I have two development machines, a laptop and a PC. This is great! I can code at my desk or on the fly. I can sync the builds with git and be sure that the project is the same on the cloud.
But there are problems with this. Strange exceptions such as SIGN_IN_REQUIRED occur when signing in or accessing Google services. A good hint that this has happened is:
- when the exceptions returned from Google service tasks are totally non-descriptive.
- when the android app works when built on one computer, but not on any other
- when the android app works when built in either Debug or Release mode, but not with the other one
- you’ve searched all of StackExchange and there is no consensus, and it appears like nobody else is experiencing this problem
Such problems cost me many hours to debug. And annoyingly, the reason was not my code. The problem occurs when different PCs use their own generated SHA-1 hash keys to sign the apps when building.
This leads to Apps with exactly the same logic, but different fingerprints. And it’s the SHA-1 fingerprints which are used to authenticate Google services.
Linking Multiple SHA-1 Fingerprints
One way to get around the multiple build fingerprints problem is to register the SHA-1 debug and release fingerprint for every PC in your projects.
One to look out for is Google Play Games Services.
Google Play Games Services require a different linked project for every SHA-1 signing key. That means, one for a release fingerprint, one for a debug fingerprint on PC #1, PC #2, etc. Each of these duplicate projects under the game console can relate to the app’s same package name, but you must manually go into the cloud console API page and ensure the new OAuth2 Client ID is linked to the SHA-1 fingerprint you want to link.
This warning is mentioned on this page Setting Up Google Play Games Services as of July 2018.
You can add more than one Android app to the same game entry in Google Play Console. However, this should only be done if there are different versions of the same game (for example, the free version and the paid version). In this case, always list the paid version before the free version (or the full version before the demo/trial version). Do not link different games to the same project as this may cause incorrect behavior. Instead, create a separate game entry in the Google Play Console for each game that you publish.
This is required at least for the Debug and Release keys. But doing this once for every development PC is going to be a pain. Completely unscalable.
The solution I’ve used is to simply reuse one debug and release key.
Reusing SHA-1 Keys
The debug keystore (locally) lives in the user directory ~/.android/debug.keystore or similarly for Windows machines. And your Release key should already have been created when creating the project in Google Play’s console. These keys can then be (securely!) shared with your development machines and then used in Android Studio like so:
Updating android/build.gradle
android { signingConfigs { debug { storeFile file('/home/nelson/.android/debug.keystore') } }
buildTypes{ ... debug { signingConfig signingConfigs.debug } }
Or through the User Interface
This way, the same SHA-1 fingerprint is used for signing on all development machines, and for each new project, only two fingerprints, the Debug and the Release SHA-1s need to be recognized in the google API configurations.
This might sound confusing. That’s because IT BLOODY WELL IS.
Google does not make it easy to use their products especially when taking several of them, e.g. Firebase with Google Play Sign-On and Games services. It’s a nightmare having to juggle so many keys, OAuth2 IDs and Client Secrets.
It’s easily the most frustrating thing about using Google’s APIs.
But once it’s all set up, and you get your head around it, you can write a blog post about it and forget it. Then refer to it next time, because it really is just all too much back-and-forth.
Good luck!