On this page (8 sections)
Two keys, two very different situations
| Key | Who holds it | If lost |
|---|---|---|
| App signing key | Google (Play App Signing) — or you, for legacy apps that never enrolled | With Play App Signing: nothing is lost. Without it: updates are impossible with the old identity |
| Upload key | You — a .jks / .keystore file (RSA 2048+) used to sign bundles before upload | Resettable: create a new key, export its certificate as PEM, request a reset in Play Console |
Google’s own words: “If you lose your upload key or suspect that it was compromised, you are not locked out of your app.” That sentence applies to apps on Play App Signing. Source: Play Console Help, Use Play App Signing (verified 22 September 2026).
Scenario A — Play App Signing enabled, upload key lost or compromised
- Generate a new upload key in Android Studio (Build → Generate Signed Bundle / APK → Create new…), or with
keytool. - Export the certificate in PEM form:
keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem - In Play Console: the app → Test and release → Setup → App signing (Google currently labels the path under Play Store protection / Manage Play app signing) → request an upload-key reset and attach the PEM file.
- Google’s support team registers the new certificate; from then on, bundles signed with the new upload key are accepted, and Google keeps signing releases with the unchanged app signing key — users notice nothing.
Until the reset is processed, releases are blocked; do this before the target-API or Billing Library deadline release, not on the day.
Scenario B — Legacy app, self-managed signing key lost
If the app was never enrolled in Play App Signing and the only key is gone, no build can ever again be signed with the app’s identity. There is no reset, because Google never held the key. The realistic options:
- Search properly first — CI secrets, old developer machines, backups, the agency that built the app, Android Studio default paths, password managers. A surprising share of “lost” keys are found.
- Publish a new app under a new package name and migrate users: in-app announcement and deep link from the old app if it can still be updated (it cannot, if the key is truly gone), listing cross-links, backend account continuity, subscription handling (Play subscriptions are tied to the package name and cannot be moved), and a data migration path for local data.
- This is also the scenario Android developer verification punishes: “If you lose your signing key you won’t be able to register your packages.”
Enrol every remaining self-signed app in Play App Signing now
Play Console allows enrolment for existing apps by uploading the current signing key (Google provides the PEPK tool for the encrypted transfer). Once enrolled, the key you hold becomes an upload key, and this page collapses to Scenario A for the rest of the app’s life.
Scenario C — Mismatch: wrong key used, debug key, or a teammate’s copy
The upload error prints the expected and the uploaded SHA-1. Compare with keytool -list -v -keystore your.jks. Common causes: a CI job signing with a fresh debug key, a Flutter or React Native project whose key.properties / gradle.properties points at the wrong file, two keystores with the same alias, or Unity’s Player Settings reset to the debug keystore. Fix the configuration, rebuild, re-upload — no reset needed.
Scenario D — Key upgrade for security or after a transfer
Play App Signing supports an app signing key upgrade — Google can generate the new key or you can supply one; new installs on recent Android versions use the new key while existing installs continue to receive updates. Google also allows requesting a new upload key after an app transfer when the previous owner still holds the old file. After any change of the Google-held signing key, register the new certificate fingerprints with every API provider (Google Sign-In, Firebase, Maps, Facebook and other SDK consoles).
The developer verification angle
Under Android developer verification, package registration “may include proving ownership of the private signing keys used for those packages”. Apps on Play App Signing are registered automatically; apps signed with a key you can no longer present cannot be registered. Resolving key custody now avoids losing the package name in 2027.
What we do
- Diagnose the scenario from the upload error, the Play App Signing status and the build configuration — without receiving any private key.
- Scenario A: prepare the new upload key and PEM, guide the reset request, re-configure CI and the framework’s signing files.
- Scenario B: run the recovery search with you; if the key is really gone, plan and build the successor app and the user-migration path.
- Scenario C/D: fix signing configuration, perform the key upgrade, and update fingerprints in every API console so sign-in and maps keep working.
Key hygiene, briefly
Keep the upload keystore and its passwords in a secrets manager with at least two custodians, never in the repository, never only on one laptop. Rotate access when developers leave. Let Google hold the app signing key.
Checklist
- Play App Signing status confirmed for every app
- Upload keystore, alias and passwords stored with two custodians
- Certificate fingerprints (upload and app signing) recorded and registered with API providers
- CI and framework signing configuration point to the right keystore
- Upload-key reset requested well before a deadline release
- Legacy self-signed apps enrolled in Play App Signing