FPCH Admin AWS Posted August 9, 2023 FPCH Admin Posted August 9, 2023 Google typically releases a new Android version annually during the late third or early fourth quarter of the calendar year. They also require that apps uploaded to the Google Play Store are optimized to run on at least the previous year’s API version by mid-fourth quarter. API versioning is the practice of managing changes to an API to prevent breaking changes. Android 14 is soon expected to be releasing by Google. Our Microsoft Intune app protection policies (APP) and mobile device management (MDM) teams have been working hard to make sure Microsoft Intune customers are supported on the new operating system (OS) release. In this post, we’ll share some of what we’ve found from testing the latest Android beta builds and highlight other noteworthy changes that are coming with this release. We’ll update this blog post if new items are discovered during our continued testing. We also encourage you to read through Google’s Android 14 change documentation, and the Google article, Behavior changes: Apps targeting Android 13 or higher, to identify other changes that may be relevant to your organization. Keep us posted on what APP and MDM learnings you find from your testing too! Versioning vs targeting Day zero support refers to supporting the new Android OS version and API targeting. New Android OS versions are released every year, first on Google Pixel devices and later by various OEMs as they build out support. This year, the latest OS version is Android 14, and is expected to be available soon. API targeting is set within client apps. Google mandates that apps must target the two most recent versions to be approved in the Play store. This year, we’re targeting API 33 (Android 13) with support beginning in August 2023. Throughout this post, you may see changes attributed to either Android 14 readiness or API 33 targeting readiness. It’s important to note their differing release dates. Android 14: Updates to the Exact alarm permission on Managed Home Screen (MHS) When configured by admins, MHS uses the Exact alarm permission for configurations, which require action at an exact time. Currently, MHS uses this permission to automatically sign users out after a set time of inactivity on the device, to launch a screen saver after a set period of inactivity, and to automatically relaunch MHS after a certain period of time when a user exits kiosk mode. For devices running Android 14 and higher, by default, the Exact alarm permission will be denied. In order make sure critical functionality continues to work, users will be prompted to grant Exact alarm permission upon first launch of MHS. Targeting API 33: Changes to Android notification permission prompt behavior There are changes to how Android apps handle notification permissions to align with recent changes made by Google to the Android platform. Notification permissions will be granted to apps as follows: On devices running Android 12 and earlier: Apps are permitted to send notifications to users by default. On devices running Android 13 and later: Notification permissions vary depending on the API the app targets. Apps targeting API 32 and lower: Google has added a notification permission prompt that appears when the user opens the app. Management apps are still be able to configure apps so that they're automatically granted notification permissions. Apps targeting API 33 and higher: App developers define when the notification permission prompts appear. Management apps are still be able to configure apps so that they're automatically granted notification permissions. Admins and users can expect to see the following changes once we begin targeting API 33: Managed Home Screen: In previous versions of Managed Home Screen, when an admin had enabled automatic relaunch of Managed Home Screen, a push notification was displayed to alert users of the relaunch. To accommodate changes to notification permission, in the scenario when an admin has enabled auto-relaunch of Managed Home Screen, the application will now display a toast message alerting users of the relaunch instead of a push notification. Managed Home Screen is able to autogrant permission for this notification, so no change is required for admins configuring Managed Home Screen to accommodate the change in notification permission with API 33. Company Portal used for work profile management: In the personal instance of the Company Portal, users will see a notification permission prompt when they first open it. In the work profile instance, users won’t see a notification permission prompt as the notification permissions will be automatically permitted. Users will be able to silence app notifications in the Settings app. Company Portal used for device administrator management: Users will see a notification permission prompt when they first open the Company Portal app and will be able to adjust app notifications in the Settings app. Microsoft Intune app: No changes to existing behavior. Users will continue to not see a prompt because notifications are automatically permitted. App notifications can be adjusted in the Settings app. Microsoft Intune app for Android Open Source Project (AOSP): No changes to existing behavior. Users will continue to not see a prompt because notifications are automatically permitted. Users are unable to adjust app notifications in the Settings app. How can you reach us? Keep us posted on your Android 14 and API 33 experience through comments on this blog post or through Twitter @IntuneSuppTeam, and request any new features through our Intune Feedback Portal. We’ll update this post with any additional information we learn as testing continues, and when Android 14 releases. Continue reading... Quote Off Topic Forum - Unlike the Rest
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.