This month’s post focuses on managing 3rd party and/or LOB apps with Google Play and distributing those apps to Android devices enrolled via Device Owner (i.e. Android Enterprise).
Background
Traditionally, organizations who are issued apps from ISVs and/or are creating their own LOB apps distribute them by uploading the apps to their EMM console and deploying them to Android devices. This scenario has worked well with Android Device Admin enrollments however, with Device Owner enrollments (Android Enterprise) Google is recommending a more secure way to distribute apps for all Android Enterprise enrollment scenarios through Managed Google Play (MGP). According to Google deploying through MGP helps ISVs manage versions more easily and provides app scanning during upload to help find vulnerabilities and poor coding practices. Utilizing MGP to manage app versions and distribution is new to many ISVs and customers and is requiring them to rethink their app distribution processes and leverage MGP vs distributing individual .apks in an adhoc way.
App package distribution
To upload apps to Google Play, Google offers two options:
- Upload through the Managed Google Play iframe inside Intune – best suited for companies uploading internally developed apps.
- Upload apps thru the Developer Console in Google Play. This option is better suited to 3rd parties and ISVs that want to make their apps accessible to multiple organizations.
Using the Developer Console requires ISVs and app devs to register for a Google Play Developer account. The registration fee is $25 and details may be found here: https://support.google.com/googleplay/android-developer/answer/6112435?hl=en
App management contention
By utilizing Managed Google Play with Android Enterprise enrollments, some organizations are beginning to experience errors when they attempt to upload an app an ISV provided (.apk) that already exists in Google Play (public or privately published). The reason for the error is Google Play doesn’t allow more than one app to reside in the service with same package name.
Another issue we’ve seen is when customers have uploaded the ISV app privately via Intune or through their Google Developer account and when this occurs, the ISV cannot upload it anymore and are required to change the app package name and upload it to Google Play through their Google Developer environment. Google has stated once an app is uploaded to the Play store and installed on devices, “unpublishing” the app prevents new users from installing the app, however existing app users are still be able to use the app and even update the app to its latest version. Therefore, Google Play does not allow other ISVs to reuse the same package name as it would lead to unexpected and insecure behavior.
This could be concerning for ISVs who may be the true owner of the app and someone uploaded it privately to Google Play first and as a result they need to rename their app package and upload from that point on.
Details on publishing an app via Google Play: https://support.google.com/googleplay/android-developer/answer/6334282?hl=en
Publishing and distributing apps
To address the app package distribution issue, Google is asking ISVs to change their app management strategy by uploading their apps to Google Play and assign the apps to their customers via their customer organization ID. Customer ID is located via the account the customer utilizes to access Google Play from their EMM (i.e. Intune). For LOB apps, customers can also utilize the same method to publish their app to their organization.
We can break ISVs (app devs) into three categories:
- 3rd party ISVs who are designing an distributing app to their customers.
- Org distributing an app provided by an ISV – where the ISV has provided them one or more versions of the same app.
- Internal org app devs developing and needing to distribute LOB apps among their workforce.
For more details on app publishing please visit: https://support.google.com/googleplay/work/answer/6145139#publishprivate
Organizations may choose to publish their apps via the Managed Google Play iFrame within the Intune admin console. However, the same rule applies where an org will be blocked from uploading if the app already exists in Google Play with the same app package name. Additionally, a developer might choose to publish an app to Play via APIs directly from their build environment. https://developers.google.com/android/work/play/custom-app-api/publish
If the ISV runs into a scenario where the app package is already present in Google Play and they didn’t upload it, they will need to rename their app package which ends the process of someone else uploading the app in their name. Google has stated ISVs experience this issue will also need to inform them that they are the true owner of the app so they can address any conflicts.
With Android Enterprise, Google has stated distributing individual .apk files is not scalable because it introduces challenges for ISVs to manage multiple versions of apps and updates. If ISVs distribute through Google Play (publicly or privately) they gain additional insight around app analytics, performance, and can quickly update and distribute apps to their customers. Another benefit Google Play provides is malware detection and removal and preventing older APIs and suspicious SDKs.
App Releases and Tracks with Android Enterprise
ISVs often have multiple versions of their custom app while maintaining the same package name (e.g. com.customapp.something) and before Android Enterprise Device Owner enrollment was available, ISVs simply published their .apks via their website for download or sent customers special builds of their .apks. Additionally, organizations have utilized tools such as AppCenter (HockeyApp) to publish apps for download.
ISVs may still publish apps directly to customers by utilizing the Google Play Console and app releases and there are various tracks ISVs may utilize, such as an Internal test track, Alpha, Beta, Prod, and custom tracks. Each track may have an app release with an identical app package and version that may be associated with (i.e. distributed to) up to 100 independent organizations using the organization ID of a customer’s Managed Google Play environment. However, ISVs may want to create multiple tracks and associate apps to their customers as necessary (according to Google, there is no limit for creating tracks). Note: Intune does have a 10 track limit for each app though.
For more details on preparing and publishing app releases visit: https://support.google.com/googleplay/android-developer/answer/7159011
App release management in the Google Play Console
The Organization ID may be located by logging into Google Play, selecting Admin Settings as shown below:
Minimum Target API
Currently the minimum target API for apps to be uploaded to Google Play is API version 28. This requirement may be a concern for ISVs, however Google has been known to allow apps targeting older API versions via an exception provided if it is only privately published (please contact Google with questions). If the ISVs attempts to upload an app with an older API version they will receive an error in the Google Play Console. However, apps published through the Intune MGP iFrame are not subject to the same minimum API requirements at this time.
Intune support of tracks
As of April 2020 release, Intune supports publishing tracks (e.g. Alpha/Beta), for more details visit:
Conclusion
When you have a LOB app or are provided apps from 3rd party ISVs, you’ll need to instruct the ISV to utilize Google Play Console (or you’ll need utilize the Google Play Console) to upload and publish the app privately or publicly, then assign the app(s) to up to 100 organizations per app.
Appendix
Android app file sizes (.apk)
Customers may ask about app file sizes and/or when they receive an error uploading their .apk via the Intune MGP iFrame stating the file is too large.
There are a couple paths customers can go down, .apk and app bundle format which according to Google docs, app bundle is preferred. If the .apk is exceeds the limit of 100 MB then Google recommends the use of expansion files.
Apps on Google Play have a size limit, which is based on the compressed size of your APK at the time of download.
Once you upload an APK, the Play Console uses gzip to estimate what your app’s download size will be. When users download your app, because of the advanced compression tools used on Google Play, it’s possible that your app’s actual download size will be smaller than the estimate that you see on the Play Console.
Depending on the Android versions that your APK targets, the size limit is:
- 100 MB: APKs that target Android 2.3 and higher (API level 9-10, 14 and higher)
- 50 MB: APKs that target Android 2.2 and lower (API level 8 and lower)
If you can’t support all devices with a single APK, you can upload multiple APKs for the same app that target different device configurations.
Note: Users must run Play Store version 5.2 or higher to install 100 MB APKs.
References
- App upload details/info: https://support.google.com/googleplay/android-developer/answer/113469?hl=en-GB
- Multiple .apk support: https://developer.android.com/google/play/publishing/multiple-apks
- App bundle: https://developer.android.com/guide/app-bundle
Mobility, Management, & Security 