Find SHA-1 and SHA-256 Fingerprints for the Correct Android Build

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

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.