Introduction

An Android App Bundler (AAB) is a publishing format for Android apps that will 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. Since this was done over an already published application some of the resources needed to implement this were already created. However, in this article we will briefly mention how to generate AABs from scratch since we want to show the process end-to-end - assuming that the app that is going to be published has been developed in React Native.

Implementation

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 automatically 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: 

./gradlew bundleRelease

Since we are on a React Native project we need to run this inside the android folder of the project

{project-folder}/android

‍

This will return the app bundler and generate the AAB file on the path:

{project-folder}/android/app/build/outputs/bundle/release/app-release.aab

With this we have an unsigned AAB which can't be uploaded to Google Play. In order to generate a signed AAB you need to previously configure your upload key, as we will describe now.

AAB signing process

Our 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

{project-folder}/android/app/build.gradlesigningConfigs {
  …
  release {
      if (project.hasProperty('RELEASE_STORE_FILE')) {
          storeFile file(RELEASE_STORE_FILE)
          storePassword RELEASE_STORE_PASSWORD
          keyAlias RELEASE_KEY_ALIAS
          keyPassword RELEASE_KEY_PASSWORD
      }
  }
}
…
buildTypes {
…
release {
       …
signingConfig signingConfigs.release
…       
}
…
}

In this case, RELEASE_STORE_FILE refers to the key file stored in .jks format.

For our project this configuration was using a 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 via the menu Build -> Generate signed bundler or APK -> App bundler -> Key store path -> Create New, and complete the form.

Then we upload those keys 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 tune it separately for this platform. In order to configure the supply fastlane command we need to generate a play-store-credentials.json file on the Play store and set it on fastlane’s Appfile ({project-folder}/android/fastlane/Appfile) so supply can connect to the store:

json_key_file "~/{project-folder}/path/to/your/play-store-credentials.json”
package_name “my.package.name”

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 configured our new pipeline so it can upload the AAB using one of 3 uploading methods.

Inner app sharing method

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 from which it can download the app. To use this method we created a new lane on our android fastfile similar to this one:

lane :internalAppSharing do
  debug
  installUrl = upload_to_play_store_internal_app_sharing
  ENV["SLACK_URL"]= "https://hooks.slack.com/services/***"
  debug
  slack(
    message:"App’s  internal app sharing",
    channel: "#*****",
    payload: {
      "Install url" => installUrl,
      "Version: " => ENV["FASTLANE_INTERNAL_AAB_VERCION"],
      "Build: " => ENV["FASTLANE_INTERNAL_AAB_BUILD"],
      "Environment: " => ENV["FASTLANE_INTERNAL_AAB_ENV"]
    },
  )
end

‍

This method takes around 15 minutes until the app is available. Unfortunately it does not sign the app with its store keys and does not count as part of the normal building flow. Because of this, those builds can not be promoted to release or can't be 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 thet 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.

Alpha test method

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 have a new, incremental version number. 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:

fastlane supply --aab $AAB_PATH --track alpha

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.

Beta test method

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. This type of release can be triggered just by running

fastlane supply --aab $SUPPLY_AAB --track beta

Release

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 confirm 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 going to be commented on in a different article.

Conclusion

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 by using Fastlane. For our automated daily builds we use the Internal App Sharing, leaving the Alpha Test method for more formal pre-releases. We've discussed one way to sign an Android project for app releasing.

‍