Skip to main content
mattdermody
Level 3.0: Honeycomb
May 12, 2026

What options are there for managing Google Play System (Mainline) Updates?

  • May 12, 2026
  • 2 replies
  • 287 views

Our very own ​@jasonbayton has an article on this topic that is a few years old, but has recently been updated.

https://bayton.org/android/gpsu-system-update


Jason is often ahead of the pack when it comes to understanding what new versions of Android bring, and I am incredibly thankful for the research he does and the education he provides to the community. In this case, an article he wrote several years ago is only just hitting my doorstep now. This is largely driven by the fact that new versions of Android, thankfully, do not propagate immediately into the production world of dedicated enterprise use. We are only really starting to see Android 14 show up in any material way now.

With that, we are now being exposed to the fact that even more components and modules have been included in the Mainline system through Google Play System Updates. One of these modules appears to be the cert store containing the system certs. Recently, we encountered a major production outage caused by a root cert rotation (Sectigo...), where the only resolution was getting the system cert lists on the devices updated. Given that the devices were on Android 14, the only way to do that was through Google Play System Updates. We found devices spread across a range of different versions of these updates and were only able to verify that manually, deep within the Settings app. Verification was manual and painful, and forcing the updates was as well, requiring multiple forced installs and reboots on the devices. This has exposed yet another vulnerability in these environments, where once again Google seems to be to blame. It is a very confusing position to find yourself in, having an automatic update that you cannot control or schedule be a critical component that the devices rely on to function, and then in an emergency having no way to automate that install. The very Mainline system was supposed to solve these sorts of issues, and yet here I find that it is making things worse in certain situations.

I am a bit perplexed by how we can enter this world of more and more core system components migrating to Mainline while simultaneously not having deployment control over those updates. Why can’t I force them? Why can’t I stop them? Why can’t I roll them back? These are questions I am asking, and any CIO with a fleet of mission-critical Android devices will be asking them as well the next time operations are down, either because Google forced an update out automatically or failed to push the update out automatically.

How is it that we do not even have a proper mechanism to report on and monitor what version of Google Play System Updates is installed on a device, and the versions of each of the potential subcomponents included within? Am I missing something? Do some EMMs report on these properties?

The uncontrolled world of updates to system components like WebView was already stressful enough, but I was at least able to report on those versions. Google Play System Updates are becoming more critical and yet remain more of a black box than ever before. I cannot report on them. I cannot automate them. I cannot force them to happen. I cannot undo them if something goes wrong.

There is this community article that was suggested to me when I started drafting this up. This however simply describes what System Updates are. It doesn’t really explain how you can actually manage them.
https://www.androidenterprise.community/best-practices-33/managing-google-system-updates-with-android-enterprise-211?tid=211&fid=33

What does the community have to say? How are you managing these in your environments?

2 replies

SF4
Level 1.6: Donut
May 12, 2026

We faced a similar issue with the Sectigo certificate change. While there are certainly benefits to "outsourcing" update components from OS updates and security patches to Mainline, there is definitely a need for admins to be able to remotely retrieve information about which Mainline updates are installed on devices. More importantly, admins absolutely need the ability to control these types of updates.

In the past, Android phones and tablets were often viewed as supplementary work devices. Nowadays, the Android device is frequently the only device users have to complete their work, especially with the growing promotion of desktop mode and Samsung DeX.

This shift in device importance makes the lack of control over critical system updates even more problematic and concerning.

jasonbayton
Level: 4.1: Jelly bean
May 12, 2026

<3 

 

I'm not managing mainline anywhere now, obviously, it's a primary callout with new engagements where update management is considered important that all we can do is close our eyes and hope for the best.

 

Wildly frustrating to see it's been broken like this for 2 years and counting.

 

That said, I've seen some new references to OTA integration with the AMAPI SDK in 1.8.0 and while it offers no immediate help with Android 17, points at least to the suggestion something is happening in that department. 

 

Fingers crossed!

mattdermody
Level 3.0: Honeycomb
May 22, 2026

Thanks for that feedback. 

Are you aware of even any method to have the current mainline patch level reportable via EMM? While frustrated to not have any proper control over them, I would at least expect to be able to have visibility into the versions of mainline packages on the devices under management and that doesn’t appear to be the case. 

jasonbayton
Level: 4.1: Jelly bean
May 22, 2026

Yes, I’ll link to device trust because that’s clear on the API available: 

https://developers.google.com/android/management/device-trust-signals

 

Device Security Patch Level SoftwareInfo#getDeviceSecurityPatchInfos() returns the current security patch level of the device for different updatable components:

 

 

And also available to DPCs - https://developers.google.com/android/work/security-posture-signals

 

A DPC or application (because it’s not restricted) can also query the version of com.google.android.modulemetadata to get the device mainline version. This is what I do for Managed Info.