Google holds your app signing key. The one you can actually lose is the upload key.

What is Play App Signing, and which key does Google hold?

Play App Signing means Google manages and protects your app's signing key on the same infrastructure it uses to store its own keys, protected by Google's Key Management Service. Play Console Help, read on 21 October 2026, says you deal with two distinct keys when you use it, and lists them with the holder next to each.

The upload key is yours. It lives in a Java keystore, a .jks or .keystore file, and it has to be an RSA key of 2048 bits or more. You sign the app bundle with it before uploading, and Google uses it to verify your identity. The app signing key belongs to Google Play. A Google-generated one is RSA 4096 bit, and a key you supply yourself must be RSA 2048 bit or higher. Google signs the finished APKs with it. The page adds a plain instruction next to the table: for maximum security, your upload key and app signing key should be different.

There is a third row in that table now, and it is new enough that almost nothing outside Google mentions it. An app can be on quantum-ready hybrid signing, which combines a classical RSA 4096 bit key with a post-quantum ML-DSA-65 key. Google generates a separate classical key for the hybrid signature, different from the classical key it uses for devices older than Android 17, so one app ends up using three distinct keys. Devices on Android 17 and above verify it with APK signature scheme v3.2. As of 21 October 2026, Play Console Help says a newly created app is enrolled in this by default.

One practical detail before you go looking for the screen. Play Console Help states that you must have admin permission to configure Play App Signing, so this is not a step you can hand to someone with a narrower role. And the two Google pages give different menu paths, which is worth knowing when a screenshot you found does not match your console. Play Console Help, the newer of the two, says Protected with Play, then Play Store distribution, then Go to Play app signing. The Android Studio page still says Release, then Setup, then App signing.

Google Play Console Help, Use Play App Signing, read 21 October 2026

What happens if you lose the upload key?

Play Console Help answers this in one sentence: if you lose your upload key or suspect that it was compromised, you are not locked out of your app. The documented fix has three steps. Create a new upload key in Android Studio. Export its certificate to PEM format with the keytool export command, which Google prints in full on the page. Then submit the reset request in the Play Console, under the upload key certificate section, where you enter a reason, attach the .pem file and click Request.

The reason this works is the separation, and the Android Studio page spells it out twice. Resetting your upload key will not affect the app signing key that Google Play uses to re-sign APKs before delivering them to users. And because your app signing key is secured by Google, you can continue to upload new versions of your app as updates to the original app even if you change upload keys. Your existing installs carry on updating, because the certificate on the device still matches. The google play signing upload key walkthrough takes the generate and register steps in order.

A forgotten keystore password lands in the same place, and it is worth saying what the documentation does and does not cover. Neither of Google's two pages describes a password recovery. The Android Studio page only tells you to select strong passwords for the keystore and key, and not to let anyone else learn them. Google never held your password, so there is nothing to reset. A keystore you cannot open is a keystore you cannot sign with, which puts you on the upload key reset path with everyone who lost the file itself.

So the honest advice about the upload key is narrower than the internet's advice. Back it up, because a reset takes a review and a wait that you do not want in the middle of a release. But a lost upload key is an inconvenience, not a dead app. Keep the keystore, the alias and the two passwords together, and keep them somewhere a dead laptop cannot take with it. The android keystore backup steps cover where to put it.

Android Studio, Sign your app, last updated 6 March 2026, read 21 October 2026

What happens if you lose the app signing key?

Two answers, and which one applies to you depends on who was holding the key. With Play App Signing configured, there is nothing on your side to lose. Google states that after you configure it, with either an auto-generated key or a key that you supply, you cannot retrieve a copy of your app's signing key, and that Google may retain a backup copy of the key for disaster recovery purposes. You can download the public certificate, which is meant to be shared, but never the private key.

If you never enrolled and manage your own signing key, the wording gets short. Google writes that your private key is required for signing all future versions of your app, that if you lose or misplace it you will not be able to publish updates to your existing app, and that you cannot regenerate a previously generated key. The Play Console Help table says the same thing in its own column: this key cannot be reset if you manage it yourself and lose it. There is no support queue for this one.

The reason is in the install model rather than in a policy. When the system installs an update, it compares the certificates in the new version against those in the existing version, and allows the update only if they match. Sign with a different certificate and you must assign a different package name, which means users install it as a completely new app, with no ratings, no installs and no path to carry anyone across. That is the cost people discover too late.

There is one documented way to change an app signing key on a live app, and it is deliberately limited. If the key is compromised or you need a cryptographically stronger one, you can request an annual key upgrade. As of 21 October 2026, Play Console Help scopes it by platform version. Android 17, API level 37, and above strictly enforce the upgraded quantum-ready hybrid key. Android 13 to Android 16 strictly enforce your latest classical key. From Android 7 to Android 12 the platform does not enforce the upgraded key at all, and Play Protect does the checking instead unless a user has turned it off. An upgrade is not a rescue for a lost key, because you still need the account and the app.

Two numbers are worth copying into your own notes, and both survive checking rather than contradicting the usual advice. Google recommends a validity period of 25 years or more, so the key outlives the app. And a key used to sign an app published on Google Play must have a validity period ending after 22 October 2033, which Google says it enforces so that users can keep upgrading. Both figures sit on the Android Studio signing page, last updated 6 March 2026 and read on 21 October 2026. When the validity period expires, users can no longer seamlessly upgrade to new versions.

Android Studio, Sign your app, last updated 6 March 2026, read 21 October 2026

Is enrolling optional for a new app?

No, and the documentation is unusually direct about it. The Android Studio signing page says Play App Signing is optional for apps created before August 2021, and that configuring it is required to sign your app for distribution through Google Play, with the same exception named again in brackets: apps created before August 2021 may continue distributing self-signed APKs. Read on 21 October 2026, that cut-off is more than five years old, so in practice every new app is in.

Play Console Help says it from the other direction, as a default rather than a requirement. Create a new app and it is automatically enrolled in quantum-ready hybrid signing with Google-generated keys. Upload your bundle and the same sentence appears again: by default your app is automatically enrolled. Nothing on either page offers an opt-out for a new app.

What is optional is which key Google holds, and that choice has a deadline. Play Console Help says you can change the app signing key before there is a release rolled out in the open testing track or the production track, and offers two routes: use the same key as another app in the developer account, or provide a copy of your own app signing key. After a release reaches open testing or production, that door closes. If you already ship to another store with a key of your own, decide this before your first open track, not after.

There is one more route, and Google labels it rather than hides it. A self-hosted Google Cloud project lets you enrol through the Play Developer API with keys in your own Cloud KMS. Google calls the setup non-standard and not encouraged, says you assume full responsibility for app signing operations, and warns that it prevents Google Play from performing essential features like disaster recovery. Google also says it cannot regenerate or fix an existing release in that configuration, and that quantum-ready hybrid signing may not be available. That is a narrow box for OEM key requirements, not a privacy preference.

If you distribute outside Google Play as well, Google documents two ways to keep one key everywhere. Let Google generate the app signing key and download a signed universal APK from the Play Console or the Play Developer API to distribute elsewhere, or generate the key yourself and transfer a copy to Google when you configure Play App Signing. The iOS side of a release has its own credentials to keep safe, and the app store connect api guide covers those.

Google Play Console Help, Use Play App Signing, read 21 October 2026