What OS rel. your Android fleet is running ?

[jarmo_akkanen]

I'm just curious to know how other corporates doing OS patching. 

We at SAP only allow 2 latest OS versions which means today we only support Android 14/13.

Our Android fleet is approx. 10 000 devices. Mixed Samsung and Google Pixel, no other manufacturers allowed.
70% of our Pixel devices running already Android 14
11% of our Samsung devices running already Android 14

How about yours?

[jasonbayton]

That's a super impressive figure for 14. Congrats!

I previously mandated support based on SMR status, so on average estates would get to about 3 years old before they were locked out with a 180 day buffer, but obviously if Android 11 units are still getting SMR (they do until Q1 next year), they'd be allowed to connect.

So rather than mandating latest and greatest OS, which I had no justification for (no app or service requirements, or corporate environment restrictions to adhere to), I only ensured they were secure.

[Moombas]

We always try to stay on the latest versions available for the devices but also need to ensure all apps are running which also includes the MDM as very often Google is restricting access even for the MDM app (even device is enrolled as fully managed - I really don't understand that! BYOD or COPE could make sense but not for COBO).

So we have mainly A12 and A13. But as we are currently looking foward to exchange devices it will switch to A13/14 i think, but A14 is yet untested as there can be very model specific issues we want to test on relevant models.

[jarmo_akkanen]

@Moombas
App topic is good one and requires always big attention. We also need to make sure our internal apps are supporting and tested with the latest OS. Normally Microsoft etc.. work apps are fully compliant with new OS but sometimes we see issues on personal apps.  

[Alex_Muc]

We are more flexibile when it comes to software updates. We use compliance policies that block access to corporate resources if the patch level is older than 3-6 months.

We would prefer to keep software updates more restrictive, but would either have to use E-FOTA or wait for improvements to Android Enterprise. The update control via policies (SystemUpdateTypes Automatic, Windowed, Postpone) all have disadvantages in daily operation.
A SystemUpdateType would be ideal, where updates are forced but can be postponed x-times by y-hours by the user. In addition, a flag whether the download should be forced in a mobile network would be great.

@jarmo_akkanen 
Even if we do not block new major releases and we do test them, we are always a little careful. Especially with new versions, bugs sometimes sneak in that weren't noticed in the beta. With Android 13, there were initially problems with the Sync Manager, which caused mail apps to stop working. (e.g. VMware Boxer)

With Android 14, payloads (e.g. restrictions) on Pixel devices no longer seem to be able to be changed. At least we have the problems with the Pixel 6a. Samsung devices do not seem to be affected.
Aren't you worried that important features or apps will no longer work reliably on a large scale if a bug in a new major release slips through testing?

[Moombas]

I fully agree, especially on fully managed devices i would like to have way better control over new versions available (notification in the MDM that new versions are available, able to block updates until we allow them (the specific update and then following the set update procedure like windowed etc.)).

But in general i don't understand why Google is restricting the MDM apps (on fully managed devices) more and more. This doesnt make sense from an administrator view.

Yes, for BYOD it maybe different and maybe for COPE as well but when i fully manage a device, the MDM should have all permissions needed to set all required settings, allow/disallow updates etc..
Thin of a Stand-PC managed in a company and you don't have access to the registry or filesystem as the admin... doesn'T make sense.