Fixing “You can’t rollout this release because it doesn’t allow any existing users to upgrade to the newly added app bundles” (Google Play Console)

What the error actually means

Play Console is telling you: some (or all) users who already installed your app cannot upgrade to the new build. That happens when the new bundle is not a valid successor of the old one—for example the versionCode didn’t increase, the signing key changed, your package name changed, or you dropped ABIs/devices that existing installs depend on.

Fast path: 10-minute pre-flight checklist

Work through these in order. Most issues are solved by item 1 or 2.

1. Bump versionCode
   • Every release must have a strictly higher versionCode than any version already in any track.
   • Open android/app/build.gradle: android { defaultConfig { applicationId "com.yourcompany.yourapp" // must be unchanged versionCode 123 // INCREASE this versionName "1.2.3" minSdkVersion 21 targetSdkVersion 34 } }
   • Rebuild the bundle after changing it.
2. Use the exact same signing lineage
   • If you changed keystores (or aliases) for signing without using Google Play’s key reset flow, upgrades are impossible.
   • Flutter/Gradle config should still point to your original keystore:
     • android/key.properties storeFile=..../release.keystore storePassword=******** keyAlias=your_alias keyPassword=********
     • android/app/build.gradle signingConfigs { release { storeFile file(properties['storeFile']) storePassword properties['storePassword'] keyAlias properties['keyAlias'] keyPassword properties['keyPassword'] } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true shrinkResources true } }
   • If you lost the upload key but use Google Play App Signing, request an upload key reset in Play Console (you keep the app signing key; only the upload key changes).
3. Keep ABI/device support
   • If older releases supported (say) armeabi-v7a and arm64-v8a but your new build only has arm64-v8a, existing armeabi-v7a users can’t upgrade.
   • For Flutter, make sure you include both common ABIs when building APKs for local tests: # For APK testing (not for Play) flutter build apk --release --target-platform=android-arm,android-arm64
   • For App Bundles, Gradle should include both ABIs by default; don’t strip them with custom ndk { abiFilters ... } unless you know the impact.
4. Package name must be identical
   • applicationId (package name) in build.gradle must match the one used in your first release. If it changed, Play treats it as a different app.
5. Don’t remove critical features for existing users
   • If you previously targeted all devices, but now Device Catalog excludes a large portion (e.g., raising minSdkVersion or dropping architectures), those users won’t see an upgrade path.
6. Upload a brand-new bundle after changes flutter clean flutter pub get flutter build appbundle --release

Deep-dive diagnosis (when the quick checks don’t surface it)

A. Compare with the last working artifact

• Play Console → Release → App bundle explorer → select the last released artifact.
• Note:
  • versionCode used.
  • Supported ABIs and device count.
  • Signing (App Signing enabled?).
  • minSdkVersion / targetSdkVersion.

Now open your new upload in App Bundle Explorer as well and compare the same attributes.

B. Verify what’s inside your .aab locally (advanced)

Install bundletool locally and run:

# Print manifest information
java -jar bundletool.jar dump manifest --bundle app-release.aab --xpath /manifest/@package

# List modules and native libraries (see ABIs)
java -jar bundletool.jar dump manifest --bundle app-release.aab --xpath //uses-sdk/@minSdkVersion
java -jar bundletool.jar dump resources --bundle app-release.aab

This confirms package name, min/target SDK, and presence of native splits.

C. Confirm your signing path

If you publish AAB with Play App Signing:

• Play signs the install APKs.
• You sign the upload with your upload key.
• If you changed upload key without the official reset, Play rejects the upgrade path.

If you previously published APK without Play App Signing and now switched to AAB + Play App Signing, you must enroll in Play App Signing (one-time step). After enrollment, do not change the app signing key.

Most common root causes & fixes (with exact symptoms)

Flutter/Gradle reference setup (copy-paste)

android/key.properties

storeFile=/absolute/path/to/release.keystore
storePassword=REDACTED
keyAlias=your_alias
keyPassword=REDACTED

android/app/build.gradle

def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file("key.properties")
if (keystorePropertiesFile.exists()) {
  keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {
  namespace "com.yourcompany.yourapp"
  compileSdkVersion 34

  defaultConfig {
    applicationId "com.yourcompany.yourapp" // must be unchanged forever
    minSdkVersion 21
    targetSdkVersion 34
    versionCode 124        // bump on every upload
    versionName "1.2.4"
    multiDexEnabled true
  }

  signingConfigs {
    release {
      storeFile file(keystoreProperties["storeFile"])
      storePassword keystoreProperties["storePassword"]
      keyAlias keystoreProperties["keyAlias"]
      keyPassword keystoreProperties["keyPassword"]
    }
  }

  buildTypes {
    release {
      signingConfig signingConfigs.release
      minifyEnabled true
      shrinkResources true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
  }

  // Keep ABI coverage unless you absolutely must limit it
  // ndk { abiFilters "armeabi-v7a", "arm64-v8a" }
}

Build & upload

flutter clean
flutter pub get
flutter build appbundle --release
# Upload the generated build at:
# build/app/outputs/bundle/release/app-release.aab

Sanity checks before every upload (preventative)

1. Track your last versionCode (keep a CHANGELOG or version.txt in the repo).
2. Never change applicationId after your first Play release.
3. Back up the keystore(s) and key.properties securely (and print the SHA-1/SHA-256 somewhere safe).
4. Don’t drop ABIs casually. If you must, plan a deprecation period and communicate it.
5. Run Internal testing first (same signing, same bundle) to catch issues early.
6. Check Device catalog after build; sudden coverage drops are red flags.
7. Keep min/target SDK migrations gradual; raising minSdk can strand existing users.

Other errors you’ll often meet during the same release & quick fixes

• “The Android App Bundle is signed with the wrong key.”
  → You used a different upload key. If Play App Signing is enabled, request an upload key reset and re-upload signed with the new upload key.
• “Version code X has already been used.”
  → Increment versionCode. Remember: every upload consumes a code, even in Internal/Closed testing.
• “This release is not compliant with 64-bit requirement.”
  → Include arm64-v8a native libs (for NDK code) or ensure Flutter’s default AAB is used (it produces 64-bit splits automatically).
• “Your release is not compliant with Play policies (privacy, SDK versions, permissions).”
  → Check policy center & manifest. Remove unused sensitive permissions (e.g., QUERY_ALL_PACKAGES), add a privacy policy URL, and target the required SDK level.
• “You uploaded an APK. New apps must use App Bundles.”
  → Use AAB: flutter build appbundle --release.

Decision tree (printable)

1. Error shown → “no upgrade path”
2. Check versionCode
   • Not higher → Fix & rebuild → upload
   • Higher → go to 3
3. Check signing lineage
   • Changed key / alias? → Use original keystore or upload key reset
   • Same → go to 4
4. Check ABI & device coverage in App Bundle Explorer / Device catalog
   • Dropped ABI or raised minSdk? → Restore coverage → rebuild
   • OK → go to 5
5. Check applicationId
   • Changed? → must revert to the original
   • Same → go to 6
6. Still failing? → Compare manifests with bundletool, re-verify Play App Signing enrollment, try an Internal testing upload to isolate.

Quick commands you’ll actually use

# Flutter clean build (AAB)
flutter clean && flutter pub get && flutter build appbundle --release

# Show signing report (helpful to verify keystore alias and SHA-1/SHA-256)
cd android && ./gradlew signingReport

# Build APK for local ABI sanity check (not for Play)
flutter build apk --release --target-platform=android-arm,android-arm64