Skip navigation
2020

After knowing how to upload alpha/beta/prod versions in the Google Play console, the next question is how to relate the priorities in UEM with the tracks in Play console. Given the scarce documentation, I admit I was very confused on how this should work. If in UEM, device is assigned first to Alpha track and in Play console the track is empty, does the device go see if it's also assigned to Beta? Do the priorities in UEM matter? Does the version code in Play console matter?

 

Well, here's the breakdown! (Disclaimer: applies to Workspace ONE UEM 1909 and above)

 

Prerequisite: Work Managed Enrollment Type needs to be set to device-based in Groups and Settings\ Devices & users\ Android\ Android EMM Registration\ Enrollment Settings. This ensures a different GoogleID record is generated per device, and so different app versions from the Managed Play console can be assigned.

 

1. In UEM, let's assign the app in this priority: Alpha (0) > Beta (1) > Prod (1)

2.  For each of the devices the app is assigned to, UEM gets the FIRST track it is assigned to and passes this info to the Play console. For example:

Device A --> Alpha Track

Device B --> Beta Track

Device C --> Production Track

 

3. On the Play console side, when a device is assigned to a track (Alpha/Beta), it is also approved for the Production track. Devices assigned to Production just gets approved for Production. The device will then receive the highest version among the tracks it is approved for.

 

4. Bonus scenarios:

  • When a Production track has a higher version than Alpha/ Beta, the lower version/s gets "superseded".
  • An alpha/ beta app can be released to Production. This results in the app being "promoted".
  • For both scenarios above, rule that the device will receive the highest version among the tracks it is approved for applies.

 

5. Let's try the scenarios with devices A, B, and C. The items in red for the tracks are the changes in Play console. The items in blue at the bottom of the table means there was a resulting change in version installed on the device.

 

Action Done

Released 1.1/1.2

to Alpha/Beta

Released 1.3

to Prod

Released 2.1

to Alpha

Released 2.2

to Beta

Promote 2.2

to Prod

Released 2.3

to Alpha

TrackState 1State 2State 3State 4State 5State 6State 7
Alpha(empty)1.1superseded2.12.1superseded2.3
Beta(empty)1.2supersededsuperseded2.2promotedpromoted
Prod1.01.01.31.31.32.22.2
Device
A1.01.11.32.12.12.22.3
B1.01.21.31.32.22.22.2
C1.01.01.31.31.32.22.2

 

Note:

Pre 1909, whitelisting behavior from UEM to Play console is different such that in item 2, behavior is as follows:

Device A --> Alpha Track --> Alpha, Beta, and Prod tracks approved

Device B --> Beta Track --> Beta and Prod tracks approved

Device C --> Production Track --> ONLY Prod track approved

Same Play console rule applies: The device will receive the highest version among the tracks it is approved for.

 

Below is the sample behavior pre-1909

 

Action Done

Released 1.1/1.2

to Alpha/Beta

Released 1.3

to Prod

Released 2.1

to Alpha

Released 2.2

to Beta

Promote 2.2

to Prod

Released 2.3

to Alpha

TrackState 1State 2State 3State 4State 5State 6State 7
Alpha(empty)1.1superseded2.12.1superseded2.3
Beta(empty)1.2supersededsuperseded2.2promotedpromoted
Prod1.01.01.31.31.32.22.2
Device
A1.01.21.32.12.22.22.3
B1.01.21.31.32.22.22.2
C1.01.01.31.31.32.22.2

 

 

Special thanks to Jason Huang, Kevin Murray, Glen Friedman, and Michael Gow for helping breaking down the components with me. Also Scott Arndt for the note on device-based enrollment type.

 

11 Feb 2020 - First published

16 Feb 2020 - Added note that Work-Managed enrollment type in UEM should be set to device-based