The builder hands you two files from one build, and the first question in support is always which one to use. Short version: the AAB goes to Google Play; the APK goes onto phones. The longer version explains why both exist.
APK: the installable
An Android Package is a signed zip containing compiled code, resources, the manifest and native libraries for every device configuration it supports. Android installs APKs directly. You can email one, host it on your website, install it with a cable, or push it to a fleet of kiosks. It is the format Android has used since day one and it still works everywhere.
Its weakness is that one file has to carry everything for every device — all screen densities, all languages, all CPU architectures — so users download resources they will never use.
AAB: the publishing format
An Android App Bundle is also a signed zip, but it is not installable. It contains the same code and resources organised so that Google Play can generate an APK tailored to each device — only the density, language and architecture that phone needs. Play does the splitting and the final signing, and users get smaller downloads. Google made the AAB mandatory for new apps in August 2021; the console refuses an APK for a new app.
For a website-based app the size difference is small (there is little in the package besides the shell and your icon), but the requirement is absolute, so the bundle is what you upload regardless.
What Play does with your bundle
- Verifies the upload signature against your upload key.
- Generates split APKs per configuration.
- Signs them with the app signing key held by Play (see the signing guide).
- Serves the right combination to each device at install time.
Consequence: the APK a user installs from Play is not byte-identical to any file you produced. If you also distribute an APK from your website, users cannot install both versions over each other unless the signing certificates match — and they usually won't, because Play signs with its key and your APK is signed with yours. Decide on one distribution channel per user group.
When you still want the APK
- Testing on your own devices before you upload anything. Install it, use it for ten minutes, check the offline screen, rotation and the back gesture.
- Testers outside Play — though for a Play launch the internal testing track is better, because it tests the actual Play-signed build.
- Distribution outside Play: internal business apps, kiosks, closed communities, regions or devices without Play. Android 14+ will show an "unknown apps" warning that users must accept once per source app.
- Uploading to other stores (Samsung Galaxy Store, Amazon Appstore, Huawei AppGallery) — most accept APKs, some accept AABs.
Version codes
Every upload to Play must have a higher version code (an integer) than the last. The builder increments it per build. If you rebuild after changing settings and Play says the version code already exists, build again — don't try to edit the file.
Bundletool, if you want to see what Play sees
Google's open-source bundletool can turn an AAB into a set of APKs locally (build-apks) and install them on a connected device (install-apks), which is the closest test to a Play install without uploading. It needs Java. Most publishers never need it; the internal testing track answers the same question.
What the builder produces
A signed APK and a signed AAB from the same configuration, with matching package name and version code. Upload the AAB to Play's internal testing track first; install the APK on your phone in parallel. When the internal-track install behaves the same as the APK, move on to the store listing.