Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A release-labeled Android App Bundle is not necessarily signed, installable, or ready for users. An .aab is a publishing artifact: Google Play turns it into device-specific APKs, and Gradle signs a release bundle only when signing configuration is assigned. To make a dependable release candidate, verify the build variant, confirm signing, and test the bundle through generated APKs or Play Console internal testing.
Why a “release” AAB may not be final
“Release” describes a build type; it does not guarantee that the artifact has been signed or tested. Android Gradle Plugin combines build types, product flavors, and source sets into build variants, so a release build can also be the wrong flavor or contain different code and resources than intended. Check the selected variant before treating an output as the release candidate. Android’s build-variants guide explains how variants are composed.
Signing is a separate step. Gradle does not sign a release AAB unless a signing configuration is assigned. Android Studio’s ordinary Generate Bundle(s) flow can create an unsigned release bundle; use Generate Signed Bundle / APK when you want the wizard to sign it, or configure signing for the release build type in the base module’s Gradle configuration. The UI behavior is described in Android’s release-build guide; Gradle configuration is covered in the build-variants documentation.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →That distinction matters because the bundle itself is not what users install. An AAB contains compiled code and resources, and Google Play generates APKs suited to each device configuration. You cannot install an AAB directly on a device. See Android’s command-line build documentation.
#1 Best Overall
How to check and correct the release candidate
- Confirm the variant and flavor. In Android Studio, open Build > Select Build Variant and choose the intended release variant for the base app module. Check the flavor as well as the build type; similarly named variants can package different app content.
- Check the signing setup. If you build with Gradle, confirm that the base module’s release build type references the intended signing configuration. If you build in Android Studio, use Build > Generate Signed Bundle / APK and follow the bundle signing flow rather than assuming that Generate Bundle(s) signs the result. Keep the keystore and private key protected, with secure backups. Android’s signing guidance is at Sign your app.
- Build a fresh bundle after correcting configuration. Do not treat an earlier unsigned or wrong-variant artifact as fixed merely because the project configuration changed. For an app update, increase the base module’s version code before uploading the new full bundle. Android’s upload guide covers inspection, testing, upload, and version-code updates.
- Validate what will be delivered. Generate APKs from the bundle for local inspection, or upload it to a Play Console internal testing track. These routes test different parts of the delivery pipeline, described below.
Choose a test route that matches what you need to verify
| Route | What it validates | When it is useful |
|---|---|---|
| Generate APKs locally with bundletool | Lets you inspect and deploy APKs generated from the bundle without publishing it. This checks local bundle-to-APK generation, not Google Play’s full processing path. | Use it for quick local validation or when you need deployable APKs from an AAB. Android documents bundletool and bundle workflows at Build your app from the command line. |
| Play Console internal testing | Exercises Play processing, including Play signing and shrinking, and is closer to the APK delivery path users receive. | Prefer it when the goal is to approximate distribution through Google Play. See Upload your app to the Play Console. |
| Firebase App Distribution | Provides a way to share builds with testers, including CI builds. The cited documentation does not establish that it reproduces Google Play’s signing path. | Use it for tester distribution when Play-specific processing is not the property being validated. |
Android’s release-preparation guidance recommends testing the release version before publishing, including under realistic device and network conditions: Prepare your app for release.
What upload signing and Play signing mean
For an app enrolled in Play App Signing, the upload key signs the AAB submitted to Play and lets Google verify the uploader. Google Play then signs the APKs generated for distribution with the app-signing key. Consequently, a correctly signed upload bundle does not carry the same signing identity as the APK a user installs. The roles and recovery options are explained in Android’s app-signing guide.
Rank #2
If the upload key is lost, a reset can be requested in Play Console when Play App Signing is enabled. If an app is not enrolled in Play App Signing and its app-signing key is lost, publishing updates may not be possible. Treat the keystore and private key as release-critical credentials, not disposable build files.
Use the right signing tool for an AAB
Android documents jarsigner as a separate command-line step for signing an app bundle. apksigner signs APKs; it cannot sign an AAB. Do not apply APK-signing instructions to a bundle. For a Gradle release bundle, configure signing on the base module’s release build type. The distinction and bundle workflow are documented in Build your app from the command line.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
