AAB, the Android App Bundle, is the publishing format in which developers upload an Android app to a store, which then generates optimized APKs for each device from it. In mobile distribution, the AAB is an upload artifact rather than an installable file: it contains all code and resources for every device configuration, and the store delivers only what a particular phone needs.
Google Play has required the AAB format for new apps since August 2021. The result for users is a smaller download, and for developers a single build that covers every screen density, CPU architecture and language.
How an Android App Bundle is turned into APKs
An AAB is a ZIP archive with a .aab extension, organized into modules. Each module holds compiled code, resources in a protocol buffer format and a manifest. When the bundle is uploaded, the store uses a tool equivalent to the open-source bundletool to produce a set of split APKs.
At install time, the store selects the base APK plus the configuration splits that match the device, for example only arm64 native libraries, only xxhdpi images and only the languages the user has set. Android installs this combination as one app.
The table shows the kinds of APK the store generates from a bundle.
| APK type | Contents | Delivered to |
|---|---|---|
| Base APK | Core code and shared resources | Every device |
| ABI split | Native libraries for one CPU architecture | Devices with that architecture |
| Density split | Images for one screen density | Devices with that density |
| Language split | Strings for one or more languages | Users with those languages set |
| Feature module APK | Optional feature code and resources | On install or on demand |
| Standalone APK | Merged universal package | Very old Android versions |
AAB compared with APK, IPA and other formats
The AAB and the APK play different roles. The APK is the installable package that runs on a device; the AAB is the publishing package from which the store builds APKs. An AAB cannot be installed directly on a phone without first converting it with bundletool.
| Format | Platform | Role | Installable directly |
|---|---|---|---|
| AAB | Android | Upload format for stores | No |
| APK | Android | Installable package | Yes |
| Split APKs | Android | Device-specific parts of one app | Yes, as a set |
| IPA | iOS | Signed app archive | Only on permitted devices |
On iOS, a comparable outcome is achieved by app thinning, in which the App Store delivers device-specific variants of an uploaded IPA. The ideas are similar, but the Android bundle exposes modules and splits more explicitly to the developer.
Signing and delivery features of the AAB
Because the store generates the final APKs, it must also sign them. Publishing an AAB on Google Play therefore requires Play App Signing: the developer signs the bundle with an upload key, and the store signs the generated APKs with the app signing key it holds.
This arrangement has a practical advantage: a lost upload key can be reset through the store, whereas losing the signing key of a self-signed APK made app updates impossible. It also means that the developer trusts the store with the final signing key, a trade-off some organizations evaluate carefully. Optional code transparency files let developers verify that the delivered code matches what they built.
| Feature | What it does | Typical use |
|---|---|---|
| Install-time module | Installed together with the base app | Core but separable features |
| On-demand feature module | Downloaded when the user needs it | Rarely used tools or editors |
| Conditional module | Installed only on matching devices | Features needing specific hardware |
| Play Asset Delivery | Delivers large asset packs | Game textures and levels |
| Play Feature Delivery | Manages feature module delivery | Reducing initial install size |
Building and testing an AAB
Android Studio and the Android Gradle Plugin build an AAB with the bundleRelease task. Before uploading, teams should test exactly what users will receive, since a bundle that compiles correctly can still produce a broken split combination.
- Build the release AAB and sign it with the upload key.
- Use bundletool build-apks to generate the APK set locally.
- Install it on test devices with bundletool install-apks.
- Upload to an internal testing track for real store delivery.
- Promote through closed and open testing to a staged app rollout.
The store also enforces size limits on the compressed download of the base and install-time modules, which pushes large games toward asset packs and on-demand delivery.
Common AAB pitfalls
Most AAB problems appear when code makes assumptions that hold for a universal APK but not for split delivery. The table lists the frequent ones.
| Problem | Cause | Remedy |
|---|---|---|
| Missing language in app | In-app language picker uses an absent split | Request language splits or disable language splitting |
| Crash on sideloaded copy | User copied only the base APK | Detect missing splits and prompt reinstall |
| Native library not found | Library loaded from the wrong path | Load libraries through the standard loader |
| Lost signing control | Assumed the APK signing key is local | Plan key management for Play App Signing |
Teams that also distribute outside Google Play must remember that other stores and enterprise channels may still require APKs, so their release process should produce both formats from the same source.
The idea in brief
An AAB is the package a developer sends to the app store. It contains everything the app could ever need, for every kind of phone and every language.
The store then packs a custom version for each phone. It is like ordering furniture: the warehouse holds every color and size, but the delivery truck brings only the pieces that fit one home. The result is a smaller download and less used storage on the phone.
A practical scenario
A language learning app ships a universal APK of about 95 MB, with native audio libraries for four CPU architectures, images for five screen densities and course strings in 30 languages. Many users on limited data plans abandon the download.
The team switches to an AAB, moves offline lesson packs into an on-demand feature module, and tests the generated APK sets with bundletool on old and new devices. Testing reveals that the in-app language selector fails for languages that were not delivered, so the app now requests the language split before switching.
After release, a typical phone downloads a package less than half the size of the old universal APK. Install completion improves, and the same AAB keeps serving every device configuration from a single upload.