Android App Bundles (AAB) was launched at Google I/O 2018 and has since been adopted by many companies to reduce their app sizes. So, it makes sense to compare what AAB offers with Multiple APKs to see which tool is more effective and why.

AAB is a vast improvement over the previous multi-apk feature that required huge development efforts. Multiple APKs is a feature on Google Play that 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 essential 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. 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 the 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 0401 or 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 for API level 16 (and above) and small-large screens, and another APK for API level 21 (and above) and large-extra large 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 for API level 16 (and above) and small-standard screens, and another APK for API level 21 (and above) and large-extra large 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 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 an ARMv7 CPU, the APKs overlap on this characteristic. 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 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 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,  Android Bundles can take care of the correct versioning of the APKs for us.

Note: bundletool is an underlying tool used by Gradle, Android Studio, and Google Play to generate split APKs according to the variants. It handles the correct versioning of the APKs itself.

Each APK must not exactly match the configuration support of another APK.

This is an elementary mistake that can happen to anyone. Therefore, when creating multiple APKs, ensure that every APK is different from others in some form of configuration.

As bundletool is generating the split APKs for us, this problem can never surface.

But…

Until now, you have seen 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:

Multiple APKs:

• 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 other 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](https://issuetracker.google.com/issues?q=Android App Bundles). So, you might want to investigate further to see if they can affect your product in some way.

Conclusion

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. Of course, 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.

‍