APK vs AAB: Everything You Need to Know About Android App Formats
A deep dive into what APK and AAB files are, how they work, who created them, and why the Google Play Store prefers AAB over APK.
APK vs AAB: Everything You Need to Know About Android App Formats
If you’ve ever tried to install an Android app manually or upload one to the Google Play Store, you’ve probably come across two file formats — APK and AAB. They might sound similar, but they work very differently. Let’s break it all down.
What is an APK File?
APK stands for Android Package Kit (sometimes also called Android Application Package).
An APK file is the traditional packaging format for Android apps. Think of it like a ZIP file — it bundles together everything an app needs to run: the compiled code, resources, assets, images, fonts, and a manifest file that tells Android what the app is and what permissions it needs.
When you install an app from outside the Play Store (a process called sideloading), you’re almost always using an APK file.
What is an AAB File?
AAB stands for Android App Bundle.
An AAB is a newer publishing format introduced by Google. Unlike an APK, an AAB is not meant to be installed directly on a device. Instead, it’s an upload format — you send it to Google Play, and Google Play takes care of generating the right APK for each specific device.
Why Can You Install an App with APK but NOT with AAB?
This is a great question. Here’s the core difference:
-
An APK is a complete, self-contained package. It contains everything needed for every device — all screen sizes, all processor architectures, all languages. You hand it to Android, and Android installs it. Done.
-
An AAB is more like a blueprint or a source package. It contains all the possible resources split into modules, but it does not compile them into a ready-to-install format. It needs Google Play’s infrastructure — specifically a system called Dynamic Delivery — to process it and generate a device-specific APK before installation.
So an AAB file on its own is incomplete from the device’s perspective. Your phone doesn’t know how to read it. Only Google’s servers do.
Why Does Google Play Require AAB Instead of APK?
Since August 2021, Google has required new apps on the Play Store to be submitted as AAB files instead of APKs. Here’s why:
1. Smaller App Size for Users
A traditional APK includes resources for every possible device — every language, every screen density, every CPU architecture. Most of that data is irrelevant to any single user.
With AAB + Dynamic Delivery, Google Play generates a customized APK for each device. A user with a medium-screen phone in English gets only the resources they actually need. This can reduce app download size by up to 65%.
2. Better Performance
Smaller installs mean faster downloads, faster installs, and less storage used on the user’s phone.
3. Modular Features
AAB supports Play Feature Delivery, which lets developers ship optional parts of an app only when the user actually needs them — instead of bundling everything upfront.
Who Created the AAB Format?
The Android App Bundle (AAB) format was created by Google. It was introduced at Google I/O 2018 and was designed to modernize how Android apps are distributed. Google developed it as part of a broader initiative to make apps smaller, faster, and more modular through their Dynamic Delivery system.
The APK format, on the other hand, has existed since the very beginning of Android. It was created by Google and the Open Handset Alliance when Android was first launched in 2008, based on the JAR (Java Archive) format.
Full Meanings at a Glance
| Abbreviation | Full Form |
|---|---|
| APK | Android Package Kit |
| AAB | Android App Bundle |
Which Programming Languages Can Produce APK and AAB Files?
Both APK and AAB files are outputs of the Android build process, not of a specific language. That said, here are the languages and frameworks that can produce them:
Languages & Frameworks that can build APK & AAB:
| Language / Framework | APK | AAB |
|---|---|---|
| Java | ✅ | ✅ |
| Kotlin | ✅ | ✅ |
| Flutter (Dart) | ✅ | ✅ |
| React Native (JavaScript) | ✅ | ✅ |
| Xamarin (C#) | ✅ | ✅ |
| Unity (C#) | ✅ | ✅ |
| Ionic / Capacitor | ✅ | ✅ |
The build tools like Android Studio, Gradle, and framework-specific CLIs handle the actual packaging — the language itself doesn’t matter much as long as it compiles down to Android-compatible bytecode or native code.
How Does AAB Actually Work?
Here’s a step-by-step breakdown of what happens when a developer uploads an AAB to Google Play:
Step 1: Developer Builds the AAB
The developer uses Android Studio or a CLI tool (like ./gradlew bundleRelease) to build an AAB. This file contains the app split into modules:
- Base module — the core app code that’s always installed
- Feature modules — optional parts that can be downloaded on demand
- Configuration splits — resources grouped by screen density, language, and ABI (CPU architecture)
Step 2: AAB is Uploaded to Google Play
The developer uploads the AAB to the Google Play Console. Google Play then takes ownership of generating APKs from this bundle.
Step 3: Google Play Processes the Bundle
Using a system called Play App Signing and Dynamic Delivery, Google Play analyzes the AAB and prepares optimized APK sets for every possible device configuration.
Step 4: User Downloads the App
When a user taps “Install” on the Play Store, Google’s servers check their device’s:
- Screen size & density (hdpi, xhdpi, xxhdpi, etc.)
- CPU architecture (arm64-v8a, x86, etc.)
- System language
Then Google serves a custom-built APK with only the matching resources. The user never sees the AAB — they just get a lean, optimized APK delivered silently.
How Does Google Play Show an AAB as an App?
This is where it gets interesting. The user sees a perfectly normal app listing on the Play Store — they have no idea whether the developer uploaded an APK or an AAB. Here’s how Google handles it:
- The AAB is stored on Google’s servers, not distributed directly to devices.
- Google Play reads the manifest file inside the AAB (the
AndroidManifest.xml) to get the app’s name, icon, version, permissions, and other metadata. - This metadata is used to populate the Play Store listing — the app name, screenshots, description, and install button all come from this.
- When installation is triggered, Google dynamically builds and signs a device-specific APK using Google’s own signing key (via Play App Signing).
- That signed APK is then delivered to the device and installed normally.
From the user’s perspective, it’s just an app. The AAB magic is entirely behind the scenes.
Quick Summary
| APK | AAB | |
|---|---|---|
| Full form | Android Package Kit | Android App Bundle |
| Created by | Google / Open Handset Alliance (2008) | Google (2018) |
| Can install directly? | ✅ Yes | ❌ No |
| Used for? | Direct installs, sideloading | Play Store uploads |
| Contains | All resources for all devices | Modular splits for all configs |
| App size benefit | None (one size fits all) | Up to 65% smaller for users |
| Required by Play Store? | ❌ No longer accepted for new apps | ✅ Required since Aug 2021 |
Final Thoughts
The shift from APK to AAB is one of those behind-the-scenes changes that makes a big real-world difference. Users get smaller, faster apps without doing anything differently. Developers get better tooling for modular features. And Google gets more control over the delivery pipeline.
If you’re building Android apps today — whether with Kotlin, Flutter, or React Native — understanding AAB is essential. It’s not just a file format; it’s the entire modern Android distribution model.
Related posts
