Decide the key's role
For a new Play app using Play App Signing, review the available app-signing arrangements and keep the upload credential separate where appropriate. For another store or direct APK distribution, understand which key must sign future updates.
Do not create a replacement key for an already published package unless the documented rotation or reset workflow permits it. Android signing guide.
Generate through a controlled toolchain
Android Studio's signed-bundle/APK wizard provides a Create new keystore workflow. A command-line alternative can use keytool; a generic example is:
keytool -genkeypair -v \
-keystore upload-keystore.jks \
-alias upload \
-keyalg RSA -keysize 2048 -validity 10000
This is an illustrative upload-key generation command, not an instruction to replace an existing production key. Check the store's current requirements and your organization's cryptographic standards. Enter passwords through prompts rather than command arguments saved in shell history.
Record public identity and private custody separately
Keep the alias, certificate fingerprints, intended application IDs, creation date and responsible owner in release documentation. Store the private keystore and passwords in approved restricted systems, not in that public ledger.
A certificate's subject fields are descriptive. They do not establish that a package came from the organization named in the text, and they are not substitutes for comparing trusted fingerprints.
Test the recovery procedure before the first emergency
Create an encrypted backup and verify that an authorized recovery operator can restore it and inspect the expected alias. Protect backup access separately from ordinary build access where feasible.
A backup that has never been tested may contain the wrong file, an outdated password or only the public certificate. Exporting a certificate is not a backup of the private signing key.
Integrate with the release pipeline
Configure the exact release variant to use the intended credential, build a test artifact and independently verify its signature. Record whether Firebase, API restrictions or other services need the upload, local-release or Play app-signing fingerprints.
APKLint can inspect the resulting APK's public signing metadata. Never upload the keystore itself for an APK check. The analysis tool does not need your private key or password to show the certificate embedded in a signed package.
Verify the new entry before wiring it into CI
After creating a credential for a new application's intended signing role, inspect the entry locally with keytool -list -v -keystore upload-keystore.jks -alias upload. Confirm that the alias exists and that the entry contains the private-key material needed for signing, rather than only a trusted public certificate. Record the certificate fingerprints and validity information in the release register without copying the password or private key into that register.
Be explicit about the keystore format when a particular integration requires one. A .jks filename does not by itself establish that the file uses the JKS format; the JDK tool's default and the selected options matter. The keytool manual documents store types and entry inspection. Match the chosen format to your actual build tooling instead of renaming an incompatible file.
Rehearse a small recovery before the first release
Restore an encrypted backup into an authorized temporary release environment and inspect the expected alias. Then sign a nonproduction test artifact and compare its certificate with the recorded identity. This tests the backup file, the stored credential reference and the operator's access procedure together. A backup check that merely confirms a file exists would miss a wrong alias or a certificate-only export.
Give the credential a documented purpose such as “upload key for the notes application.” A name like release.jks is too ambiguous when several apps and distribution channels share a build system. Associate the key with application IDs, its authorized custodians and the procedure for changing its use. Do not create a new key during every clean CI run; that would change identity rather than reproduce the release setup.
Finally, verify the signed candidate produced by the actual release task. The creation command establishes a credential, while the artifact check establishes which credential the build used. Keeping those two observations separate catches a pipeline that generated the right key but continued signing with an older configuration.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
