App version management in Android Enterprise – Managed Play Closed Tracks and their nuances

If you think my titles are wordy, check the official title of good old Robinson Crusoe! Anyway, today we will look at two important things:

• Using Managed Google Play feature called Closed Tracks to control app versions and update cycles in two scenarios:
  • Multiple “deployment rings” for different device groups
  • Developer having customers with different update cycles
• Important caveats and limitations of said feature and how they will ruin your mobility deployment if you are not careful!

What it is about

Google Play Store has a feature called “Closed Testing Tracks“, which allows developers to upload early versions of the applications and share them with closed groups of testers. At the end of 2020 this feature was updated to support Android Enterprise (Managed Google Play) and production use cases. The idea is as follows: here is my app in my Google Play Console, it currently has version (build code) 9.

If you are an MDM admin (not developer) and want to find out how to get Google Play Console access – read this

I have shared a production version of my app with my AE organization via Setup -> Advanced Settings -> Managed Google Play, so it can be used and assigned to devices in my org (read more about this here)

Sharing a Production app with AE org in Managed Google Play

This, however, only exposes the production version of the app. What I can do now, is add additional versions of the app in the Closed Tracks. Here I have created a number of tracks, gave them names, and uploaded versions 10-13 of my app.

Creating Closed Tracks in Managed Google Play

Now, there is one more thing to be done (for each track) – instead of inviting testers via Google Groups or email addresses, I can share those tracks to Android Enterprise organizations (one or more) via their IDs, similar to how it was done for Production.

Sharing a Closed Track with AE org in Managed Google Play. You can share it with more than one organization.

How, with this setup in Play in play (yes, bad puns intended) we can look at the use cases. What can we do?

Use Case 1: Internal app version management

In this scenario we assume that the application is our own internal app and we want to share different versions of it to different devices. Reasons may be various, but typically they would revolve around testing, early adopters, staged rollouts, update freezes for specific mission-critical device groups (no updates to mobile PoS during high season) etc. In order to achieve this, once the tracks are set up, I simply need to choose the track during the assignment in my MDM. Here’s an example from Workspace ONE UEM (v2010+ is required) – they are pulled dynamically from Google Play.

Managed Google Play closed tracks are automatically synchronized into Workspace ONE UEM 2010+

Then you can create assignment structure like this, based on different smart groups, and carry on business as usual. Simple!

Assign closed tracks to smart groups as usual

Use Case 2: Developer with customers on different update cycles

This is a scenario, where the app owner is an independent software developer that has customers with different update cycles: one customer wants to update every month, another every 3 months etc. The implementation is similar to the previous one, except that tracks will be shared with multiple customers, and not every customer may see every track. Then they assign track(s) via the above method – simple!

Right?…

This is where the caveats come in…

Caveat 1: Superseding tracks

So far, the system seems to be simple, logical and intuitive. Unfortunately, an important caveat hides here:

All users are always eligible to receive the production track. If an APK with a higher version code is published in production than in the test track where the user opted in, the user will receive the production APK.

This essentially means, that as soon as the Production version of the app is higher (i.e. newer) that the Closed track version:

• the closed tracks with lower version will shut down with Inactive:Superseded status (tracks with versions higher than prod will remain)
• they will no longer be synced to the UEM console
• all devices assigned to those tracks will be upgraded to production version of the application

Or, in simple terms, your carefully crafted deployment model will be RUINED. You were warned!

Thus, implementing a (fairly typical) scenario, when a developer updates the public version of the app (on the public Play Store) every week or two, and has customers on “slower” closed tracks is currently impossible, since the production version of the app must be the oldest one. However, if 100% of the app audience is internal/B2b and understands that they never should use the production version of the app – both use cases can work. …But keep in mind another little inconvenience.

Caveat 2: Managed configuration schema

Technically, apps in different tracks may have different managed configurations assigned to them (i.e. beta version of the app works with the beta server, and prod works with the prod server, with server URL specified via AppConfig). This is officially supported by Google. With one detail: the managed configuration schema is always pulled from Production track.

Thus, if your app had two config parameters, and you need to add a third one – you will have to update the production track! You can, however, avoid ruining your setup by first, releasing even higher versions into all the closed tracks. Just ensure you release into closed tracks before you release into prod! This will cause all the devices to download the update, but nothing prevents you from putting the same code (i.e. the only new thing in the APK will be the build code). Lots of wasted bandwidth though…

Alternatively, closed track versions could start at 10000 so that you have plenty chances of bump prod track w/o affecting the closed tracks.

However, all of these problems could have been solved, if there was a tick box in the closed track saying “Do not supersede this track“. Without knowing the internal structure of Google Play it is hard to say how easy or hard implementing such a checkbox could be, but let’s hope we will get it sooner than later!

Update! I have created a feature request that was forwarded to Google. You can upvote it here to demonstrate interest and provide support: https://wsone.ideas.aha.io/ideas/GOOGLI-I-310

In the meantime, if you want to track what’s new and coming to Managed Google Play and Android Enterprise in general, you can do it here: Upcoming Android Enterprise features.

Summary

In this post we have examined the following:

• How Managed Google Play closed tracks feature works and is set up
• How MDM admins could use it to distribute different versions of the same app to different devices inside an organization
• How developers could use it to support customers on slower update cycles (or how you could, under some circumstances, request a “slower” track from your developer)
• What caveats exist and what workarounds may be used to still leverage closed track without ruining your deployment
• Where to track new and upcoming features for Android Enterprise
• How you can vote up this feature to give it more traction

Was that useful? Are you more or less inclined to use the Closed Tracks feature now? Found any errors? Have an opinion to share – comment here or on LinkedIn!