Signing is the mechanism Android uses to know that an update comes from the same publisher as the original install. Get it wrong and users cannot update; lose the key and, historically, you could never update again. Google changed that with Play App Signing. Here is how the pieces fit for a publisher who just wants their app to keep working.
The idea
Every APK is signed with a private key. Android records the certificate at install time and refuses any later APK for the same package name signed with a different certificate. That is why "app not installed" appears when you sideload a rebuilt app over a Play-installed one, and why the key matters more than the code.
Play App Signing: two keys
Since 2021, Play App Signing is mandatory for new apps. It splits the role in two:
| Upload key | App signing key | |
|---|---|---|
| Who holds it | You | Google, in Play's infrastructure |
| What it signs | The AAB you upload | The APKs users actually install |
| If lost | Reset via Play Console support — a few days | Cannot be lost by you; Google keeps it |
| Fingerprint used for | Verifying your uploads | Digital Asset Links, Firebase/OneSignal configuration, any service that checks the installed app's certificate |
When you upload your first bundle, Play offers to generate the app signing key (default and recommended) and registers your bundle's certificate as the upload key. From then on, only that upload key may sign what you upload, and users only ever see the app signing key.
Which fingerprint goes where
Play Console → Test and release → Setup → App signing shows both certificates with MD5, SHA-1 and SHA-256 fingerprints. The one you need almost always is the app signing key certificate, because it is the certificate on the app that is actually running on phones:
- Digital Asset Links (
assetlinks.json) for Trusted Web Activities and Android App Links: app signing key SHA-256. - Firebase / Google Sign-In / Maps restrictions: app signing key SHA-1 or SHA-256, plus the upload key if you test with local builds.
- OneSignal: no fingerprint needed for basic push; Firebase configuration inside OneSignal follows the Firebase rule if you use it.
Putting the upload key's fingerprint where the app signing key's is expected is the number-one cause of "works in testing, breaks in production".
Losing the upload key
Because Google holds the app signing key, a lost upload key is an inconvenience, not a catastrophe. Generate a new key, export its certificate, and file an upload-key reset request from the App signing page. Google verifies the account owner and switches the registered upload key within a few days; existing users are unaffected because the app signing key never changed.
Apps published before Play App Signing
Older apps that never enrolled still ship the developer's own key to users. For those, losing the keystore means no more updates under that package name — the reason the rule exists. Enrolment for existing apps is optional but recommended; Google provides an encryption tool to upload your existing key securely, after which it becomes the app signing key.
How the builder signs
The builder generates its signing key deterministically from your package name, so rebuilding tomorrow with the same package name produces the same certificate. In practice: you can always produce an update that Play accepts as coming from the same upload key, without keeping a keystore file at all. The derived key becomes your upload key at first upload; Play's app signing key protects users. It also means the package name is the secret to guard — someone building with your exact package name gets the same certificate, which is one more reason package names should be specific to your domain and never published in a template.
Checklist
- Enrol in Play App Signing at first upload (default).
- Copy both SHA-256 fingerprints from the console into your project notes.
- Use the app signing key fingerprint in
assetlinks.jsonand third-party consoles. - Never change the package name; it is the identity the key is derived from and the identity Play knows.