Android keystore guide for signing and Play
Losing a release keystore can block app updates—operate with backups and access controls.
Upload key vs app signing key
With Play App Signing, Google holds the app signing key while you rotate upload keys if compromised.
About this Android keystore resource
This page is an educational overview only. APKBuild.org does not host cracked APKs, mod games, or pirated software. We link to official tooling concepts and safe workflows for developers.
Always download Android Studio, SDK components, and signing utilities from official Google channels or your organization’s software catalog.
Legal and safe usage
Respect software licenses, Play policies, and user privacy laws. Enterprise teams should route installs through MDM and approved portals rather than anonymous file shares.
If you distribute internally, document who signed the build, which keystore was used, and how updates will be delivered.
How this ties into APKBuild.org
After you understand the tooling landscape, use the online builder to package your HTTPS PWA or ZIP project. You get logs, artifact download, and a path to AAB when Play is ready.
Creating a keystore with keytool, exactly once
One command creates the key: `keytool -genkeypair -v -keystore release.jks -alias upload -keyalg RSA -keysize 2048 -validity 10000`. The alias is the name you will reference in Gradle or in `apksigner`, and the password protects both the keystore and the key itself. Use a generated password from a password manager rather than something memorable.
`-validity 10000` is about 27 years, which is the right order of magnitude: Play requires a key valid past 2033 for new apps, and validity cannot be extended after creation. Choose RSA 2048 or larger; the defaults on older JDKs are weaker than what Play expects today.
Losing the key: the failure that ends a package
Android identifies an app by its package name plus its signing certificate. A build signed with a different key is a different publisher, so it cannot update an installed app and Play will not accept it for an existing listing. There is no recovery through Android itself — which is why the keystore, the alias, and the password belong in three separate places, at least one of them off your laptop.
Treat the keystore as a company asset, not a build artefact: store it in a password manager's file vault or an encrypted backup, record the SHA-256 fingerprint alongside it, and note which app each key signs. When a build is done on a server, the key lives on the server — back it up from there before the first release, not after.
Play App Signing: which key you actually keep
With Play App Signing — mandatory for new apps — Google holds the app signing key and you keep an upload key. You sign each release with the upload key, Play verifies it, then re-signs the distributed APK with the app signing key. The practical benefit is that a lost upload key can be reset through support, which turns a fatal mistake into an inconvenient one.
What you still must protect: the upload keystore, because it authorises releases, and the Play Console account itself, because whoever controls it controls the listing. For apps distributed outside Play, there is no Google-held key at all — your keystore is the only identity the app will ever have.
Frequently asked questions
How many years should keystore validity be?
Set at least 25 years — the common choice is `-validity 10000`, about 27 years. Google requires the key to remain valid past 2033 for new apps, and the value is fixed at creation, so a short default is a problem you cannot fix later without a new key.
Can I reuse one keystore for several apps?
Technically yes, and some studios do it for internal builds, but each app should have its own key. A shared key means one leak compromises every app it signs, and Play treats the signing identity per app — separate keys keep the blast radius to one listing.
What is the alias for?
One keystore file can hold several keys, and the alias selects which one signs. You need the alias every time you sign or configure Gradle, so record it with the password. A forgotten alias is recoverable with `keytool -list`; a forgotten password is not.