Forum Discussion
Enhancing Android Enterprise OS Update Management
Hi,
The way the Android API implements OS update management on Android Enterprise devices is not particularly useful for devices with user affinity. Are there any upcoming API changes for EMM solutions like Microsoft Intune?
From my experience with the current API:
- AUTOMATIC – The OS update is installed as soon as it becomes available via OTA, which is not practical for real-time scenarios.
- WINDOWED – Similar to AUTOMATIC but with the limitation that OS updates can only be installed within a defined maintenance window. This means that if a user needs to update their device due to a software bug fixed in the latest OS version, they may not be able to do so immediately if the maintenance window is set outside working hours.
Suggested Improvements:
- Provide an option to control OS updates on BYOD (Work Profile only). I understand that when enrolling a device through Work Profile, only the work container can be managed via EMM. Google may need to reconsider this approach.
- It would be beneficial to have an approach similar to Apple’s, where EMM admins can manage OS updates (e.g., push specific updates, set deadlines, etc.) through DDM (Declarative Device Management - Source: https://support.apple.com/en-gb/guide/deployment/depc30268577/web ), even on BYOD devices (Device Enrollment) — without requiring supervision like DO (Device Owner mode).
I’m aware that Samsung Knox E-FOTA exists, but it is limited to Samsung devices. Expanding this capability to all Android devices (like Google Pixel devices) would greatly improve update management in enterprise environments.
BR,
Marco
Hi Marcom,
you left out "Postponed" as an actual option but i guess all IT admins agree, that a full version control on firmwares is needed. I think I (and others as well) already provided several ideas to do so.
I don't know the Apple system but keep in mind that they have an easier task as they provide only their own models and firmwares where on Android you have several manufacturers with a lot of unknown firmwareupdates etc. (seen from Google side).So there must be something different.
If i find the thread where we discussed that already a bit I can post it here but need to search for it again.
But i don't see a reason to do so for BYOD, there i would like to just say "minimum OS version X" and/or "minimum security patch level" and that otherwise work profile get's disabled or not being able to be installed.
Hi Moombas,
I'm aware of the Postponed option, but this only defers updates, which we currently don't need.
We are currently enforcing the minimum OS version/security patch level within the compliance policy and blocking access to O365 services. But yeah, as mentioned, Google needs to rethink the current solution/approach.
Hi,
It could and should indeed get some attention to get some improvements. We implement Knox E-FOTA a lot, exactly because of this lack of control on the Android side itself. Zebra and HDM also designed something themselves, but I believe that shouldn't be necessary.
I don't really agree on your BYOD case tough, in theory its still a user owned device. Your EMM should be able to set minimum requirements for software version.
What I really mis is the option to control when and how the update is pushed and installed. A time window, and an option for the end user to postpone ones or twice and than actually update. As a finishing touch, confirmation to the EMM that the firmware is actually installed.
I dont need a confirmation on the EMM (the currently installed oem/os/security patch version is enough) but we really want to say something like, install all oem versions up to version X.
This could be model specific (makes most sense to me) or any other but should be open to the customer what kind of decision point(s) to choose.
I am not really sure if AE needs anything for devices with user affinity. Updating the devices should be a job for the end user to do self, when it is suitable for the end user. With automatic updates it can disrupt important job.
We have instead used compliance rules when updating the minimum security patch version and emailed users with old software and given them 14 days of grace period, with periodically reminders before the device has lost its compliance status.
