SHA1 key hell regarding Gmail authentication and sign-in

5 min readNov 16, 2023

What the hell is “Sign-in failed 10”

I believe, in your first dates of android development you struggle with the tools and processes more than coding. Everything changes so fast that a resource written last year might not be valid any more. One another thing i notice that some unqualified instructors/blog-authors don’t mention the whole process. That is, you watch the video on udemy or youtube, you apply the exact process they narrate, but at the final deployment it occurs to o you that your app doesn't work as expected.

Here, i want to write about one of those things, SHA1 key, which is required if you want to make use of google services, like authentication and gmail sign-in, in your app. There is an abundance of questions about it, and everyone seems to be confused. Things get complicated if you want to utilize gmail sign-in. When debugging your app on a virtual/real device, everything looks fine, your app works well but when it comes to releasing your app to Google Play, those youtube/udemy resources become useless, as you start to get the error “sign-in failed 10". Because they don’t publish those apps to Google Play, they are only for education purpose.

You can see what i mean if you check following links:

And when it comes to official documentation(this and this), it is very comprehensive, but for a newbie like me it is almost impossible to deduct the necessary insight.

So luckily we have ChatGPT, and i asked it. Here is the question and its answer.

Q: when developing an android app, should i use the sha1 generated in android studio or the one in play console?

A: When it comes to using a SHA1 fingerprint for your Android app, the source depends on the context and purpose:

Development and Debugging:

For development purposes, especially when integrating APIs or services like Google Maps, Firebase, etc., you typically use the SHA1 key generated from the debug keystore in Android Studio. This key allows you to authenticate your app during the development phase.

2. Release and Publishing:

When you’re ready to publish your app on the Google Play Store, you’ll need to create a new release keystore and use the SHA1 key generated from that keystore.
The SHA1 key in the Google Play Console is related to the release keystore you use when signing your APK or app bundle for distribution in the Play Store. This key is important for authenticating your app with various Google services and APIs in the production environment.

To sum up, during development, you’ll use the debug keystore’s SHA1 key generated in Android Studio. When you’re preparing your app for release and upload it to the Play Store, you’ll need to generate a new release keystore and use the SHA1 key from that keystore for production purposes.

Remember, keeping the keystore secure and backed up is crucial, especially the one used for releasing your app to the public. Losing the keystore could result in the inability to update your app or verify your identity as the app’s developer.

Here comes my follow-up question:

Q: Can i add both keys to my firebase console? is there any drawback for this?

A: Yes, you can add multiple SHA-1 fingerprints to your Firebase project in the Firebase console. In fact, it’s a common practice to add both the debug and release SHA-1 fingerprints during development to ensure that your Firebase services work correctly in both environments.

There aren’t significant drawbacks to adding multiple SHA-1 fingerprints to Firebase. However, it’s essential to keep in mind a few points:

Clarity and Maintenance: Adding multiple fingerprints might be confusing if not properly labeled or managed. Ensure you label them appropriately (e.g., “Debug Key,” “Release Key”) for clarity.
Security: While it’s generally safe to add multiple fingerprints, always be cautious about managing access and permissions within Firebase. Ensure that only necessary people or services have access to your Firebase resources.
Testing: Test thoroughly to confirm that the Firebase services work as expected with both the debug and release keys. Sometimes, differences in configurations between debug and release environments might affect the functioning of certain services.

By adding both keys to Firebase during development, you ensure that your app can smoothly transition from the development phase (debug key) to the production phase (release key) without any service interruptions.

In case you may have wondered why running gradlew signinReport produces SHA1 for only debug variant but not release variant, I asked this to ChatGPT, too. Here is the answer:

When using gradlew signinReport, it typically generates the signing report for the debug variant because the debug signing configuration is readily available in the debug build type.

The release variant, on the other hand, uses a different signing configuration, often specified in the build.gradle or gradle.properties file, and may have a separate keystore and signing configuration. The release variant's signing information is usually more sensitive and kept private to ensure the security of your app. Therefore, the gradlew signinReport command might not automatically display the signing information for the release variant to prevent unintentional exposure of sensitive data.

To view the signing information for the release variant, you might need to check your build.gradle file or related configuration files to find the specific configuration details for the release signing, including the keystore location, passwords, and aliases. Then, you can use that information to generate the signing report for the release variant separately.

I wanted to make sure if the release one is the one on play console app signing page, and it clarified:

Yes, the release signing key used for the Play Store can often be managed directly through the Google Play Console’s App Signing page.

Google Play offers the option of using the App Signing by Google Play feature. When you opt in for this, Google manages your app signing key for you. You upload your app’s APK or Android App Bundle to Google Play, and Google manages the signing process using a key they control. This allows Google to optimize APK delivery to users and offers added security.

With this feature enabled, the signing key used for the app on users’ devices is different from the one you use to upload your app to the Play Console. The key used for signing your app in Android Studio or in your local development environment is your upload key, while the one used on the Play Store is managed by Google.

If you’ve enrolled in App Signing by Google Play, the key used for signing your app on the Play Store will not be the same as the one in your local release signing configuration. This is why when you use gradlew signinReport, it typically shows the debug signing configuration rather than the release signing configuration managed by Google Play.

I hope this information fits you well.

Thanks for reading

SHA1 key hell regarding Gmail authentication and sign-in

Written by Volkan Yurtseven