AAB vs APK: Why Google Forces You to Use Bundles

If you have built Android apps before 2021, you remember APKs. Single file, ship as-is, easy to sideload. Then Google switched. Since August 2021, every new submission to the Play Store must be an Android App Bundle (AAB). APKs are still everywhere — sideloading, alternative stores, debug builds — but the official Google Play submission format is exclusively AAB.

What an AAB actually is

An AAB is a ZIP archive with a specific internal structure. It contains your app's code, resources, native libraries, and a manifest, organized by configuration: base module, dynamic feature modules (optional), per-architecture native code, per-language resources, per-density images. Crucially, an AAB is not directly installable on a device. Google's servers — or the open-source bundletool — split it into device-specific APKs at download time.

For a typical app, the AAB is roughly the same size as the equivalent universal APK on disk. The savings happen on the user's end: instead of downloading every architecture and density, the user gets only their device's slice. App size drops 20–60% in practice.

Why Google forced the switch

Three reasons. First, install size: users with low storage and slow connections benefit massively. Second, dynamic delivery: AAB enables features like Play Asset Delivery (huge game assets downloaded post-install) and Play Feature Delivery (entire app modules installed only when needed). Third, signing-key management: AAB submissions require Play App Signing, where Google holds the production signing key. This makes it harder for malicious actors to publish modified versions of legitimate apps under a stolen developer account.

The signing-key tradeoff

Play App Signing is mandatory for new AAB submissions. Google holds your app's production signing key in their secure key management system; you upload AABs signed with an "upload key" (which you keep) and Google re-signs them with the production key before distribution.

This is convenient (you can lose your upload key and recover by contacting Google) but irreversible (once Google has the production key, there is no path back to self-signing). New apps cannot opt out; existing apps that were self-signing before 2021 can continue, but if you migrate to AAB you accept Play App Signing.

How to build an AAB

From Android Studio: Build → Generate Signed Bundle / APK → Android App Bundle. From the command line: ./gradlew bundleRelease. The output lands at app/build/outputs/bundle/release/app-release.aab.

React Native: cd android && ./gradlew bundleRelease. Flutter: flutter build appbundle. Unity: in the build settings, check "Build App Bundle (Google Play)".

Testing an AAB locally

You cannot directly install an AAB on a device. To test, use Google's bundletool:

bundletool build-apks --bundle=app.aab --output=app.apks
bundletool install-apks --apks=app.apks

This generates the device-specific APK split for the connected device and installs it. Use this to verify your release AAB before uploading.

What the wizard reads

Step 2 of the wizard parses your AAB in the browser — no bundletool required. It reads the binary AndroidManifest.xml from base/manifest/, decodes the resource format, and pulls out: package name, version name and code, min and target SDK, and the full permission list. Your AAB never leaves your device.

When to still use APKs

APK is still the right format for: sideloading (direct installs without Play Store), alternative app stores (Amazon Appstore, F-Droid, Huawei AppGallery, Samsung Galaxy Store), enterprise distribution (MDM-pushed builds), and debug development. Most build systems produce both formats from the same source.