Android · build & submit

Your app bundle is signed with the wrong key

Your Android App Bundle is signed with the wrong key
APK signature is invalid

The short answer

Play is comparing against your upload key, and your artifact was signed with something else. Nine times out of ten the something else is the debug keystore, because release builds from a stock React Native or Expo template are signed with the debug key unless you have configured otherwise.

Check which key actually signed the artifact:

keytool -printcert -jarfile app-release.aab

Compare the SHA-1 it prints against the upload certificate fingerprint shown in Play Console → Test and release → App integrity → App signing. If they differ, re-sign with the correct keystore and upload again.

If they differ and you no longer have the correct keystore, skip to the reset process below — it is a supported path, not a dead end.

Why this happens

Play uses two keys and the error message names neither of them clearly.

KeyWho holds itWhat it does
Upload keyYou Proves an upload came from you. This is the one in this error.
App signing keyGoogle Signs what devices actually install. You usually never see it.

With Play App Signing enabled — the default for anything created in the last several years — Google re-signs your bundle with the app signing key before distribution. Your upload key exists only to authenticate the handoff. This is why the fingerprint on the artifact you built will not match the fingerprint your users' devices see, and why comparing against the wrong one of those two sends people in circles.

Why release builds get signed with the debug key

The Expo and React Native Android templates ship a signing config that falls back to the debug keystore. It exists so a fresh clone can produce a runnable release build without any credentials at all, which is genuinely useful — and it means an unconfigured project produces an artifact that looks like a release build, installs fine locally, and is rejected by Play.

Two ways to fix it. Configure the gradle signing config with your real upload keystore, or build normally and re-sign the finished artifact:

# .aab
jarsigner -keystore upload.keystore app-release.aab upload

# .apk
apksigner sign --ks upload.keystore --ks-key-alias upload app-release.apk

The second approach has the advantage of leaving your gradle files untouched, which matters if prebuild regenerates them.

If the upload key is lost

This is recoverable, and worth knowing before you panic: generate a new keystore, then ask Google to reset the upload key for the app through Play Console support. Because the app signing key is held by Google and is unchanged, your existing users are unaffected and updates continue to work. A lost app signing key on a legacy app without Play App Signing is the genuinely unrecoverable case — a different and much rarer situation.

Catching it before you build

The half of this that is knowable up front is whether the keystore you are about to sign with is the one you think it is. leas doctor opens the keystore, confirms the alias exists, and reports its expiry — which catches the wrong-keystore and wrong-alias cases before a build rather than at upload:

▸ Android
  ✗ Upload keystore             no alias "upload" — keystore holds androiddebugkey
      → Set keyAlias in leas.json to one of the aliases above.

Set up leas in 10 minutesFree, MIT licensed, and it never receives your signing keys.

If that didn’t fix it

  • Re-signed and still rejected. Signing an already-signed artifact can leave the old signature in place. Build clean, then sign once.
  • The keystore holds more than one alias. Signing with the wrong alias produces exactly this error. keytool -list -v -keystore upload.keystore lists them.
  • You are comparing against the app signing fingerprint. Play shows both. The one that must match your artifact is the upload certificate.