Save the date! Android Dev Summit is coming to Mountain View, CA on November 7-8, 2018.

About Android App Bundles

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

Google Play’s new app serving model, called Dynamic Delivery, then uses your app bundle to generate and serve optimized APKs for each user’s device configuration, so they download only the code and resources they need to run your app. You no longer have to build, sign, and manage multiple APKs to support 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 decide 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 as dynamic feature APKs, and, through Dynamic Delivery, Google Play serves only the code and resources for that module to the device.

Watch the following video for an overview of Android App Bundles and Dynamic Delivery.

If you’re using Android Studio, most app projects require little effort to support Dynamic Delivery, and you can build an Android App Bundle in just a few clicks. However, adding dynamic feature modules is still in beta, and requires a little more effort and possibly refactoring your app.

Dynamic Delivery with split APKs

A fundamental component of Dynamic Delivery is the split APK mechanism available on Android 5.0 (API level 21) and higher. Split APKs are very similar to regular APKs—they include compiled DEX bytecode, resources, and an Android manifest. However, the Android platform is able to treat multiple installed split APKs as a single app. With split APKs, Google Play can break up a large app into smaller, discrete packages that are installed on a user’s device as required.

The following describes the three kinds of split APKs, and figure 1 below illustrates the relationship of these APKs for a simple and more complex app.

  • Base APK: This APK contains code and resources that all other split APKs can access and provides the basic functionality for your app. This is the first APK that’s installed when a user downloads your app.
  • Configuration APKs: Each of these APKs includes native libraries and resources for a specific screen density, CPU architecture, or language. That way, when a device downloads a base or dynamic feature APK, it downloads only the libraries and resources it needs. For most app projects, you don't need to refactor your app to support configuration APKs, Google Play generates them for you from the code and resources you include in your app bundle.
  • Dynamic feature APKs: Each of these APKs contain code and resources that are not required when your app is first installed, but may be downloaded and installed later.

Figure 1. On the left: a simple app that includes a base APK (B) and some configuration APKs (C). On the right: a more complex app that includes two dynamic feature APKs (D) and corresponding configuration APKs (C) for download on demand.

Keep in mind, when you use an Android App Bundle, Google Play builds and serves all of your app’s APKs for you. And, for devices running Android 4.4 (API level 20) and lower, Google Play automatically serves a single APK that’s optimized for the device's configuration. So whether or not you plan to support devices running older Android devices, Dynamic Delivery provides a flexible serving mechanism for you and your users.

Most existing app projects require little effort to support Google Play’s new serving mechanism. That’s because the standard app module provides code and resources for your base APK and, with Android Studio, you can create dynamic features for your app in just a few clicks.

When you're ready to add support for serving your app with Dynamic Delivery, read Configure your project for Dynamic Delivery.

Build, deploy, and upload Android App Bundles

After you configure your app project to support Dynamic Delivery, you need to build a signed Android App Bundle in order to upload your app to Google Play.

An app bundle is different from an APK in that you can’t deploy one to a device. Rather, it’s a new upload 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 a signed app bundle in just a few clicks. Then, simply upload your app bundle to the Play Console to test or publish your app with Dynamic Delivery. To learn more about the Android App Bundle format, go to Build, deploy, and upload Android App Bundles.

Test your app bundle with bundletool

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

You can perform these tests locally using bundletool—the command line tool Gradle, Android Studio, and Google Play use to build an Android App Bundle or convert an app bundle into APKs that are deployed to devices. This tool is also useful for including app bundle support on your build server.

To learn how to download and use bundletool, read Test Android App Bundles with bundletool.

After testing your app bundle locally, you should then test it through Google Play by uploading your app bundle to the Play Console. A new internal test track allows you to upload an app bundle to the Play Console and start testing it on your device with Dynamic Delivery in just a few minutes.

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

Android App Bundles and apps on Google Play Instant both aim to enable app modularization, so you can create smaller, more optimized app experiences for users. And, in the future, app bundles will include support for instant apps. That is, you can publish your installed app and certain instant app experiences from a single app bundle.

So, whether you start with an Android App Bundle for your installed app or you’re already developing an Instant App, you’re on track to build an “instant-enabled” app bundle in the future.

Get started

When you decide that you want to support Dynamic Delivery and build an Android App Bundle for your app, follow these steps:

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

  2. Configure your project 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.

  4. Test your Android App Bundle using bundletool to generate APKs from your app bundle and deploy them to a connected device.

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

  6. Upload your app bundle to the Play Console. You can then use the Play Console's new internal test track to quickly test downloading your app via Dynamic Delivery.

Considerations for dynamic feature beta testers

If you want to publish an app that includes dynamic feature modules to a production track, you must first apply to the dynamic feature beta program. If you are accepted into the beta program, keep the following considerations in mind as you develop your dynamic feature(s):

  • Only devices running Android 5.0 (API level 21) and higher support downloading and installing dynamic features on demand. To make your dynamic feature available to earlier versions of Android, make sure to enable Fusing when you create a dynamic feature module.
  • Make sure you enable SplitCompat, so that your app has immediate access to downloaded dynamic feature modules.
  • If the dowload size for your dynamic feature is large, your app needs to obtain user confirmation before it can download the dynamic feature module to a device.
  • Dynamic feature modules should not specify activities in their manifest with android:exported set to true. That's because there's no guarantee that the device has downloaded the dynamic feature module when another app tries to launch the activity. Additionally, your app should confirm that a dynamic feature is downloaded before trying to access its code and resources. To learn more, read Manage installed modules.
  • Before you publish your app, be sure to thoroughly test your dynamic features using the Play Console's test tracks. To learn more, read Set up an open, closed, or internal test.

Additionally, make sure that you're aware of the known issues described in the section below.

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.

  • Android App Bundles do not support APK expansion files. However, Google Play still requires that app downloads be 100MB or less. So, for example, when first installing your app, the total size of your base APK and its configuration APKs must equal 100 MB or less. Similarly, the total size of any dynamic feature APK and its configuration APKs must be 100 MB or less. After uploading your app bundle, the Play Console warns you if your app bundle results in APKs that violate this restriction.
  • 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.
  • Because app installs may require downloading more than one APK (such the base APK and a few of its configuration APKs), you should be careful when manually transferring your app’s APKs onto a device (also known as sideloading). Otherwise, your app may experience runtime issues due to missing code and resources.
  • Currently, Google Play includes all the code and resources for a dynamic feature module in a single APK. In the near future, for devices running Android 5.0 (API level 21) and higher, serving will be optimized to use configuration APKs.
  • 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.