Introduction

The SHA-1 fingerprint used by many Android integrations comes from the app signing certificate, not from the source code. You usually need it for Firebase, Google Sign-In, Maps, and similar service configuration. The important part is generating the fingerprint from the correct keystore for the build variant you are actually shipping.

Know Which Certificate You Need

Most Android projects have at least two signing contexts:

• debug signing certificate for local development
• release signing certificate for production

If a feature works on local debug builds but fails after release, the release certificate fingerprint is usually missing from the external service configuration.

There is another wrinkle with Google Play App Signing: the upload key and the final app-signing key may be different. If the provider expects the production certificate, make sure you register the right one.

Fastest Method: Gradle signingReport

For Android Native, Flutter, and React Native projects with an Android module, the simplest option is Gradle’s signing report.

From the Android project directory:

./gradlew signingReport

On Windows:

gradlew signingReport

This prints signing information for build variants, including SHA-1 and SHA-256. Copy the SHA-1 value for the variant you need.

Use keytool for a Specific Keystore

If you want to inspect a keystore directly, use keytool.

Debug keystore example:

1keytool -list -v \
2  -keystore "$HOME/.android/debug.keystore" \
3  -alias androiddebugkey \
4  -storepass android \
5  -keypass android

Release keystore example:

keytool -list -v \
  -keystore /path/to/release.keystore \
  -alias release_alias

This method is especially useful when you want to verify that the Gradle report is using the keystore you think it is.

Flutter Workflow

Flutter Android builds still use the Android Gradle toolchain under the android folder.

cd android
./gradlew signingReport

If release signing is configured with key.properties or Gradle variables, confirm that the expected release keystore is referenced before trusting the output.

React Native Workflow

React Native follows the same Android-side process because the Android app lives under its own Gradle project.

cd android
./gradlew signingReport

If the release config depends on environment variables, make sure those values are available when you run the report. Otherwise the release fingerprint may not reflect the real production signing setup.

Register the Fingerprints in the Right Place

Once you have the fingerprints, register them in the service that requires app identity verification. A practical checklist:

• add the debug SHA-1 for development workflows
• add the release SHA-1 before production rollout
• keep SHA-256 values too when the provider supports them
• verify the package name matches the same app entry

Many integration failures come from having the correct SHA-1 but the wrong package name, or the correct package name but the wrong certificate.

Verify the Build Variant You Test

After updating the external service configuration, test with the same signing path you configured. A debug build proves only the debug fingerprint. A locally signed release APK proves only the release key used for that build.

If the app is distributed through Play App Signing, confirm whether the provider should use the upload certificate or the Play-managed app-signing certificate.

Keep Keystore Handling Secure

Release keystores are sensitive assets. Good practice includes:

• never commit keystores or passwords to source control
• restrict who can read the release keystore
• store secrets in a secure manager or CI secret store
• document certificate rotation steps

Fingerprint generation is easy. Recovering from lost or mishandled signing credentials is not.

Common Pitfalls

The biggest mistake is registering only the debug SHA-1 and forgetting the release certificate.

Another issue is reading the fingerprint from the wrong alias or wrong keystore file, especially after CI or signing-config changes.

Teams also often forget the distinction between upload certificate and app-signing certificate when Play App Signing is enabled.

Summary

• SHA-1 comes from the Android signing certificate, not from the app code.
• './gradlew signingReport is the quickest way to get fingerprints in Android-based projects.'
• 'keytool is useful when you want direct keystore verification.'
• Register the correct fingerprint for the correct package name and build type.
• Protect release keystores carefully, because signing identity is operationally critical.