All guides
BuildApp BundlePublishing

AAB vs APK: What Actually Changed, and What You Have to Ship

Google Play requires Android App Bundles for new apps, but APKs have not disappeared. What each format is, why Play made the switch, and how to still get an installable APK when you need one.

Play Store Toolkit·7 min read

Since August 2021, new apps on Google Play must be uploaded as Android App Bundles (.aab). APKs still exist and still install — they just are not what you hand to Play any more.

The difference in one paragraph

An APK is a finished, installable package containing every language, every screen density and every CPU architecture your app supports. An AAB is not installable: it is a publishing format containing all of that compiled code and resources, which Google Play then uses to generate an optimised APK for each specific device.

Why Google made the switch

A single universal APK ships resources most users never touch — French strings to an English-only device, xxxhdpi artwork to a low-density phone, arm64 libraries to an x86 emulator. With an AAB, Play builds a device-specific APK containing only what that device needs. Size reductions of 15–35% are typical, and download size is one of the strongest predictors of install completion.

What you give up

Uploading an AAB means enrolling in Play App Signing: Google holds the key that signs what users install, and your keystore becomes an upload key rather than the signing key.

This has one consequence that catches people out constantly: the fingerprint your production app is signed with is not the one on your machine. Google Sign-In, Maps and App Links all verify against the Play App Signing certificate, which you take from Play Console → Test and release → Setup → App signing. Register that fingerprint, not just your local one — the keystore SHA-1 helper walks through both.

The upside of the same change: if you lose your upload keystore, you can request an upload key reset. Before Play App Signing, losing the key meant losing the ability to update the app at all.

When you still need an APK

  • Direct distribution — sideloading, your own website, enterprise deployment.
  • Other stores — many accept APKs only.
  • QA and device testing — handing a build to someone without Play involved.
  • Existing apps published before the AAB requirement can still update via APK, though moving to AAB is strongly encouraged.

Getting an APK from a bundle

Google's bundletool converts an AAB into installable APKs:

bundletool build-apks --bundle=app-release.aab \
  --output=app-release.apks \
  --ks=my-release-key.jks \
  --ks-key-alias=my-alias \
  --mode=universal

--mode=universal produces one fat APK that installs anywhere, which is what you usually want for manual distribution. Drop the flag and you get a set of split APKs matching real device configurations.

For a quick QA build, Android Studio's Build → Build APK(s) is faster than going through the bundle at all.

Practical notes

  • Test the bundle, not just the debug APK. Play Console's internal testing track installs what users will actually receive.
  • Watch the delivered size, not the AAB size. Play Console shows the download size per device configuration; that number is what matters.
  • versionCode still has to increase for every upload, bundle or not.

Tools for this

Keep reading