Guide · Play Console
AAB vs APK: what to upload to Google Play, and why
When you go to publish, Play Console asks for an .aab, but everything you've read about installing Android apps talks about .apk. Are they the same thing? Which do you build? Here's the clean mental model, and where each one actually fits.
The short version: the APK is the finished app a device installs. The AAB (Android App Bundle) is a publishing format you upload to Google Play — Google uses it to generate a small, optimized APK for each user's device. You upload an AAB; users still receive an APK.
What each one is
| APK | AAB | |
|---|---|---|
| What it is | The installable app package | A publishing bundle of everything needed to build APKs |
| Who installs it | Devices install it directly | Devices never install it — Google Play processes it |
| Where it goes | Sideloading, other stores, testing | Uploaded to Google Play |
| Size on device | Contains all densities/languages/ABIs | Google strips it down per device |
Why Play switched to the AAB
A single "universal" APK has to contain resources for every device: all screen densities, all CPU architectures, all languages. Most of that is dead weight for any one user — their phone only needs one density, one ABI, one language. The App Bundle hands Google all of it, and Google generates a tailored APK per device that includes only what that device uses. The result is a smaller download for users without you maintaining a dozen separate APKs. This is why new apps and updates on Play must be AABs.
How users still get an APK
The AAB itself is never installed. When someone downloads your app, Google Play's servers build the right APKs on the fly from your bundle — the base plus the specific density/language/ABI splits that device needs — and deliver those. So the chain is: you build an AAB → Play generates per-device APKs → the device installs an APK. The APK never disappeared; it just gets produced by Google instead of by you.
Building each one
In Android Studio, Build > Generate Signed Bundle / APK lets you pick either. From the command line:
# App Bundle for Play upload ./gradlew bundleRelease # → app-release.aab # APK for direct install / testing ./gradlew assembleRelease # → app-release.apk
When you'd still build an APK yourself
- Quick testing — installing directly on a device over USB or sharing a build with a tester.
- Distribution outside Google Play — other app stores or direct download, where there's no Play to process a bundle.
- Debugging what actually ships — you can use the bundletool to generate the exact APKs Google would, to reproduce a device-specific issue.
Because Google builds the delivered APKs from your AAB, it also signs them — which is where Play App Signing comes in. If that split of keys is fuzzy, it's worth understanding before your first release.
Quick mental model
Think of the AAB as the raw ingredients and recipe you hand to Google's kitchen; the APK is the finished dish served to each diner, cooked to their table's needs. You ship ingredients; Google plates the meal.
Gradle task names and Studio menu labels shift slightly between versions; the AAB-for-Play, APK-for-device split is the part that stays constant.