Android App Bundle



The Android App Bundle (AAB) is Android’s new, official publishing format. It offers a more efficient way to build and release your apps. AAB enables easier deliver of a great experience in a smaller app size, which can improve installation process. I will not go into to much details, but you can check more about Android App Bundle format and it’s benefits here:

For start, let’s quickly check more evident cons and pros of AAB vs. “classical” APK.


Manage releases more efficiently: Before AAB, if developer wanted to create a device-specific APK, several packages needed to be build and maintained. Let’s say, if you wanted to optimize APK for different resolution devices, several APKs needed to be build, maintained and deployed to Google Play Store. Now, with AAB, this is done automatically. AAB format slice down common and device-specific modules and deploys only needed packets onto installing Android device.

Smaller Apps: As stated before, with AAB Google Play Store deploys only device required artifacts. On deploy, it will not ship unused artifacts like: images with non-target device resolution, or binaries compiled for other-then-targeting CPU architecture, or language packs not installed/available on target device, etc…


On the other hand, there are some drawbacks by introducing AAB into development process, most notable:

Testing: Application testing is maybe a little bit more difficult with AAB bundle format. With APK I could simply deploy APK to target Android device, install it and run. With AAB this is not an option. You can test you app with Google Play Store and Beta program, for example. On deployment, Google Play Store automatically identifies installing target device and ships only artifacts needed for that specific device.

As of this writing, Visual Studio AppCenter does not support AAB bundle format. This is very bad, because, especially for Xamarin developers, Visual Studio App Center is very popular tool to build, deploy and test of mobile apps – especially Xamarin.Forms.

As I can not not directly deploy and test my AAB bundles on my Android due to AAB format, I will show one possible solution to this situation. In the next two sections, I will show one relative simple approach how I can deploy and test my AAB-packed application on my local Android device.

How to split AAB to APK modules

Let’s say, I have my app packed in AAB bundle format. I described one way how to create AAB format for Xamarin.Forms application in my blog post entitled: Xamarin.Forms: Create Android App Bundles with Azure DevOps.

First, I need bundletool from Google. I can find this tool here: In my case, I used (as of this writing) the latest release version:

If I want to split my ABB on APK splits I run this command in my console:

In my “.\out\” folder I have si.jenx.mydemo-Signed.apks file. This file contains sliced down application on “elementary” modules. This *.apks file is basically compressed zip file.

If I want to create APK for my local connected device, I need adb (Android Debug Bridge, which handles connection and deployment of my application from my development machine to connected Android device. Finally, I execute this batch script in my console:

Now, I have these two files in in my .\out folder:

First file, containing all APK modules is approx 70MB in size. Second one is containing only artifacts for my local Android and it’s about 30MB in size. As said before, these two files are nothing more then compressed zip files – after unzipping I can observe content of both. First file contains sliced down application of all elementary parts: language packs, different resolution-resources packs, cpu-target packs and similar, e.g.:

Second file is my local-device-specific. It contains only needed modules for my Android device. The content is significantly reduced, as you can see below:

I have 3 languages installed or enabled on my Android device: Slovenian, English and German – and this is reflected also my output: only these three locales will be deployed on my device when I download app from Google Play. Furthermore, my device has xxhdpi-based density display, thus, only xxhdpi-based resources will be shipped on my device on installation. And because my Android phone is running on armeabi-v7a 32-bit ARM-based CPU – only binaries for this CPU will be installed. Pretty awesome.

So, AAB is sliced-down to minimum – it contains only required APK modules for my device. Google Play Store handles uploaded AAB file exactly the same way. It slice down AAB on all possible variants and deploys only optimal application, all because it knows your target device configuration.

Install AAB on my local Android device

As before, for installation AAB packed application on my locally connected Android, I will again use Google bundletool and Android Debug Bridge (or adb). Script command for deploying my app onto my locally connected Android Device is as follows:

After I run this script, my app is successfully deployed on my Android.

In the next section I will compare the installed application size, pushed via “classical” APK or with AAB bundle.

Comparing app size deployed with APK vs. AAB

I checked my apps size deployed with APK and with target specific AAB deploy. The result is:

I reduced the app size for approx. 21%. Awesome, do you agree?

You can also check some AAB dynamic delivery improvements for some popular Google apps:


AAB bundle format is relatively new deployment format for Android applications. It brings many benefits, some of them are also mentioned in this blog post.

In the future, AAB will be de-facto-standard to deploy Android based apps on Google Play Store. Google is really pushing hard in this direction.

In this blog post I quickly investigated AAB bundle format and how to install and test ABB-bundle-based applications on locally connected Android Devices.

Until next time, happy coding.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.