Play App Signing in 2026: Upload Keys, Lost-Key Resets, and Key Upgrades

Every app on Google Play is signed twice: once by you, before the upload, and once by Google, before the file reaches a user's device. The key behind that second signature — the app signing key — is the one piece of an app that cannot be replaced by re-uploading a bundle, and since 2026 a large part of it lives in Google's own key infrastructure. This guide covers what Play App Signing does, how the three key types differ, how new and existing apps enroll, which fingerprints your API providers actually need, what to do when an upload key is lost, and how app signing key upgrades are enforced across Android versions.

Why the signing key matters more than the account

Developer accounts can be renamed, re-verified, transferred between owners, and migrated to organizations. Signing keys cannot. Android decides whether an update is legitimate by checking that the new APK is signed with the same key as the installed one — if that chain breaks, the only way to ship a "new version" is to publish a different app and ask users to install it again, losing installs, reviews, and history.

That single fact is why Play App Signing exists. Since August 2021, new apps on Google Play are expected to use it, and today it is the default path: Google holds the key that signs the distribution APKs, so a lost laptop, a stolen keystore, or a departing developer can no longer end an app's life. What you keep — and what most people still call "the keystore" — is the upload key, and that one can be reset.

Three key types, three very different jobs

Play's own documentation separates the keys by who holds them and what they sign. Getting this mapping right is what prevents both authentication bugs (wrong fingerprint registered with an API) and panic (thinking a lost keystore is fatal).

Upload key — held by you. Stored in a Java keystore (.jks or .keystore) and must be an RSA key of 2048 bits or more. You use it to sign the app bundle before uploading; Google uses it to verify that the upload came from you. If it is lost or compromised, Google can reset it.
App signing key — held by Google Play. Associated with a public certificate (.der or .pem). Google-generated keys are RSA 4096-bit; keys you provide yourself must be RSA 2048-bit or higher. This is the key that signs the optimized APKs delivered to users. You can let Google generate it, or supply your own.
Quantum-ready hybrid keys — held by Google Play. A hybrid signature that combines a classical RSA 4096-bit key with a post-quantum ML-DSA-65 key. Android 17 and above verifies apps with the APK signature scheme v3.2; older devices keep verifying through the classical signature block. Because Google generates a separate classical key for the pre-Android 17 path, an app can end up using three distinct keys at once.

Google's own note on the design: for maximum security, your upload key and your app signing key should be different keys.

When Google signs your APKs it also stamps the manifest with com.android.stamp.source and com.android.stamp.type, so a delivered APK remains traceable to the original signer. Changing anything on this page requires admin permission in the account — which is why the person holding admin effectively controls the app's future, not just its settings.

What enrollment unlocks

Play App Signing is not only a key-custody service. Letting Google sign the optimized APKs generated from your bundles is what enables automatic protection and automatic strings translation (powered by Gemini models), and for games it unlocks services such as Play Games Sidekick, Play-as-you-download, and free trials for paid titles. An app that manages its own signing keys outside Play App Signing simply does not get these.

Enrolling a new app

Create the app. A newly created app is automatically enrolled in quantum-ready hybrid signing with Google-generated keys; Google also generates a separate classical key for signature blocks recognized on Android 16 and below.
Create an upload key. Generate a keystore to sign your release bundle — either in Android Studio or with the Java keytool utility from the command line. Keep this file and its passwords somewhere you will still have them in two years.
Upload the app bundle. Preparing a release and uploading the .aab is what completes the automatic enrollment.
Optionally change the app signing key. Advanced developers who want to manage their own key can do this before any release has been rolled out on the open testing or production tracks: go to Protected with Play > Play Store distribution > Go to Play app signing and click Change the app signing key. You can either reuse the same key as another app in the developer account, or provide a copy of your own app signing key.

Migrating an existing app

If you still manage your own keys and upload APKs, you can upgrade to Play App Signing to get app bundles and the rest of the Play enhancements:

Go to Protected with Play > Play Store distribution > Go to Play app signing in Play Console.
Accept the terms of service if you have not already.
Transfer a copy of your original signing key. Download the PEPK tool and follow Google's step-by-step instructions to encrypt and upload your existing key from whatever repository it lives in. This is what preserves the update path for already-installed users.
Create a new upload key (recommended). Generate a fresh key in Android Studio and register its certificate in the console, so the key you use for day-to-day uploads is no longer the key that signs for users.

Register the right fingerprints with your API providers

This is the step that breaks apps after enrollment. Services such as Google Maps, OAuth, or Facebook Login authenticate your app by the app signing key's fingerprint. Because Google now signs the final APK, the fingerprint that reaches users is the one held by Google — so you must register the Google-held app signing key fingerprint with each provider, not only the local upload key fingerprint.

Open Protected with Play > Play Store distribution > Go to Play app signing and scroll to the App signing key section.
Copy the SHA-1 or SHA-256 fingerprints required by the provider and paste them into that provider's console (for example, Google Cloud Console for Maps and OAuth).
If your app uses quantum-ready hybrid signing, copy and register the fingerprints of three keys: the new classical key and the post-quantum key used on newer devices, plus the classical key used on older devices.
If you use Android App Links, update assetlinks.json with the same fingerprints.

When the upload key is lost or compromised

Losing an upload key does not lock you out of your app. The recovery path is documented and routine:

Create a new upload key in Android Studio.
Export its certificate to PEM format:

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

In Play Console, go to Protected with Play > Play Store protection > Manage Play app signing.
In the Upload key certificate section, click Request upload key reset.
Enter the reason for the reset, upload the upload_certificate.pem file, and click Request.

Until the reset is processed you cannot upload new releases, so plan the recovery before a deadline, not after one. Note the asymmetry: the upload key is resettable, the app signing key is not something you can simply ask Google to replace on demand.

Upgrading the app signing key

If an app signing key is compromised, or you need a cryptographically stronger one, Play supports an annual key upgrade that applies to installs on Android 17 (API level 37) and above. Enforcement differs by platform version:

Android 17 (API 37) and above: the platform strictly enforces the upgraded quantum-ready hybrid key, verified through APK signature scheme v3.2.
Android 13 (API 33) to Android 16 (API 36): the platform strictly enforces your latest classical key, per APK signature scheme v3.1.
Android 7 (API 24) to Android 12 (API 32): the platform itself does not enforce the upgraded key and still recognizes the latest classical key. Google Play Protect adds validation by checking that updates are signed with your latest classical key, unless the user has turned that off.

One consequence is easy to miss: because the platform does not enforce the upgraded key on Android 12 and below, apps that share the same signing key across multiple apps to share data will, on those older versions, only recognize the legacy key for features such as custom permission sharing.

To run the upgrade: open Protected with Play > Play Store distribution > Go to Play app signing, click Upgrade key under the App signing key section, choose a path — let Google Play generate a new key (recommended), reuse the app signing key of another app in the account, or provide a copy of your own — and click Save. Then register the new fingerprints with your API providers. With quantum-ready hybrid signing, that means two new keys: the new classical key and the new post-quantum key.

Publishing outside Google Play

If you distribute the same app through other Android stores and want one signing identity everywhere, you have two options:

Let Google generate the app signing key, then download a signed universal APK from Play Console (Test & release > Latest releases and bundles, select the bundle, open the Downloads tab) or via the Play Developer API, and distribute that file elsewhere.
Generate the app signing key yourself and transfer a copy of it to Google when you configure Play App Signing, so the same key is used across stores.

Play App Signing also applies APK signature scheme v4 automatically for eligible apps to support optimized distribution on Android 11 and above — no action required. The exception is apps using quantum-ready hybrid signing, which is not yet compatible with v4 signing.

The pitfalls that cost real apps real installs

Treating the upload keystore as disposable. Google can reset an upload key, but you still cannot upload anything until the reset is processed. Back up the keystore file and its passwords outside the build machine.
Registering only your local fingerprint. After enrollment the delivered APK carries Google's app signing key fingerprint. Maps, OAuth, and login providers that only know your old fingerprint will fail.
Forgetting assetlinks.json. Android App Links verification depends on the same fingerprints.
Changing the signing key after release. Changing the default app signing key is possible before anything is rolled out to open testing or production — not after. Plan key decisions at app creation, not at first update.
Ignoring the old-Android path in hybrid signing. Apps using quantum-ready signing have three keys, and providers need all of the relevant fingerprints, not just the newest one.
Assuming updates behave the same on every Android version. Enforcement of upgraded keys stops at Android 12, where Play Protect — not the platform — does the checking.
Self-hosting the key in your own Cloud project. Google supports enrolling through a self-hosted Google Cloud project for highly specific requirements, but documents it as non-standard and not encouraged: you take full responsibility for signing operations, lose disaster recovery, and may lose advanced optimizations, certain Play enhancements, and features such as quantum-ready hybrid signing. Google cannot regenerate or fix an existing release in that setup; the fix is a new release.
Weak access control. Everything on the app signing page is admin-level. Enforce 2-Step Verification for every user in the account.

The one-line model: your upload key proves who you are and can always be reset; the app signing key proves your app's identity to every installed device and is the asset you must never lose or leak. Enroll in Play App Signing, register the Play-held fingerprints everywhere your app authenticates, and treat the keystore in your build pipeline as production infrastructure — backed up, access-controlled, and replaced only deliberately.