TestCrew
Play Console and Releases

Why Can't I Upload an Android App Bundle to Google Play?

Troubleshoot Google Play AAB upload errors by checking versionCode, signing, applicationId, build type, target API requirements, file integrity, and release tasks.

Published
August 2, 2026
Updated
August 5, 2026
Official info checked
August 2, 2026
TestCrew guide cover for troubleshooting Android App Bundle upload errors

When you upload an Android App Bundle to Google Play Console, processing may stop because of the file type, signing certificate, version, package name, or release configuration.

The first step is to save the exact error message. Before repeatedly rebuilding the AAB, identify where the failure occurs.

  • The upload does not begin after selecting the file
  • Google Play rejects the bundle during analysis
  • The AAB is accepted, but the release cannot be published
  • The release is created, but it cannot be submitted for review

These are different problems and should not be troubleshooted in the same way.

Check these five items first

Before uploading, confirm that:

  1. The versionCode is higher than any value previously used
  2. The bundle is signed with the correct release upload key
  3. The applicationId matches the app in Play Console
  4. The file is a properly generated .aab
  5. You distinguish warnings from blocking errors after upload

Cause 1: The versionCode has already been used

Every release submitted to Google Play needs a unique versionCode.

Rejected example

Previously uploaded AAB:

versionCode = 12

New AAB:

versionCode = 12

Corrected example

versionCode = 13

Changing only versionName does not solve the problem.

versionName: 1.2.0 → 1.2.1
versionCode: 12 → 12

Check values already used in internal, closed, open, and production tracks as well.

Cause 2: The bundle is signed with the wrong key

An update to an existing app must be signed with the upload key registered for that Play Console app.

Common causes include:

  • A new keystore was created on another computer
  • A debug keystore was used
  • The keystore belongs to another app
  • CI was configured with a different key
  • The wrong key alias was selected
  • The old key is still being used after an upload-key reset

Verify the AAB signature

jarsigner -verify -verbose -certs app-release.aab

To inspect the certificate in the keystore:

keytool -list -v \
  -keystore upload-keystore.jks \
  -alias upload

Compare the SHA-1 or SHA-256 fingerprint with the upload certificate shown in Play Console.

When the upload key is lost

When Play App Signing is enabled, you may be able to create a new upload key and request an upload-key reset in Play Console.

Do not create an unrelated new Play Console app merely to work around an update-signing error.

Cause 3: The applicationId is different

The package name in Play Console must match the applicationId inside the AAB.

Play Console app

com.example.todoapp

Generated AAB

com.example.todoapp.dev

When using product flavors or applicationIdSuffix, confirm the selected build variant.

android {
    defaultConfig {
        applicationId = "com.example.todoapp"
    }

    productFlavors {
        create("development") {
            applicationIdSuffix = ".dev"
        }
    }
}

For the production app, generate the production release AAB rather than a development-flavor bundle.

Cause 4: The selected file is not an AAB

An App Bundle submitted to Google Play must be a valid .aab generated by the build system.

Do not confuse these formats:

ExtensionPurpose
.aabAndroid App Bundle submitted to Google Play
.apkPackage that can be installed on a device
.apksAPK set generated by bundletool
.zipGeneric archive; changing the extension does not create an AAB

Renaming an APK to .aab does not convert it into an Android App Bundle.

Android and Gradle

./gradlew clean
./gradlew bundleRelease

Typical output:

app/build/outputs/bundle/release/app-release.aab

Flutter

flutter clean
flutter pub get
flutter build appbundle

Typical output:

build/app/outputs/bundle/release/app-release.aab

Cause 5: An older AAB was selected

AAB files often use the same filename for every build, making it easy to upload a file generated before the fix.

Check:

  • Modification time
  • File size
  • versionCode
  • Source project
  • Build variant
  • Signing key

Deleting old output directories before rebuilding makes it easier to select only the newly generated artifact.

Cause 6: The target API requirement is not met

Google Play applies target API requirements to new apps and updates.

This issue may appear after the AAB transfer or when submitting the release rather than during the initial upload.

Check at least the following values in Gradle:

android {
    compileSdk = 36

    defaultConfig {
        targetSdk = 36
    }
}

Required API levels change over time and may vary by submission date or app category. Follow the requirement displayed in Play Console and the current official documentation.

Cause 7: The file is corrupted

A bundle may become unreadable because of a failed build, incomplete cloud synchronization, or an unnecessary compression step.

Recreate it with this process:

  1. Delete the build output
  2. Restore dependencies
  3. Build the release variant
  4. Confirm the creation time
  5. Upload the file directly from local storage

You do not need to email, recompress, or convert the AAB before submitting it.

Cause 8: The bundle size or structure is problematic

Apps containing large images, video, audio, machine-learning models, or native libraries may reach Google Play download-size limits.

Possible actions include:

  • Remove unused resources
  • Convert images to WebP or AVIF
  • Exclude unnecessary ABIs
  • Deliver video or large data separately
  • Consider Play Asset Delivery
  • Split optional functionality into Dynamic Features

Review the delivery size calculated by Play Console, not only the apparent size of the .aab file.

The AAB uploaded, but the release still cannot be published

A successfully processed bundle can still be blocked by incomplete Play Console requirements such as:

  • Store listing
  • Privacy policy
  • Data safety
  • Content rating
  • Ads declaration
  • App access instructions
  • Distribution countries
  • Target API requirement
  • Policy issue

In this situation, do not rebuild the AAB automatically. Review the tasks shown on the Play Console dashboard and Publishing overview.

Error reference table

Message or symptomFirst place to check
versionCode already usedGradle or Flutter version settings
Signed with the wrong keyKeystore, key alias, and CI secrets
Package name does not matchapplicationId, flavor, and selected Play app
File cannot be analyzedRebuild the AAB and confirm the selected file
Target API is too lowtargetSdk and the Play Console requirement
Download-size limitResources, native libraries, and assets
Upload succeeds but publishing is blockedIncomplete Play Console tasks
Temporary transfer failureBrowser, network, and local file

Fastest troubleshooting sequence

  1. Copy the complete Play Console error
  2. Confirm the package name of the target app
  3. Find the highest versionCode previously used
  4. Verify the upload certificate
  5. Select the production release variant
  6. Delete the output directory and rebuild
  7. Confirm the new AAB’s timestamp and size
  8. Upload it to the correct Play Console app
  9. Separate warnings from blocking errors
  10. If publishing is blocked, review incomplete console tasks

Summary

The most common AAB upload problems are:

  • Reused versionCode
  • Upload-key mismatch
  • Incorrect applicationId
  • Selecting an old file or the wrong build variant

Instead of rebuilding without a diagnosis, compare the exact Play Console error with the configuration of the bundle you actually generated.

Primary sources

Official references

Check the linked official documentation before a production release.

Continue reading

TestCrew

Find testers through mutual testing

Test other Android apps, provide useful feedback, and use earned credits to recruit testers for your own Google Play closed test.

Learn how TestCrew works

Analytics settings

TestCrew uses Google Analytics provided by Google LLC to improve the website. You can change whether it is used; this applies to future measurement on this page and later visits. See the Privacy Policy.