An Android App Bundler (AAB) is a publishing format for Android apps that will definitely replace the APK format. Basically, this format allows the store to generate and provide APKs that are optimized for each device configuration.
Currently it is possible to publish both APKs or AABs to the play store but Google intends to only allow AABs in the future. Because of this we decided to update all of our pipelines to generate and deploy AABs. Because this was done over an already published application some of the resources needed to implement this were already created, but we will briefly mention how to generate them here since we want to show the process end-to-end .
The first step recommended in order to use AAB is to make sure that the apps, resources are properly organized according to conventions. Since our application was made using the React Native framework, all views, images, fonts and other resources are managed by it. Because of this we did not have much to do regarding this point.
Once this was done, In order to generate an AAB for our application we simply need to execute the following command:
Since we are on a React Native project we need to run this inside the android folder of the project
This will return the app bundler on the path:
With this we have an unsigned AAB. In order to generate a signed AAB you need to previously configure your upload key, as we will describe now.
This project was already configured to automatically sign the builds if the key was available. We did this by configuring the build.gradle file of the app module of the project as following
For our project this configuration was using the app’s signing key that was generated when we set up the process for building the APK some time ago. Because of this we needed to create a new key to use as an upload key and configure both of them on the play store.
We generated a new key on Android Studio Build -> Generate signed bundler or APK -> chose App bundler -> Key store path -> create new, and complete the form.
Then we upload them to the Google Play store. Take into account that this process will be different if you are creating a new app, in that case you will configure this during the creation of the app on the store. In our case we went to the Google play console Setup -> App singing, chose Export and upload key from java keystore and followed the instructions of the page.
Once the keys are configured we can generate a new AAB and prepare to upload it to the store.
To upload an AAB to the play store we use fastlane supply. The fastlane installation and configuration was done inside the android application of the project, So we can java it separately for the one on the IOS side of the project.
In order to configure supply we need to generate a play-store-credentials.json file on the play store and set it on fastlane’s Appfile so supply can connect to the store:
set
This JSON acts as a key that allows Supply to connect to the play store account associated with it and perform actions on the declared package.
In our case, since we already had a pipeline running with supply we didn't need to prepare this step. Because of this we prepared our new pipeline so it can upload the AAB using one of 3 uploading methods.
Inner app sharing
This is the fastest way to share test builds available on the google play store, it is meant to be used to share a link with the developer team. To use this method we created a new lane on our android fastfile similar to this one:
This is the fastest method to share an android app, around 15 minutes until the app is available. Unfortunately it does not sing the app with its store keys and does not count as part of the normal building flow. Because of this thos builds can not be promoted to release nor used to test integrations that require proper singing like firebase. The Slack part of the lane allows us to notify our team of the new build and shares the install url.
In order to install an android “inner app sharing” build you need to be logged with a test account on the android app store and have the “internal app sharing” toggle enabled in Your account settings. You can find this toggle in the app store on Profile -> Settings -> General -> Internal app sharing. If you are not able to see this option then you need to enable the developer mode on the app store. This can be done via Profile -> Settings -> About -> Play store version and tap repeatedly this item until you see an alert indicating that you entered developer mode.
To set up a they account the account manager needs to go to google play console/{your-app}/Setup/Inner app sharing and add the accounts email to the testers list selected.
This is the method provided by the store to generate closed tests for your app on the normal building flow. This means that the store will keep track of this build number and any new build will need to be greater than it. The build is also properly signed and can be promoted as a production release. Because of this the process is much longer than an inner app sharing, it takes 4 to 5 hours since it needs processing and approval by the Google Play store.
You can use fastlane supply directly to upload an alpha test:
Only the declared testers can install this app from the google store directly while the app is in Alpha state . Testers are configured from the play console on Testing -> Closed testing -> manage track/testers.
The only difference between this and Alpha is that any user can choose to become a beta tester and become able to download your beta releases from the store instead of the prod app.
In order to release the application to the final users we promote our alpha tests to release. We do this by going to the google play console Testing -> Closed testing -> Releases. There we chose “promote to release” on the desired track.
Once this is done we will be redirected to a screen where we will confit the release build, metadata and load the release notes. Once all of this is confirmed the roll out of the release will start with the specified percentage of users.
The scheduling of the automated builds was configured through an AWS Codebuild Build. The Configuration of this build and the api for the on-demand builds are loft to be commented on a different post.
In this article we described how to prepare a flow that generates a signed AAB and uploads it to the store using different testing tracks. For our automated daily builds we use internal app sharing and alpha tests for more formal pre-releases. We've discussed one way to sign an Android project for app releasing
