Android App Bundles (AAB) was launched at Google I/O 2018 and has since been adopted by many companies to reduce their app sizes. It makes sense to compare what AAB offers with Multiple APKs to see which tool is more effective–and why.
AAB is a huge improvement over the previous multi-apk feature that required huge development efforts. Multiple APKs is a feature on Google Play which allows developers to upload multiple APKs based on pixel density, locale, ABI, API levels, etc. Android Developers documentation lists many rules that developers need to address before publishing APKs on Google Play.
A quick poll of Android Devs on Slack and Reddit revealed:
More than 60% people are using AAB for their production apps. Some people started to try multiple APKs but reported a higher degree of difficulty regarding maintenance.
To understand why AABs should be considered, it’s important to look at the list of rules stated in the official documentation for multiple APKs.
All APKs you publish for the same application must have the same package name and be signed with the same certificate key:
When creating multiple APKs it is important that all of them have the same package name and be signed with the same key, This is how Google Play will recognize it as a single application.
While using bundles, you simply add your private key to the Play Console, and that’s it. Google Play takes care of signing your APKs going forward.
Each APK must have a different version code, specified by the android:versionCode attribute.
While using multiple APKs there is a lot to take care of when defining the version codes and if done incorrectly, it can result in being unable to activate the APK on play console or users might not see the app updates. This is just a small list of what can go wrong just due to versionCode, taken from the official documentation:
If an APK you’ve uploaded for API levels 16 and above (Android 4.1.x+) has a version code of
0400, then an APK for API levels 21 and above (Android 5.0+) must be
0401or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
If you have one APK that’s for API level 16 (and above) and small – large screens, and another APK for API level 21 (and above) and large – xlarge screens, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 21 will receive an update for the second APK.
If you have one APK that’s for API level 16 (and above) and small – normal screens, and another APK for API level 21 (and above) and large – xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there’s no need for the version codes to increase from the lower API level to the higher API level.
If you have one APK that’s for API level 16 (and above) and ARMv7 CPUs, and another APK for API level 21 (and above) and ARMv5TE CPUs, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the CPU architecture. Because an APK with ARMv5TE libraries is compatible with devices that have an ARMv7 CPU, the APKs overlap on this characteristic. As such, the version code for the APK that supports API level 21 and above must be higher. This ensures that a device with an ARMv7 CPU that receives a system update to API level 21 will receive an update for the second APK that’s designed for API level 21. However, because this kind of update results in the ARMv7 device using an APK that’s not fully optimized for that device’s CPU, you should provide an APK for both the ARMv5TE and the ARMv7 architecture at each API level in order to optimize the app performance on each CPU. Note: This applies only when comparing APKs with the ARMv5TE and ARMv7 libraries, and not when comparing other native libraries.
Failure to abide by the above rules results in an error on the Google Play Console when you activate your APKs—you will be unable to publish your application until you resolve the error.
Fortunately, App Bundles can take care of the correct versioning of the APKs for us.
Note: bundletool is an underlying tool which is used by Gradle, Android Studio and Google Play to generate split APKs according to the variants and it handles the correct versioning of the APKs itself.
Each APK must not exactly match the configuration support of another APK.
This is a very simple mistake that can happen with anyone. When creating multiple APKs, make sure that every APK is different from other in some form of configuration.
As bundletool is generating the split APKs for us, this problem can never surface.
Until now, you saw the advantages that Android App Bundles have over Multiple APKs. But everything has its pros and cons…
Let’s compare the filters/configurations available when working with both:
- Support different OpenGL texture compression formats with each APK.
- Support different screen sizes and densities with each APK.
- Support different device feature sets with each APK.
- Support different platform versions with each APK.
- Support different CPU architectures with each APK.
- Optimize for entry-level devices such as those running Android (Go edition).
Android App Bundles:
- Support different CPU architectures with each APK.
- Support different device feature sets with each APK. (Dynamic Delivery)
- Support different device resolutions
- Support different regions by locale.
Splitting the APKs based on OpenGL texture and platform versions is not available for now, but in the future, it may be.
There are some known issues with bundles that you can read about on the official documentation and Google Issue Tracker. So, you might want to investigate further to see if they can affect your product in some way.
Considering the above pros and cons, it seems that AAB is often the correct approach if you want to support different devices and reduce the size of your APK. There are some minor cons, but they should not be a deal-breaker considering many companies have already started using AAB in their production apps.