What is the AAB (Android App Bundle) format?

Why is AAB used to replace APK?

Google Play uses app bundles to create and distribute APK files that are optimized for each device configuration, so only the code and resources needed for a specific device are downloaded to run the app. . You no longer have to create, sign, and manage multiple APK files to optimize support for different devices, and users get smaller, better-optimized downloads.

Almost any application project will not require much effort to create application packages that support the delivery of optimized APK files. For example, if you've organized your app's code and resources according to established conventions, simply create a signed Android App Bundle using Android Studio or using the command line and upload them to Google Play. The optimized APK delivery then becomes a self-perpetuating benefit.

When you use the app bundle format to publish your app, you can also optionally take advantage of Play Feature Delivery, which allows you to add feature modules to your app project. These modules contain features and resources that are only included in your application, based on conditions that you specify, or are available after runtime for download using the Play Core Library.

Game developers who publish their apps with app bundles can use Play Asset Delivery: Google Play's solution to distribute large amounts of game content providing developers with different distribution methods. flexibility and high performance.

Watch the following video for an overview of why you should publish your app using Android App Bundles.

Compressed download size limit

Publishing using Android App Bundles helps users to install apps with the smallest possible download size and increases the compressed download size limit to 150MB.

That is, when the user downloads the app, the total size of the compressed APK files required to install the app (e.g. base APK + configuration APK) cannot be larger than 150MB. Any subsequent downloads, such as downloads of the feature module (and its configuration APKs) on-demand, must also meet this compressed download size limit. Content packs do not contribute to this capacity limit, but they do have other size limitations.

When you upload your apk, if the Play Console finds any possible downloads of the app or its required features larger than 150MB, you will get an error.

Please note that Android App Bundles do not support APK expansion files (*.obb). So, if you get this error when you publish your apk, use one of the following resources to reduce the compressed APK download size:

1. Make sure you enable all configuration APKs by setting enableSplit=true for each configuration APK type. This ensures that users only download the code and resources they need to run the app on their device.
2. Make sure you minify your app by removing unused code and resources.
3. Follow best practices to further reduce app storage.
4. Consider converting features that are only used by certain users into feature modules that your app can download later on demand. Note that this may require some refactoring of the application, so make sure to try the other suggestions described above first.

Some problems with Android App Bundles

The following are currently known issues when building or distributing apps with Android App Bundles.

Only partially installed sideload apps - i.e. apps that weren't loaded using the Google Play Store and are missing one or more of the required split APKs - failed to install successfully on all Google certified devices, and devices running Android 10 (API level 29) or higher. When downloading apps through the Google Play Store, Google ensures that all required components of the app are installed.

If you use dynamic resource tables modifiers, APKs generated from apks may behave unexpectedly. So when building an apk, you should disable those tools.

It is now possible to configure properties in a feature module's build configuration that conflict with those from the base module (or other module). For example, you can set buildTypes.release.debuggable = true in the base module and set it to false in the features module. Remember, by default, feature modules inherit some of the build configuration from the base module. So make sure you understand which configurations you should keep and which ones you should ignore, in your feature module build configuration.