You finished building your Rork app, opened Google Play Console to upload it, and got stopped cold by "Your Android App Bundle is signed with the wrong key." The build succeeded, so it's confusing that only the submission fails. This is one of the most common walls people hit on their very first release.
I've been shipping apps as a solo developer since 2014, and across the titles that added up to roughly 50 million downloads, I run into this signing error at least once every time I move to a new build environment. Once you understand how the two keys fit together, it stops being scary and becomes a quick thing to diagnose.
Why Google says the key is "wrong"
Two different keys are involved when you publish to Google Play, and mixing them up is what makes the error message hard to read.
The first is the upload key. This is the key you use locally to sign your AAB (Android App Bundle). It proves to Google Play that the upload genuinely came from you.
The second is the app signing key. This is the key Google re-signs the delivered APK with. When Play App Signing is enabled, Google stores this key securely on their side.
"Signed with the wrong key" almost always means the key you just signed with does not match the upload key already registered on Google Play. It shows up when you've lost your original key, or when you switched build environments and accidentally signed with a freshly generated one.
Check this first
Before doing anything, confirm which key actually signed your bundle. Pull the certificate fingerprint (SHA-256) out of your AAB and compare it against what Google Play has on file.
# Inspect the signing certificate inside your AAB / APK
keytool -printcert -jarfile your-app.aabNote the fingerprint on the SHA256: line. Then open Google Play Console, go to your app's Test and release → App signing, and you'll see the SHA-256 for both the upload key certificate and the app signing key certificate.
If your local fingerprint matches the upload key certificate, you're fine. If it doesn't, you're signing with a different key — and that mismatch is the direct cause of the rejection.
Fixes by scenario
The cause depends on how you build. Rork apps are usually built either through EAS (Expo Application Services) or by exporting native code and signing locally, so let's focus on those two.
Case 1: You use EAS Build and the key changed
EAS Build generates a signing key on your first build and stores it for you on the Expo side. Convenient — but the fingerprint can drift if you've touched eas credentials, or rebuilt under a different account or project, causing a new key to be created.
First, check which key EAS currently holds.
# List Android signing credentials
eas credentials --platform androidPick your build profile (usually production) from the menu, and it shows the current keystore and its SHA-256 fingerprint. If that matches the upload key certificate on Google Play, just rebuild with it and you're done.
The harder situation is when EAS has lost the key you originally registered with Google Play. If you still have that registered upload key on hand (the .jks / .keystore file plus its passwords), load it back into EAS.
# Upload an existing keystore so EAS signs with it
eas credentials --platform android
# → Keystore: Set up a new keystore → choose the existing file → enter passwordsIf you no longer have the key anywhere, jump to "If you lost your upload key" below.
Case 2: You sign locally and grabbed the wrong key
If you exported native code and sign through Android Studio or the command line, verify that your signing config points at the right keystore. It's surprisingly easy for android/gradle.properties or a CI variable to reference a debug key or another app's key.
# android/gradle.properties — be explicit about the release signing key
MYAPP_UPLOAD_STORE_FILE=upload-keystore.jks
MYAPP_UPLOAD_KEY_ALIAS=upload
MYAPP_UPLOAD_STORE_PASSWORD=YOUR_STORE_PASSWORD
MYAPP_UPLOAD_KEY_PASSWORD=YOUR_KEY_PASSWORDCheck the fingerprint of the keystore you're pointing at:
# Show the fingerprint for a specific alias inside the keystore
keytool -list -v -keystore upload-keystore.jks -alias uploadMake sure that SHA-256 matches Google Play's upload key certificate. When you run several apps in parallel, it's easy to share one app's keystore by mistake. I once nearly signed one app with another app's key while updating a wallpaper app and a relaxation app on the same day. Keep a clearly separated keystore and alias per app — it's the safest habit.
Case 3: If you lost your upload key
When the upload key is gone from both your machine and your build environment and can't be recovered, you ask Google to reset it. This is only possible for apps with Play App Signing enabled, precisely because Google holds the app signing key used for delivery.
Create a new upload key and attach its public certificate (PEM) to the reset request.
# Generate a new upload key
keytool -genkeypair -v -keystore new-upload-keystore.jks \
-alias upload -keyalg RSA -keysize 2048 -validity 9125
# Export the PEM certificate to attach to the reset request
keytool -export -rfc -keystore new-upload-keystore.jks \
-alias upload -file upload_certificate.pemTake that upload_certificate.pem and request an upload key reset from the App signing page in Google Play Console. Approval usually takes one or two business days. After it's approved, builds signed with the new key are accepted.
One important caveat: if you opted out of Play App Signing and managed the app signing key yourself, and then lost that key, you can no longer ship updates under the same package name, and no reset will help. That's exactly why I strongly recommend enabling Play App Signing from the start.
Keeping it from happening again
This error is painful enough to recover from that prevention pays off the most. After years of running multiple apps, here's the routine I've settled into.
Store the upload key .jks file and its passwords somewhere separate from your build environment — a password manager or an encrypted backup. The most common accident is losing only the key when you replace your build machine.
Enable Play App Signing for new apps as a rule. Google then holds the delivery key, so even if you lose the upload key, a reset can bring you back.
And give each app its own keystore and alias name, with a short note listing them. Comparing fingerprints is a one-liner with keytool -printcert -jarfile, so making it a pre-submission habit cuts out the wasted round-trips of being rejected after upload.
Next time you move to a new build environment, pull your AAB's fingerprint first and confirm it matches Google Play's upload key certificate before you submit. That single check prevents almost every instance of this signing error.