Aircall Journey to Android App Bundle 📦
A couple months, we decided to use Android App Bundle (AAB) to distribute Aircall’s Android app in Play Store. After analyzing the Aircall Android application package (APK), we found we could deliver optimized APKs to our users — an overall size reduction of 60%!
In this article, we are going to expose our journey to Android App Bundle from our own motivations to the development within the application and the CI with CircleCI and fastlane to release on the Play Store.
Why move to App Bundle?
Moving to App Bundle had many advantages. The first and main reason was the APK size optimization, to deliver only what the user needs. After looking at our application file, we found that we embedded all native libraries (.so files) of all supported architectures! We could have used the abi split in our main build.gradle but we would have managed 4 APKs with different version code. We also saw we could reduce the resource assets to match the density of the device where the app is installed.
Here is what the Aircall universal APK looks like on the inside:
Optimizing size was not the only advantage we saw. Migrating to AAB will allow us (a little bit) to save the planet! Indeed, with all the MB saved from the downloads and updates, we are using less storage space and consuming fewer energy resources.
You can see our MAD Score below. If it hits 1 million downloads we could save 22 TB of data — really a huge impact.
We were also excited by our future ability to enable Play Feature Delivery to push features to specific users. Since we are already using feature flags inside our applications, this would let us develop features on-the-go for our users.
Gradle configuration
Moving to AAB was a very smooth process and did not require a lot of configuration code. To replicate this move, on your build.gradle of your application, add the following block to build an AAB file. You will be able to add the language, density and abi blocks to refine the split:
- language: split the APKs by each language you have implemented inside your application.
- density: the APK will match the right density of the device. For example, if you target a xxhdpi device, it won’t have other density resources such as mdpi or hdpi.
- abi: each APK will be split depending on the architecture of the device (arm64-v8a, x86, x86–64…) so it does not have to embed all .so files in a single APK.
The Aircall application supports multiple languages, and switching between languages can be done inside the app. So here, we are not splitting the APKs by language in favor of switching at runtime.
You can now generate an AAB file running the following gradle task: app:bundleRelease. Once the work is done on the application side, you can focus on the continuous integration part with CircleCI and fastlane.
Integration with CircleCI and fastlane
At Aircall, we are using CircleCI and fastlane for continuous integration to automate our release process on the Play Store. Here is how we easily changed the CI script to build and upload an AAB to the store.
In your CircleCI job to deploy to production, you will use a fastlane lane to build the AAB file and send it to the Play Store.
Now, in a Fastfile file located in the fastlane folder of your project, you can create a new lane to build and sign the new AAB file using a gradle action described below.
Instead of running the task app:assembleRelease to build APKs, you will need to use the task app:bundleRelease to generate the AAB. Then, once the file is generated, the lane will upload it to the Play Store using the upload_to_play_store action. Make sure to specify you want to upload an AAB and not an APK with skip_upload_aab:false. For instance, you can also specify the track (production or beta for your testers) and the rollout percentage if you want to target a small part of your users when releasing a new version.
Now that your new AAB file is uploaded in the Play Store, the users will have access to a smaller APK which perfectly matches the technical specifications of their devices.
Let’s have a look at the Play Store and see how it can be monitored.
What’s up on the Play Store console?
Before publishing your brand new .aab file, you have to enable the Play App Signing on the console. To access it on the left panel, expand the Release section and select Setup, then click on App signing.
Once the signing is enabled, you will be able to upload the .aab file on the console. Then, if you go into the App bundle explorer section, you will see the details of the applications like permissions, API levels, etc.
In the Downloads tab, you will be able to download the generated APK for all the supported devices (very convenient for testing). Finally, on Delivery you will see the base APK for all devices and how many APKs you can build with your AAB configuration. In our case, we have a 15Mo base APK and 12 generated split APKs for supported devices with API level 24+.
Moving to Android App Bundle has proven beneficial so far, even with a few limitations, particularly in distributing the application to our testers (with Firebase App Distribution). The .aab format is not yet supported on the console but two solutions were possible: Keep pushing APKs to Firebase or use bundletool to convert the .aab file into an APKs with a CI job. (You won’t have any issues if you are using the internal test track of the Play Store to distribute your test apps.)
I hope all this info will help your migration to App Bundle. And remember, this format will be mandatory for all new apps in the Play Store starting in August 2021 🙂
