Google is committed to advancing racial equity for Black communities. See how.

About Android App Bundles

An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.

Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app. You no longer have to build, sign, and manage multiple APKs to optimize support for different devices, and users get smaller, more-optimized downloads.

Additionally, you can add dynamic feature modules to your app project and include them in your app bundle. These modules contain features and assets that you can choose not to include when users first download and install your app. Using the Play Core Library, your app can later request to download those modules. Google Play will serve only the code and resources for that module to the device. When you combine this with support for uncompressed native libraries, larger apps (such as games) can reduce their storage requirements and increase user retention.

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

With Android App Bundles, the compressed download size restriction is now 150MB. You cannot use the app bundle with APK expansion files.

If you're using Android Studio 3.2 or higher, you can build an Android App Bundle in just a few clicks. However, adding dynamic feature modules will require more effort as it may involve refactoring pieces of your app.

This page describes the steps to get started building Android App Bundles and describes some important concepts related to app bundles and Dynamic Delivery.

Get started

To build app bundles and support Dynamic Delivery, follow these steps:

  1. Download Android Studio 3.2 or higher—it's the easiest way to add dynamic feature modules and build app bundles.

  2. Add support for Dynamic Delivery by including a base module, organizing code and resources for configuration APKs, and, optionally, adding dynamic feature modules.

  3. Build an Android App Bundle using Android Studio. You can also deploy your app to a connected device from an app bundle by modifying your run/debug configuration and selecting the option to deploy APK from app bundle. Keep in mind, using this option results in longer build times when compared to building and deploying only an APK.

  4. Test your Android App Bundle by using it to generate APKs that you deploy to a device.

  5. Enroll into app signing by Google Play. Otherwise, you can't upload your app bundle to the Play Console.

  6. Publish your app bundle to Google Play.

To build app bundles that include asset packs, see About Dynamic Asset Delivery.

The Android App Bundle format

An Android App Bundle is a file (with the .aab file extension) that you upload to Google Play.

App bundles are signed binaries that organize your app’s code and resources into modules, as illustrated in figure 1. Code and resources for each module are organized similarly to what you would find in an APK—and that makes sense because each of these modules may be generated as separate APKs. Google Play then uses the app bundle to generate the various APKs that are served to users, such as the base APK, dynamic feature APKs, configuration APKs, and (for devices that do not support split APKs) multi-APKs. The directories that are colored in blue—such as the drawable/, values/, and lib/ directories—represent code and resources that Google Play uses to create configuration APKs for each module.

App bundles organize your app into directories that each represent a
        module. Within each module directory, code and resources are organized
        similar to that of a typical APK.

Figure 1. The contents of an Android App Bundle with one base module, two dynamic feature modules, and two asset packs.

The following list describes some of the app bundle’s files and directories in more detail:

  • base/, feature1/, and feature2/: Each of these top-level directories represent a different module of your app. The base module for your app is always contained in a base directory of the app bundle. However, the directory for each dynamic feature module is given the name specified by the split attribute in the module’s manifest. To learn more, read about the Dynamic feature module manifest.
  • asset_pack_1/ and asset_pack_2/: For large, graphically-demanding apps or games, you can modularize assets into asset packs. Asset packs are ideal for games due to their large size limits. You can customize how and when each asset pack is downloaded onto a device according to three delivery modes: install-time, fast-follow, and on-demand. All asset packs are hosted on and served from Google Play. To learn more about how to add asset packs to your app bundle, see the Dynamic Asset Delivery overview.
  • BUNDLE-METADATA/: This directory includes metadata files that contain information useful for tools or app stores. Such metadata files may include ProGuard mappings and the complete list of your app's DEX files. Files in this directory are not packaged into your app's APKs.
  • Module Protocol Buffer (*.pb) files: These files provide metadata that helps describe the contents of each app module to app stores, such as Google Play. For example, BundleConfig.pb provides information about the bundle itself, such as which version of the build tools were used to build the app bundle, and native.pb and resources.pb describe the code and resources in each module, which is useful when Google Play optimizes APKs for different device configurations.
  • manifest/: Unlike APKs, app bundles store the AndroidManifest.xml file of each module in this separate directory.
  • dex/: Unlike APKs, app bundles store the DEX files for each module in this separate directory.
  • res/, lib/, and assets/: These directories are identical to those in a typical APK. When you upload your app bundle, Google Play inspects these directories and packages only the files that satisfy the target device configuration, while preserving file paths.
  • root/: This directory stores files that are later relocated to the root of any APK that includes the module that this directory is located in. For example, the base/root/ directory of an app bundle may include Java-based resources that your app loads using Class.getResource(). Those files are later relocated to the root directory of your app’s base APK and every multi-APK that Google Play generates. Paths within this directory are also preserved. That is, directories (and their subdirectories) are also relocated to the root of the APK.

Build and deploy Android App Bundles

An app bundle is different from an APK in that you can’t deploy one to a device. Rather, it’s a publishing format that includes all your app’s compiled code and resources in a single build artifact. So, after you upload your signed app bundle, Google Play has everything it needs to build and sign your app’s APKs, and serve them to users through Dynamic Delivery.

If you’re using Android Studio, you can build your project as a signed app bundle in just a few clicks. If you're not using the IDE, you can build an app bundle from the command line. Then, upload your app bundle to the Play Console to test or publish your app with Dynamic Delivery.

Test your app bundle

After you build your Android App Bundle, you should test how Google Play will use it to generate APKs and how those APKs will behave when deployed to a device.

To test your app bundle, use any of the following methods:

Download dynamic feature modules with the Play Core Library

If your app includes dynamic features, it needs to use the Play Core Library to request, monitor, and manage dynamic feature module downloads. To learn more, go to Download modules with the Play Core Library.

If you want to see the library in action, try the Play Core Library sample app.

A note about Instant Apps

In Android Studio 3.2 or higher, you can add an instant experience to an app bundle, as long as your app's size is small enough. For details on the size limits for the different types of instant experiences that you can create, see Overview of Google Play Instant.

Compressed download size restriction

Publishing with Android App Bundles helps your users to install your app with the smallest downloads possible and increases the compressed download size limit to 150 MB. That is, when a user downloads your app, the total size of the compressed APKs required to install your app (for example, the base APK + configuration APKs) must be no more than 150 MB. Any subsequent downloads, such as downloading a dynamic feature (and its configuration APKs) on demand, must also meet this compressed download size restriction. Asset packs do not contribute to this size limit, but they do have other size restrictions.

When you upload your app bundle, if the Play Console finds any of the possible downloads of your app or its on demand features to be more than 150 MB, you get an error.

Keep in mind, Android App Bundles do not support APK expansion (*.obb) files. So, if you encounter this error when publishing your app bundle, use one of the following resources to reduce compressed APK download sizes:

  • Make sure you enable all configuration APKs by setting enableSplit = true for each type of configuration APK. This makes sure that users download only the code and resources they need to run your app on their device.
  • Make sure you shrink your app by removing unused code and resources.
  • Follow best practices to further reduce app size.
  • Consider converting features that are used by only some of your users into dynamic feature modules that your app can download later, on demand. Keep in mind, this may require some refactoring of your app, so make sure to first try the other suggestions described above.

Known issues

The following are the currently known issues when building Android App Bundles or serving your app using Dynamic Delivery. If you experience issues that are not described below, please report a bug.

  • Partial installs of sideloaded apps—that is, apps that are not installed using the Google Play Store and are missing one or more required split APKs—fail on all Google-certified devices and devices running Android 10 (API level 29) or higher. When downloading your app through the Google Play Store, Google ensures that all required components of the app are installed.
  • If you use tools that dynamically modify resource tables, APKs generated from app bundles might behave unexpectedly. So, when building an app bundle, it is recommended that you disable such tools.
  • In a dynamic feature module’s manifest, you should not reference resources that don’t exist in the base module. That’s because, when Google Play generates your app’s base APK, it merges manifests for all modules into that of the base APK. So, resource linking breaks if the base APK’s manifest references resources that don’t exist in the base APK.
  • As of Android Studio 3.2 Canary 14, when you change the build variant for your app’s base module, the same build variant is not automatically selected for dynamic feature modules that depend on the base module. So, you might receive an error when building your app. Simply make sure that you select the same build variant for the base module and other modules that depend on it.
  • It is currently possible to configure properties in a dynamic feature module’s build configuration that conflict with those from the base (or other) modules. For example, you can set buildTypes.release.debuggable = true in the base module and set it to false in a dynamic feature module. Such conflicts might cause build and runtime issues. Keep in mind, by default, dynamic feature modules inherit some build configurations from the base module. So, make sure you understand which configurations you should keep, and which ones you should omit, in your Dynamic feature module build configuration.
  • Downloading dynamic feature modules requires devices to have a recent version of the Play Store app installed. So, if your app includes dynamic feature modules, downloads for a very small percentage of users may fall back to a single optimized multi-APK, which is the same download experience for devices running Android 4.4 (API level 20) and lower.

Additional resources

To learn more about Android App Bundles, consult the following resources.


  • PlayCore API sample, which demonstrates usage of the PlayCore API to request and download dynamic features.
  • Dynamic code loading sample, which demonstrates three different approaches to safely access code from an installed dynamic feature module.


  • Your First Android App Bundle, a codelab that explores the basic principles of Android App Bundles and shows you how to quickly get started with building your own using Android Studio. This codelab also explores how to test your app bundles using bundletool.
  • On demand modules, which helps you create an app that downloads and installs dynamic features on demand.

Blog posts