Guide summary
Choose the correct Android signing key, register additional SHA-256 certificates and resolve eligibility or key-mismatch messages without exposing private keys.
For: Android release owners who see eligible-key, additional-key or signing-key mismatch messages while registering an existing package.
Release sequence
- Inventory the artifact users receive from each active distribution channel.
- Extract its public SHA-256 certificate fingerprint and label the key as app signing, upload, legacy or channel-specific.
- Select an eligible key or use the official review path, then add every legitimate key that signs a distributed version.
- Complete the requested ownership proof and recheck the exact package-and-certificate pair.
Quick facts
Do not rotate a production signing key because it is absent from an eligible list. Confirm the artifact and key role, preserve update continuity and use the official request or review path.
Detailed guidance
Register the certificate that signs the installed app
Start with the artifact users actually install. With Play App Signing, Google signs delivered APKs with the app signing key, while your upload key only authenticates uploads. A website build or another store can use a different production certificate.
Extract the SHA-256 certificate from each distributed APK and label where it is used. Registering a familiar keystore alias is not enough if that key does not sign the installed app.
- Play-delivered APK: app signing certificate.
- Play upload: upload certificate with a separate purpose.
- Other channel: inspect that channel's production APK.
apksigner verify --print-certs app-release.apkChoose the eligible-key or review path
For an existing package, the console can show signing keys already associated with its history. Select the key that matches the version users receive. If the correct production key is not eligible, verify that you have not selected an upload or debug key, then use the console's request or review path and explain the distribution history.
For a new package name, follow the current console flow and keep the package, certificate and developer account together in the release record. Do not create a replacement key merely to make a list entry appear.
- Compare SHA-256 fingerprints, not key aliases.
- Keep evidence for legacy and channel-specific releases.
- Preserve the key that maintains app-update continuity.
Add every legitimate distribution key
A package can have more than one legitimate signing key when different channels or approved signing histories are involved. Add each public certificate through the official additional-key workflow and give every fingerprint a clear channel and owner label.
When the console asks for ownership proof, complete that challenge with the matching signing key. The proof can involve a signed APK and adi-registration.properties; it never requires uploading your private key.
- Add only keys that sign a real distributed artifact.
- Keep private keys inside the existing signing system.
- Allow the console to finish processing before rechecking status.
Separate registration errors from Play upload errors
A registration mismatch means the package is registered with another certificate fingerprint. A Play message saying an App Bundle was signed with the wrong key is an upload-key or Play App Signing problem. The two messages can involve the same package but require different fixes.
Use the package-and-certificate status check to validate registration. Use Play Console's certificate pages and upload guidance to diagnose an AAB rejection. Rotating either key before identifying the failing layer can make recovery harder.
- Registration check: package plus public certificate.
- AAB rejection: expected upload certificate.
- Installed Play identity: app signing certificate.
Frequently asked questions
Can one Android package have multiple signing keys?
Yes. Additional legitimate keys can be registered when they represent real distribution channels or an approved signing history. Record which artifact and channel each SHA-256 fingerprint belongs to.
Which key should I use with Play App Signing?
For the identity of an app delivered by Google Play, use the app signing certificate. The upload certificate authenticates your bundle upload and can be different.
What if my production key is not eligible?
First confirm that it signs the installed production artifact rather than an upload or debug build. Then use the official console request or review flow and provide the requested distribution evidence.
Do I need to upload my private signing key?
No. Registration uses the public certificate fingerprint. Ownership proof may require an APK signed by the matching private key, but the key itself stays in your keystore or signing service.
Why does Play say my App Bundle uses the wrong key?
That message normally concerns the upload certificate expected by Play, not the certificate registered for Android developer verification. Diagnose it in Play Console before changing any key.
Sources and review
Last reviewed: