With Play App Signing, users receive your app signed by Google's app signing key, not your upload key. If an API provider such as OAuth or Maps was registered with your upload key's fingerprint, it will not recognize the store build. Register the fingerprints shown in the App signing section of Play Console.
Why it happens
Google's help article explains the setup. You sign your bundle with an upload key and upload it. Google then signs the APKs it delivers with the app signing key, which it manages. Those are different keys with different certificate fingerprints.
Many services identify an Android app by its package name plus the fingerprint of the certificate that signed it. If you registered the fingerprint of your local keystore, then tested with a locally signed build, everything worked. The store build is signed by another key, so the fingerprint no longer matches, and the service refuses it.
What Google says to do
The article says that if your app uses services such as Google Maps, OAuth or Facebook Login, you should register the app signing key fingerprints from the App signing key section in Play Console, and not only your local upload key. It also notes that apps with quantum-ready signing have three keys to register.
A short table
| Key | Who holds it | Signs | Register with API providers? |
|---|---|---|---|
| Upload key | You | The bundle you upload | For builds you sign and run yourself |
| App signing key | The APKs users install | Yes, for store builds |
The first row still matters for local and internal test builds, so keep both registered.
Fix steps
- In Play Console, open the App signing section for your app.
- Copy the certificate fingerprints listed there.
- Add them to each provider that checks fingerprints, such as OAuth client settings and map key restrictions.
- Keep your upload key and debug key fingerprints too, so internal builds still work.
- Test with a build installed from an internal testing track, since that build carries the real store signature.
- Repeat for any backend that validates the signing certificate of calling apps.
How to avoid the surprise
- Add "register app signing fingerprints" to your launch checklist for every new app.
- Keep a record of each fingerprint, which key it belongs to, and where it is registered.
- Do the first store upload to an internal track early, not on launch day.
- If you change the upload key through a reset, the app signing key does not change, so provider registrations stay valid. Google states a reset does not affect the app signing key. See /resources/blog/lost-android-upload-key-how-to-request-an-upload-key-reset.
A security angle
Fingerprint restrictions are a way to stop others from using your API keys in a different app. Do not remove the restriction to get around a mismatch. Add the right fingerprint instead. An unrestricted key can be copied from the app and used elsewhere, which can create cost and abuse.
Also remember that the certificate fingerprint is public information. It identifies a key, and it is not a secret.
Where Safeguard fits
Fingerprint registration checks who signed the app. Safeguard checks what is inside it, using dependency scanning and SBOMs, and has a free scan at gold.safeguard.sh/scan.
Quick check
Which fingerprint do I register for store builds?
The one from the App signing key section in Play Console. Google says to register it, not only your local upload key.
Does an upload key reset change that fingerprint?
No. Google states that resetting the upload key does not affect the app signing key.
Sources
Last reviewed: 19 October 2026.
