What Is an AAB File? AAB vs APK Explained

The growth of Android applications and the diversity of device configurations created a need for a more efficient app distribution format. Google addressed this with the Android App Bundle (AAB) file.

Unlike APKs, AAB files allow the Google Play Store to generate device-specific installs, reducing download sizes, improving installation efficiency, and simplifying updates. Since 2021, an AAB submission is mandatory for publishing on the Google Play Store.

What Is an AAB File?

An AAB file, or Android Application Bundle file, is a publishing format for Android applications and is the standard on the Google Play Store. This means Android applications should be uploaded as .aab file rather than other formats.

Key points about AAB files:

• Modular Structure: The application is divided into different modules, with each module containing its respective resources and code.
• Optimized Process: AAB files were introduced to optimize the app upload and download process. Unlike APKs, which were built and signed for specific device configurations, AAB files reduce overhead.
• No Multiple APKs Needed: Previously, developers had to create multiple APKs for different devices. With AAB, this requirement is eliminated.
• Non-Proprietary Format: The AAB format, including its extension, file types, and architecture, is not proprietary or licensed by Google.
• Open Source: AAB is open source, with no restrictions on using it in other app stores.
• Google Play Standard: Google Play uses AAB as the standard format for app publishing.

Why Google Mandated AAB for Android Apps?

Google mandated the AAB format for new apps on the Play Store starting in August 2021. The main reason was to optimize app distribution and improve user experience.

Here’s a breakdown of why:

• Fewer App Downloads: AAB allows Google Play to generate optimized APKs for each device configuration. Instead of downloading a one-size-fits-all APK containing all resources and code for every device, users get only what their device needs. This reduces app size, which saves bandwidth and storage.
• Dynamic Delivery: With AAB, you can use dynamic features, meaning certain parts of the app can be delivered on demand rather than included in the initial download. For example, you can download a heavy feature only when the user actually needs it.
• Better Performance and Efficiency: Smaller, device-specific APKs lead to faster installs, fewer crashes, and better runtime performance because unnecessary resources aren’t included.
• Future-Proofing Android Distribution: Google wants a more modular ecosystem where apps are flexible, updatable, and lean. Mandating AAB helps you adopt modern practices that will scale with device diversity.
• Enhanced Security and Play Store Management: AAB puts Google in charge of generating the APKs. This gives Google more control over signing and delivering the app securely, reducing risks of tampering.

Note

Test your AAB and APK files on real Android devices. Try LambdaTest Today!

AAB vs APK: Key Differences

AAB and APK have clear distinctions, with AAB having an edge over APK files. These differences can be documented as follows.

Features of an AAB File

AAB comes with beneficial features contributing to its popularity:

• Split APK: AAB works with split APK bundles where multiple APKs are generated for different functionalities, such as multiple language support. They can be requested and downloaded as per requirements.

• Highly Organized Structure: The .aab file comes with a modular structure with directories, resources, and code arranged according to the modules. This not only helps in providing a clean structure but also helps Google to understand the relevance of each module and download and select only the required modules during the download.

• On-Demand Download: The best feature of .aab files is to get the flexibility of choosing the modules as per wish (Play Feature Delivery) and downloading on demand.

• Minimum Size Possible: Since only device-specific modules are downloaded and optional modules are selected by the users, the final APK is the most concise and optimized APK for the device.

• Single File Upload: AAB format brings down the number of uploads to the application store to just one. This is in contrast to uploading multiple APKs as done before AAB became the standard.

• Consistent Signing: AAB format shifts the signing process of APK from the developer to Google. Therefore, there are no risks of losing confidential keys, and the process remains consistent.

Anatomy of an AAB File

The anatomy of an AAB file consists of various modules that wrap code and resources into it. The arrangement looks as follows:

• base/, feature1/, feature2/: These are different modules of the application, located in separate directories. They contain their respective resource and code. However, the base/ module must always be present in the base directory.

• asset_pack_1/, asset_pack_2: When the application has too many or too large graphical elements, they are kept inside these modules. They are uploaded to Google Play, and the you can decide when and how to download them to the application. The downloading methods include install-time, on-demand, and fast-follow.

• BUNDLE-METADATA/: This is a directory that contains all the metadata files for the application.

• Protocol Buffer (.pb) Files: Every module contains .pb files that provide the metadata for the module. Different .pb files provide different types of metadata. For instance, assets.pb provides asset metadata for the module and BundleConfig.pb provides metadata for the bundle. This helps Google Play Store understand what modules and resources to download for which device.

• manifest/: The directory is provided to each module that contains the AndroidManifest.xml file, which provides information about the module. This is in contrast to APK files that contain only one AndroidManifest.xml file.

• dex/: Used to store the dex files. Unlike APK, AAB files come with one dex/ directory (and its respective dex files) for each module.

• res/, lib/, and assets/: Contains resources, lib, and asset files for each module. It helps the Google Play Store in making a better selection while considering files according to the target device.

• root/: The root/ directory contains files that are moved to the root directory of the APK, where this module will also be present. The subdirectory structure from this directory is also maintained in the downloaded application.

How to Build and Sign an AAB File?

The .aab file can be built and signed through either Android Studio or via the command line.

Building and Signing an AAB file via Android Studio

To build an AAB file from Android Studio:

1. Go to Android Studio > Build > Generate Signed Bundle / APK.







2. Select Android App Bundle on the next screen and click Next.
3. The next screen will ask for the Key store path and Alias for the same. This is used for signing the .aab file that will be packed after the build.







4. The next screen will ask for the build type to choose between release and debug. You can choose release for uploading to the Google Play Store or debug if you are testing the application.
5. Select Finish to finish the build process, and the .aab bundle will be available in the /app/build/outputs/bundle/release if release was chosen as the build variant or /app/build/outputs/bundle/debug/ if debug was chosen.

Building and Signing an AAB File via Command Line

You can build and sign the .aab file using the command line through either Gradle or bundletool.

Below are the steps for each method:

• Building .aab via Gradle for debug: /gradlew :base:bundleDebug
• Building .aab via Gradle for release: ./gradlew bundleRelease
• Building .aab via bundletool: bundletool build-bundle –modules=base.zip –output=mybundle.aab

Note: The bundletool option is slightly more advanced than Gradle because it requires additional information. For instance, it asks for zip files for each module that contain its resources and code. The “base.zip” file mentioned in the command above corresponds to the base module zip.

Signing an AAB File via Command Line

After building the .aab file, it must be signed before uploading to the Google Play Store. You can do this in two ways:

• Using Gradle: If your build.gradle.kts file contains signing information, Gradle can sign the file automatically during the build process.
• Using jarsigner: If signing is not configured in Gradle, or if you used bundletool, you can manually sign the file using jarsigner.

  Command: jarsigner -keystore app-release.aab

Signing the file is required to publish it on the Google Play Store.

Converting AAB File to APK File

AAB is a purely publishing format, and you cannot install it directly on the systems. Hence, before commencing the testing session, it is important to convert the .aab file to a .apk file, which can be achieved through various methods.

Uploading Directly to the Google Play Store

The .aab file can be converted to .apk by the Google Play Store automatically, which is the standard process followed during the release. This can be done by building the .aab file through the methods described above, and then uploading the file to the Google Play Store.

Through Bundletool

Google Play Store uses bundletool internally to convert the .aab file to the .apk file. Therefore, it recommends using the same methods for local conversions.

The following command will create an .apk file from a .aab bundle using bundletool:

bundletool build-apks –local-testing –bundle my_app.aab –output my_app.apks

In this command, the “local-testing” flag is used to include the local testing manifest in the generated APK. This helps Play Delivery Library understand that the current APK needs to be used just for local testing, and therefore, the Google Play Store is not connected.

This method will generate multiple APKs. Hence, expect a big-sized file as the output. Installing it in the device will pick up the correct APK according to the device, with a reduced size.

Building a Universal APK

To avoid having many split APKs and choosing from them, you can build a universal APK (which will be big in size). The following command will be used for this process:

java -jar bundletool-all.jar build-apks –bundle=app-release.aab –output=app.apks –mode=universal

This option will be quick but doesn’t provide some of the AAB-associated features, such as on-demand download and downloading only the required resources as per the device from the pool of multiple APKs.

All three of these methods will provide an APK file from the AAB package, which can then be installed and tested as described in the next section.

Ways to Test an AAB File Locally

Once you have converted an AAB file to APK file, the following ways can be used to perform Android app testing in a local environment.

• Google Play Store: Uploading the AAB files and downloading through the Google Play Store directly is one quick option. However, this would publish the application (release it) and hence, is not a recommended method of Android app testing.
• Google Play Console: To avoid releasing to the users without testing, Google provides the option of Google Play Console where the developers can upload and provide the build to only a set of testers that they choose. It is the closest one can get to the actual “build-upload-release” process and allows remote teams to get the builds in seconds.
• Physical Devices: Once the APK is built on the local environment, or if uploaded to the Google Play Console remotely, the testers can use a real physical device to download the application. However, testing through this method requires high budgets due to the procurement of many physical devices.
• Third-Party Android Emulators and Android Studio: APK files can also be directly loaded on the downloaded emulators in Android Studio by either drag-and-drop or installing the .apk file through adb. However, one must note that all work done on Android Studio, including testing on emulators, consumes local resources and hence, should not be a primary testing option.
• Bundletool: When APKs are developed using bundletool, they can be installed either by providing all the split APKs or a universal APK name.

When Using multiple APKs:

java -jar bundletool-all.jar install-apks –apks=

This method will select the target APK directly.

When using a universal APK:

Universal APK can be installed using the ADB command below:

adb install universal.apk

This will install the file on the emulator directly through the terminal.

How to Test AAB Files With LambdaTest Real Device Cloud?

Cloud testing platforms like LambdaTest provide an efficient way to test AAB files on a real device cloud. Instead of being limited to a single local setup, you can run tests on real Android devices across multiple Android versions, devices, and operating systems.

Key Features:

• Mobile App Testing: Upload and run your mobile apps on real Android devices to ensure smooth installation and functionality.
• Android Device Testing: Validate app functionality and behavior across different Android OS versions and device models.
• Android Automation Testing: Use popular frameworks like Appium or Espresso to automate test cases for your AAB files.
• Online APK Emulator: You can even test your convered APK files on cloud-hosted Android emulators without needing local device lab.

To get started, refer to this documentation on real device app testing on LambdaTest.

Challenges With the AAB Files

While AAB seems to be the correct path to have been laid down for application publishing, it does come with certain challenges and limitations.

• Additional Build Process: Building an APK from the .aab file requires additional steps that were not required before. It makes the build and conversion process challenging for developers, especially when some of the third-party sources are still working on .apk directly as before.

• Increase Testing Complexities: Testers cannot keep their APK files and distribute them among the team for testing. They need to install it using multiple APKs, depending on the target device, which demands time and is not desirable for testers, especially while doing manual testing.

• Size Issues While Testing: When an AAB file is built, it generates split-APKs, among which the files are selected for installation on the target device. This is an issue for testers, as they are not able to ascertain what size will be downloaded at what point on the device, and how it will impact the performance.

• Sideloading Issues: AAB is a Google initiative. Since Android allows the download and installation of APKs from third-party sources, the process is not so smooth now. Every third-party source has not modified its platform to provide conversion and signing, and the ability to judge the right split APKs and configure them correctly. The inconsistent signing has also created issues, leading to frequent crashes and unpredictable behavior.

Troubleshooting Common Issues With the AAB Files

Here are the common issues developers encounter when creating or uploading Android App Bundle files and how to resolve it.

• Build Task Not Recognized: If :base:bundleDebug or bundleRelease fails with “task not found,” make sure you’re using the correct module name. Replace :base: with your actual module name (for example, :app:bundleDebug). Also confirm you are running commands from the project root where the gradlew script is located.

• Unsigned AAB File: The Play Store rejects unsigned bundles. If you use Gradle, check that your build.gradle.kts file includes a properly configured signingConfigs block. If you use bundletool, sign the file manually with jarsigner.

• Incompatible Java Version: The Android Gradle Plugin usually requires Java 11 or higher. If builds fail unexpectedly, verify your version with java -version and install a supported JDK.

• Google Play Upload Errors: Errors like “missing resources” or “no native code” often mean the bundle was built incorrectly. Ensure each module is packaged as a zip file with compiled code and resources, and that a base module base.zip is included.
• Debug Build Uploaded Instead of Release: The Play Store only accepts signed release builds. Always use ./gradlew bundleRelease to generate the publishable file, not bundleDebug.

Conclusion

Google has mandated, since August 2021, to upload .aab files instead of .apk files on the Play Store for users to download. This was done as a measure to streamline the signing process and manage the increasing size of applications to provide a better solution for developers and users.

Developers build and upload .aab files, which contain multiple APKs, and Google signs them and downloads only those APKs that are required for that device. This is a better choice for the users, but it increases the work of developers and testers.

Not to mention it comes with its challenges, which have become part of the Android application development process. This post balances these two sides for the introduction of AAB and provides a clear view of why it was introduced, how it can be built and tested, and why managing them is a topic of discussion sometimes.

Citations

• Android App Bundles: https://developer.android.com/guide/app-bundle/

Harish Rajora

Harish Rajora Software Developer 2 at Oracle India with over 6 years of hands-on experience in Python and cross-platform application development across Windows, macOS, and Linux. He has authored 800 + technical articles published across reputed platforms. On LinkedIn, he is followed by a community of 1,500+ QA engineers, developers, DevOps specialists, and tech leaders. He has also worked on several large-scale projects, including GenAI applications, and contributed to core engineering teams responsible for designing and implementing features used by millions. He has completed his post-graduation with an M.Tech in Software Engineering from the Indian Institute of Information Technology (IIIT) Allahabad. I have worked extensively with Django, shell scripting, and led DevOps initiatives, building CI/CD pipelines using Jenkins, AWS, GitLab, and GitHub. Over the years, he has emphasized the importance of planning, documentation, ER diagrams, and system design to write clean, scalable, and maintainable code beyond just implementation.

See author's profile