An APK is a finished Android app: one file containing every resource for every device, which installs directly when you open it on a phone. An AAB (Android App Bundle, .aab) is a publishing format — it cannot be installed at all. You upload it to Google Play, and Play generates a tailored APK for each device, typically 20–35% smaller than the universal one. Since August 2021 every new app on Play must be uploaded as an AAB. For everything else — testing, clients, your own download link — the APK is what you want.
Side by side
| APK | AAB | |
|---|---|---|
| Installs on a phone | Yes — tap the file | No, never |
| Accepted by Google Play | Only for apps first published before Aug 2021 | Required for all new apps |
| Size the user downloads | Everything, for every screen density and CPU | Only what that device needs — usually 20–35% less |
| Who signs what reaches phones | You do | Google does, with Play App Signing |
| Share by link, email, QR | Yes | No |
| Other stores (Amazon, Galaxy, F-Droid, APK sites) | Yes | Mostly no |
| On this site | Free tier | Pro |
Why Play insists on the bundle
A universal APK carries five sets of launcher icons, every localisation and — for apps with native code — every CPU architecture, then installs the lot on a phone that uses one of each. The bundle lets Play strip the rest at download time. For a converted website the saving is smaller than for a game (there is no native code and few resources), but the rule applies regardless of how little you would save.
What AAB changes about signing
This is the part that surprises people. With an AAB you upload something signed with an upload key, and Google re-signs the delivered APKs with an app signing key it holds. Two consequences:
- Losing your upload key is recoverable — Google can reset it. Losing the app signing key is not your problem any more, because Google holds it. That is a real safety improvement over the old APK world, where a lost keystore ended the app.
- Fingerprints differ. Anything that needs your app's certificate — Android App Links, Google Sign-In, Maps keys — must use the app signing certificate from Play Console, not your upload key. Using the wrong one is the single most common reason deep links refuse to verify.
Which to build, when
| You want to… | Build |
|---|---|
| Install it on your own phone to test | APK |
| Send it to a client or a colleague | APK |
| Put a download button on your website | APK |
| Distribute inside a company, MDM or kiosk fleet | APK |
| Publish on Google Play | AAB |
| Publish on Amazon Appstore, Galaxy Store or F-Droid | APK |
| Update an app already on Play | AAB, same package name, higher version code |
Can I turn an AAB into an APK?
Technically yes — Google's bundletool can generate APKs from a bundle, including a universal one — but it is a command-line detour with a keystore attached. If you need an installable file, build an APK in the first place; the builder produces either from the same project, so there is nothing to convert.
The practical answer for a converted website
Build the APK first, free, and put it on a real phone. Walk every screen, test a login, pull the network out. When the app is right and you have decided Play is worth the $25 registration and the review, switch the output to AAB and upload that. Nothing about your project changes between the two — same URL, same icon, same package name. The Play submission checklist →