Android App Bundle (AAB): What Actually Happens After You Upload Your App to Google Play

Most Android developers know that Android App Bundles (.aab) replaced APKs as the publishing format on Google Play.
But many developers still treat it like just another build artifact generated by Android Studio.
In reality, AAB completely changes how Android apps are packaged, optimized, and delivered to users. Once you understand what's happening behind the scenes, a lot of Android architecture decisions start making more sense.
Let's break it down.
The Old World: APK Delivery
Before App Bundles, Android apps were distributed as a single universal APK. That APK contained everything: all CPU architectures, all screen densities, all languages, all resources, all native libraries.
Even if a user only needed a tiny portion of that package, they still downloaded the entire file.
Example device configuration: CPU arm64-v8a, screen xxhdpi, language English. But the APK still contained x86 libraries, mdpi/hdpi resources, and every language translation.
Which meant larger downloads, slower installs, higher failure rates on poor networks. For global apps with millions of users, this inefficiency becomes very noticeable.
Enter Android App Bundles
Android App Bundles change the entire distribution pipeline. Instead of uploading a ready-to-install APK, developers upload a bundle of code and resources. Google Play then generates device-specific APKs dynamically during installation.
This means users only download what their device actually needs.
What an AAB Actually Contains
When you generate an .aab file from Android Studio, you're packaging modules and resources, not an installable app. A simplified structure looks like this:
base/
├── manifest/
├── dex/
├── res/
├── lib/
└── resources.pb
feature_login/
feature_payment/
feature_chat/
There are three important concepts here.
1. Base module. The base module is required. It contains the application entry point, core code, essential resources, and startup components. Without the base module, the app cannot launch. Think of it as the minimum runnable version of your app.
2. Dynamic feature modules. These allow parts of the app to be downloaded only when needed — login systems, payment flows, chat modules, AR features, onboarding experiences. Instead of shipping everything during installation, these features can be installed on demand. This is extremely useful for large apps with many optional features.
3. Resource optimization (resources.pb). Inside the bundle you'll also see resources.pb, which stores resources in protobuf format instead of XML. Benefits include faster processing inside the Play pipeline, optimized resource indexing, and a smaller metadata footprint. This is also why .aab files cannot be installed directly — they must first be processed by Google Play.
What Happens After You Upload the Bundle
Once an App Bundle is uploaded to Google Play, it enters the Play App Bundle processing pipeline. Several things happen automatically.
Step 1 — Bundle validation. Google Play checks manifest integrity, module dependencies, signing configuration, and bundle structure. If something is incorrect, the upload fails.
Step 2 — Optimization. Google Play performs additional optimization on resources, native libraries, and language assets. This step contributes significantly to APK size reduction.
Step 3 — Split APK generation. Instead of generating a single APK, Google Play produces multiple split APKs, assembled dynamically based on the device. Three major types are created:
- Base APK — contains the core functionality: main activities, essential resources, startup logic.
- Configuration APKs — generated based on device configuration: ABI splits (
arm64-v8a,armeabi-v7a,x86), density splits (ldpithroughxxxhdpi), and language splits (en,hi,fr,ja,ar, etc). Each device downloads only the configuration it needs. - Dynamic feature APKs — if your app uses dynamic feature modules, separate APKs are generated for them, delivered during installation, when a feature is requested, or via the Play Core API.
The Actual Delivery Flow
When a user installs the app from Google Play:
- Google Play reads the device configuration — e.g. ABI
arm64-v8a, densityxxhdpi, languageen. - Google Play generates a custom APK set.
- The user downloads only the required files — e.g.
base.apk,config.arm64_v8a.apk,config.xxhdpi.apk,config.en.apk.
This dramatically reduces download size.
Why This Matters in Production Apps
Smaller install size. Many apps see 15–30% smaller install packages. Apps with heavy native libraries or multiple languages can see even larger reductions.
Better install success rates. Large APKs frequently fail on slow mobile networks, unstable connections, and low-storage devices. Smaller downloads significantly improve install completion rates.
Dynamic feature delivery. Teams can ship features only when users actually need them — video editing tools, advanced filters, ML models, AR experiences. This keeps the base install lightweight.
Play Asset Delivery. For large assets like game textures or machine learning models, Android provides Play Asset Delivery — assets can be installed during gameplay, downloaded on demand, or streamed in the background. This avoids shipping huge app binaries.
Practical Tips for Android Developers
- Design modular apps — separate core functionality from optional features.
- Move heavy libraries to dynamic modules — SDKs like payment SDKs, AR libraries, and ML frameworks can live outside the base module.
- Let Google Play optimize resources — language and density splits are handled automatically by the App Bundle pipeline.
- Use
bundletoolfor testing — inspect generated APK sets locally and simulate installs across different device configurations.
Final Thoughts
Android App Bundles are not just a publishing requirement. They represent a device-aware distribution system designed to make Android apps smaller, faster to install, and easier to scale.
Once you start thinking in terms of modules, features, and device-specific delivery, you begin to see App Bundles as an architecture tool — not just a packaging format.
And that shift changes how modern Android apps should be built.
No spam, no schedule — just an email when a new post goes up.