Deploying Your Apps with Android Application Bundles (.aab)

Darryn Campbell -
5 MIN READ
657

As part of their annual Google Play policy updates, back in November 2020 Google announced that from August 2021 all new apps must publish in the Play Store using the Android App Bundle format (.aab).  This change coincides with the update to target Android 11 and more details are available in the Android blog post.  In July 2021, Google released an updated blog post which confirmed that private enterprise applications are unaffected by this change.

So, what does this mean for developers targeting Zebra Android mobile computers?

At the time of writing, this change only affects applications which are published to the Google Play Store as publicly available.  For clarity, there are three broad distribution mechanisms that a developer may choose to distribute their app:

  1. Make the .apk available as a download from their website or use something like GitHub releases or Microsoft’s App Center which integrates with their CI system.
  2. Distribute the app privately to managed Android devices using Google’s managed Play store in conjunction with a supported EMM Publish.  This application can then only be seen by one or more specified organizations.
  3. Publish as a public application in the public Play Store.  Organization administrators can then include the application in their managed Play Store as needed.  E.g. Zebra’s Workforce Connect PTT Pro.

Developers currently using the first or second distribution mechanisms remain unaffected by the change to .aab files in August 2021

Assuming you intend to distribute your application via the Play Store you will need to move to the application bundle format to distribute new applications, although updates to existing applications remain unaffected.

I did not intend this article to promote or describe application bundles and there are a lot of online resources talking about app bundles.  For a good getting started guide, I recommend the official guide from Google.  The remainder of this article will look at some of the common reasons Enterprise developers have not yet transitioned to app bundles and what changes they will need to make.

With app bundles, Google manages your app signing keys.  I find this easiest to explain with the below diagram from Google:

As a developer you sign your app in the same way as you do with .apk distribution but with .aab distribution this upload key is only used to authenticate you as the developer of the app, the actual app installed on the device is signed with a separate, app signing key, which is controlled by Google.

Having Google manage the app signing key can impact enterprise developers:

Trust concerns:

If you are concerned with trusting Google with your app signing key, I would point you towards the following quotes from Google’s app signing documentation:

Your keys are stored on the same infrastructure that Google uses to store its own keys, where they are protected by Google’s Key Management Service. You can learn more about Google’s technical infrastructure by reading the Google Cloud Security Whitepapers.

By using a separate upload key you can request an upload key reset if your key is ever lost or compromised. By comparison, if you’re not opted in to app signing with by Google Play and you lose your app’s signing key, you lose the ability to update your app.

Any developer or organization that still have concerns trusting their app signing keys to Google will need to use an alternative distribution mechanism that does not require the use of app bundles.

Functionality concerns:

Developers who already have a key management process (& we have a whole team for that!) may be concerned how the move to app bundles will affect their existing processes.  Google provides flexibility in how the app signing key is generated to accommodate the widest range of possible CI processes.  There is an article in the Google Play help center on this topic but as an overview you have the following choices for your app signing key:

  • Allow Google to manage and protect your app signing key for you (default)
  • Use the same key as another app in the same developer account.  This option is only available if you have already opted into Google’s app signing.
  • Export and upload a key from a Java keystore, likely the keystore you also used to sign another app.  Note that Android Studio will also offer you the option to export an ‘Encrypted key’ when you generate the signed bundle.
  • Export and upload a key (not using Java keystore).  You will need to execute some code on a provided public key and upload the generated encrypted private key back to the Play store console

MX features that require the signature of the signing certificate:

Some Zebra MX features, particularly those available from the Access manager require you to provide the signature of the certificate used to sign the app for security reasons.  If your device provisioning process requires the use of app signatures you will need to update these signatures to ensure they represent the signing key (controlled by Google) and not your upload key.

Download the app signing key certificate from your Play console:

This will give you a deployment_cert.der file that represents your signing key.  You can then convert this .der file into the required format, if needed and update your provisioning process.  I wrote previously about these signing certificates and how to convert them to the required format.

Typically, only the developer or software configuration team will have access to they Play Store console; since this team are typically separate from the staging administrator, who will actually configure the devices, remember to provide them with the deployment_cert.der file.

Note that if you are using the EMDK ProfileManager to apply your MX then this change to the signing certificate will not affect you.  For example, this application would not be affected.

In conclusion:

Because this change only affects new apps published to the public Play Store, I would expect only a minority of enterprise developers will be affected.  Please be aware however that the author has no visibility of Google’s roadmap in this area, I would caution that there is no guarantee that private enterprise applications as well as updates to existing apps will remain exempt from this requirement moving forward.

Other resources:

Applications distributed via the Play Store are installed on devices as split APKs.  For more information on sideloading & extracting split APKs please see this previous article on the developer portal: https://developer.zebra.com/blog/sideloading-android-apks-files-using-apksinstaller-utility

profile

Darryn Campbell

Please Register or Login to post a reply

Replies