Build a signed Android App Bundle (AAB) for Google Play
Google Play has required an App Bundle for new apps since 2021. An .aab is not an APK with a different extension: it is a publishing format that Play splits into per-device APKs, so a phone downloads only the density, language and ABI it needs instead of everything.
That also means an .aab cannot be installed on a device by double-clicking it. If you want to test what you built, build the APK; when it is time to publish, build the AAB. Both come from the same project and the same signing key here.
AAB vs APK: which file do you actually need
Use the APK to install on a phone, hand to a client for QA, or distribute outside Play. Use the AAB to upload to Play Console. The bundle is smaller on Play because Google does the splitting; the APK is the file that runs.
If you are updating an existing listing, Play only accepts a bundle whose versionCode is higher than the published one and whose signing key matches the one Play already holds — which is why losing a keystore ends a listing.
What goes into the bundle
The build wraps your web app or generated app in an Android project, compiles it with Gradle, signs the release output and produces the .aab. The manifest carries your package ID, version name and version code; the icon and splash assets are compiled into resources.
If the source is a live URL, the app loads that origin, so content changes ship from your server without a new Play release. If the source is a ZIP, the assets are packaged inside the app and work offline.
The Play Console steps that follow
Upload the .aab under Production → Create new release. Play validates the bundle and shows the target SDK it detected; new apps and updates submitted after 31 August 2026 must target Android 16 (API level 36).
Then complete Data safety, content rating, the privacy policy URL, and — if anything sits behind a login — reviewer credentials. The bundle being correct does not make the listing complete, and reviewers reject incomplete listings more often than broken builds.
Why the keystore matters more than the build
Android identifies an app by package ID plus signing key. Change either and the store treats it as a different app; the update is refused or installed alongside the old one. APKBuild keeps the key with the project across rebuilds so a second version installs over the first.
Export the key and keep a copy. If you later move to another build service, that file is the only thing that lets your existing users update.
When an AAB is the wrong choice
Direct distribution to a client, an internal team, or a device without Play Services needs an APK. Play is also not the only route: for testing, sideload the APK; for enterprise distribution, use MDM with the APK.
If you need a native Kotlin app rather than a packaged web app, this is not that tool — see the comparison on the AI app builder page.
Frequently asked questions
Can I install an AAB on my phone?
Not directly. An .aab is an upload format; Play converts it into per-device APKs. Build the APK from the same project to test on a device, and use the .aab for Play Console.
Does Google Play require an AAB?
Yes for new apps and app updates distributed through Play. APKs are still the right format for sideloading, client hand-off and enterprise distribution.
Can I turn an existing APK into an AAB?
Not reliably. Converting repackages an APK you already signed and loses the original module structure; the correct route is to rebuild the project as a bundle, which is what this builder does from the URL, ZIP or saved AI app.
Is the bundle signed with my key?
It is signed with the project keystore, which survives rebuilds. If you enrol in Play App Signing, Google holds the distribution key and your key becomes the upload key — both must stay consistent for updates.
What target SDK does the bundle carry?
The build compiles against the current Android SDK; the Play Console release page shows the detected target SDK before you roll out. Check it with the free APK readiness checker if you are unsure.