Is Google Play Closed tracks for testing only?

[Jensa]

Hello Community!

We have a business critical app delivered to us from the developer in Google play closed tracks.
When a new version is released, the developer creates a new track for us giving us full control of when we test it and to what assignment group we want it to be installed. When we are satisfied with our testing we assign the lates track to our production devices.
I recently got the question if Closed tracks is not just for testing apps, and not to be used for production as we do.

I would like your help to elaborate on this. Does anyone use Closed tracks the same way as wee do? Do you see any downsides or risks by managing apps this way?

Thanks for your feedback!
//N

[BenMcc]

@jasonbayton Limits for Play console closed testing is limited by the number of testers and lists you can have on the account. You can have 2000 users per list, 50 lists max per track and a max of 200 lists across the account.

[jasonbayton]

Ok so there's a lot of wiggle room there, and I don't see install base counting towards this.. so sharing a track to an org with 10k devices wouldn't be constrained by any of the above because it's one item in the list?

I know there's an arbitrary limit to the number of organisations you can share to via play for some reason, but that's still a lot of runway. 

[BenMcc]

I still think the biggest problem is that there is nothing to stop Play changing the policy for any of this. Test tracks are designed to be just that and so using a test track as a production outlet may cause problems if, for example, they decided next month to limit test tracks to 500 testers! While it may work, longer term it may not be a great idea!

[mattdermody]

I completely agree. I try to highlight this risk to my end customers that insist on using feature limited AMAPI aligned EMMs like Intune that force us into using Private Closed Test tracks for production application usage on line-of-business devices. Sure we can maybe use this workaround to accommodate the usage of an EMM that can't install APKs directly on devices but this workaround is unofficial and could be cut off unexpectedly. Many people just don't understand these nuances of Android management until they run into an actual issue and realize they're painted into a corner.

[jasonbayton]

I don't know of any documented limits to the number of devices installing an app from a track, that's perhaps something Lizzie will provide in the comment below, but on the face of it this doesn't sound like a bad approach.

If I had the option I'd still work from a unique package name. It's easy for a dev to generate this, and push it to play as a private app as the production version, using a closed track just for the testing before it's pushed to production.

That then aligns more closely with how Google expects these things to work, and avoids any potential issues with your flow in future (policies change...)

[Moombas]

Hi Jensa,

just to add here as well, please see this:

https://support.google.com/googleplay/android-developer/answer/9845334?hl=en#:~:text=Closed%20testin....

Means: No, it's not the way how it should be used as @BenMcc already mentioned.

The way to go would be that the developer provides the app as an apk file (if your MDM provides such "sideload" functionality) or as a private app: https://support.google.com/a/answer/2494992?hl=en#zippy=%2Cmanaging-private-apps-in-admin-console-ve....

[Jensa]

Hi Moombas,

Thanks for your reply.

So, if a developer want to deliver apps to us it "should" be done via Private track, right?
In that case it also means that the developer need to create a a separate package ID just for us?
I see a gap here, a problem for the developers.
If it is not supported to use Closed tracks, where a developer can create multiple tracks/versions and invite multiple customers, then they have to use Private tracks which means that they have to go through massive administration, creating separate package ID´s for each customer, and also build separate tracks for each version and for each customer.
This will most likely result in that developers won´t offer that option, since it´s too complex, which then will result in big companies, like the one I represent, to not choose Android as plattform since we lack control, and that would not be good for Google.

I understand that the intent with closed tracks maybe wasn't to solve use cases like ours, but what is it exactly that is a risk of using it like this?

Kind Regards
//Niklas

[mattdermody]

This is the exact position we take within our org. We develop enterprise applications that are not published to Public play that need tight version control for each of our end customers. We have ZERO appetite to provide custom compiles of the base APK with unique bundle IDs for every customer just to get around limitations of the Android Enterprise ecosystem. As a result of this our typical firm stance is that a custom DPC based EMM is required so that our customers can have comprehensive version control over the apps that they're installing since their EMM can install it directly on devices. Android Enterprise still falls very short when it comes to proper version control in a line of business device setting so we are generally stuck pushing people away from AMAPI / cloudDPC toward hybrid EMMs that offer Google Play AND direct APK installs. In edge cases where we don't have a choice we leverage the closed testing tracks concept but even that is a lot of administrative overhead because we run into other limitations like Intune only supporting the display of 10 closed test tracks. We have 100+ versions of our application and counting and therefore have to carefully choose which 10 versions to grant to each Org ID. The large majority of our end customers however opt to go with custom DPC based EMMs since they aren't willing to expose themselves to production risks caused by Google Play based mission critical app installs. 

I am very much aware that I am swimming against the current with this stance but this is based on years of personal experience with Android Enterprise and constant re-evaluation of it's capabilities. App installs via Google Play are just not reliable or robust enough for line-of-business app and device environments. 

[BenMcc]

Hi,

People do use the tracks in the way you describe, and as you have experienced it does work, however there are limits on the testing tracks (number of testers etc) which may or may not be a problem for you. It is also not the way Play is designed to work and there is no guarantee Play won't change how the test tracks work at anytime which may cause problems for you in the future.

Ben

[jasonbayton]

I'd imagine with our use case here the number of testers perhaps wouldn't matter.. unless individual devices fall under the finite limit for distribution via closed track? Otherwise the in-console area to add organisations wouldn't grow past a few IDs typically, especially if it's a track per customer.

@Lizzie are there documented limits to tracks that could impact this approach?