Choose the distribution path first
Decide whether the app is a local debug build, a locally signed release, a Play-installed release or an internal app-sharing build. Write that label next to the fingerprint before copying it into Firebase or another API configuration.
For Play App Signing, the upload certificate is not necessarily the certificate on the APK delivered to users. Play signing identities.
Read from the artifact or authorized keystore
For an APK:
apksigner verify --print-certs app.apk
For a keystore entry:
keytool -list -v -keystore release.jks -alias release
The first operation also performs APK verification; the second inspects the selected keystore entry. Enter private-store credentials locally and do not put them into shared documentation. Signing tools.
Compare like with like
| Value | Changes when |
|---|---|
| APK SHA-256 hash | The artifact's bytes change |
| Certificate SHA-256 fingerprint | The certificate changes |
| Certificate SHA-1 fingerprint | The certificate changes; SHA-1 and SHA-256 are different digest representations of the certificate. |
| Application ID | The installed/store identity is configured differently |
A service can require a particular combination of application ID and fingerprint. Correctly entering a fingerprint for the wrong package still produces an invalid registration.
Diagnose a release-only login failure
Check the installed build's certificate, not merely the key used by CI to upload the AAB. Add the intended certificate through the service's supported registration workflow, refresh configuration if required and reinstall or retest the exact distribution path.
Do not delete all old fingerprints without understanding which testers or older signed paths still use them. Keep an inventory so obsolete records can be removed deliberately.
Treat fingerprints as public identifiers
Certificate fingerprints are not private signing keys. Sharing a fingerprint does not enable someone to sign an app as you, but it also does not prove that a screenshot or text message containing it is authentic. Obtain expected values through trusted channels.
APKLint can display certificate metadata from an APK. Compare that information with your release register and use Android's signing documentation when managing the underlying private credential.
Build a registration table for one application
For com.example.notes, create separate rows for the local debug build, a locally signed release and the Play-distributed release. Store the requested certificate algorithm and fingerprint in each row, with the service registration that uses it. Two rows may share a value, but do not merge them merely because both are described informally as “release.” Their operational roles still differ.
If a service requests SHA-1, supply the SHA-1 fingerprint of the relevant certificate. Do not shorten a SHA-256 value or hash its displayed hexadecimal string to manufacture a SHA-1 fingerprint. Both are computed from the certificate according to the requested algorithm. The Android signing guide describes certificate information used by API providers.
Normalize formatting without changing identity
Some interfaces display uppercase hexadecimal with colon separators, while another display may omit the separators. Normalize only formatting when comparing values, and verify that both labels name the same algorithm and object. An APK digest and a certificate digest remain different fields even after they are formatted identically. Keep the original labelled output in the review record to make the comparison auditable.
For a release-only login problem, obtain evidence from the exact installed distribution path. A successful local test signed with the upload credential does not identify the certificate on a Play-delivered APK. Compare the service's package-name and certificate combination, then retest after a supported registration correction. Avoid deleting unrelated development registrations while diagnosing one production row.
When a signing transition is planned, preserve the effective dates and supported distribution paths for each identity. An old fingerprint may still be required for a supported installed population. Remove registrations only after understanding which builds use them. A tidy table is valuable because it connects public identity to actual releases, not because it contains only one fingerprint.
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
