Google Sign-In DEVELOPER_ERROR on Android release builds.

What you see

Google Sign-In works perfectly when you run the app from your machine. Then you build a release APK, or install the build from a Play track, and sign-in fails with DEVELOPER_ERROR.

Nothing in your code changed between the two builds. That is the clue.

Why it happens

Google checks which key signed the app before it allows sign-in. It compares the app's SHA-1 fingerprint with the fingerprints registered for your Android app in Firebase.

Usually only the debug keystore's SHA-1 was registered, because that is what you used while setting up. The release keystore has a different fingerprint. If you use Play App Signing, Play re-signs the app with yet another key, so the build users install has a third fingerprint.

Google sees a fingerprint it does not know and refuses with DEVELOPER_ERROR.

It helps to know which key signs which build:

• Debug keystore. Signs the builds you run from your own machine. This is the one that works.
• Release or upload keystore. Signs the APK or bundle you build for release and upload to Play.
• Play App Signing key. Play re-signs your upload with this key. It signs the copy users actually install.

Each one has its own SHA-1. Google needs to know about every one that will run your app.

The fix, step by step

Step 1. Get your release fingerprint. Run keytool against the keystore you sign releases with:

keytool -list -v -keystore release.keystore -alias YOUR_ALIAS

Copy the SHA-1 line.

Step 2. Get your debug fingerprint too, if it is not registered. The default debug keystore uses a well known password:

keytool -list -v -keystore ~/.android/debug.keystore \
  -alias androiddebugkey -storepass android

Step 3. Get the Play App Signing fingerprint. In Play Console, open your app, then App integrity. Copy the SHA-1 of the app signing key. This is the key that signs what users actually install from Play.

Step 4. Add all of them in Firebase. Go to Project settings, choose the Android app, and add each SHA-1 as a fingerprint. Debug, release and Play signing.

Step 5. Try again without rebuilding. This is a server side check. You do not need a new build. Sign-in starts working within minutes on the build you already have installed.

Step 6. Refresh your config for future builds. Re-download google-services.json and replace the copy in your project, so the next build carries the updated client list.

Step 7. Check the client id in your code. Keep the Web client id as webClientId in your sign-in config. Using the Android or iOS client id there is a separate way to break sign-in.

Step 8. Test the build users get. Install from a Play test track, not a sideloaded APK. That copy is signed with the Play key, so it is the real test of the fingerprint you just added.

How to prevent it

• Register debug, upload and Play signing fingerprints when you first set up Google login. Not after the first release fails.
• Before the first upload, compare the keytool -list -v SHA-256 with the upload certificate you expect, so you know which key you are really using.
• Keep a separate upload keystore per app and back it up off the build machine. Losing it means the app can never be updated.

Related traps

• Silently unsigned bundle. A fresh Capacitor Android project has no release signing config. bundleRelease can go green and produce an unsigned bundle that Play rejects with a message that never mentions signing.
• OAuth never returns to the app. If you use a browser based flow, AndroidManifest.xml needs an intent filter for your redirect scheme.
• disallowed_useragent. Google refuses web sign-in inside an embedded webview. Use the native SDK or the system browser.

Keep reading.