Google Sign-In Not Working for Google Play Testers?

Why does sign-in work for you but fail for every tester?

Verified 27 October 2026 against Use Play App Signing, Client authentication, Authenticate with Google on Android and the app testing requirements article. Claims labelled as developer reports come from issue trackers and forums, not from Google's documentation.

What Play App Signing changes about your build

Play App Signing applies to apps published as Android App Bundles, which is why this catches first-time publishers rather than a few unlucky setups. The client-auth guide calls it "a requirement when using Android App Bundle" (Client authentication). The guide for API providers spells out the trap in one line: "When using Play App Signing, the signature of the binary signed by the upload key certificate will be different than the binary distributed by Google Play." Your local release build and your testers' install are signed by two different keys, so any service that validates the signing certificate sees two different apps.

You are dealing with two keys, and Google's article lists them side by side:

• Upload key — held by you, stored in a Java keystore (.jks or .keystore), must be RSA 2048-bit or more. You use it to sign the bundle before uploading; Google uses it to verify your identity, and Google can reset it for you if it is lost or compromised.
• App signing key — held by Google Play, associated with a public certificate (.der or .pem), Google-generated keys are RSA 4096-bit. Google uses this key to sign the final APKs delivered to testers' and users' devices.
• Google's own note: "For maximum security, your upload key and app signing key should be different." They are expected to differ — which is exactly why the fingerprint mismatch exists.

Where each fingerprint lives

Two locations for what you have, one location for what Google holds (these are Google's labels on the two pages cited above; Play Console renames navigation now and then):

• App signing key fingerprints (what API providers need): Play Console, on your app's Play app signing page. Google documents the path as Protected with Play > Play Store protection > Manage Play app signing, under the App signing key section. The client-auth guide points to Release > Setup > App Integrity for the same SHA-1.
• Your upload key certificate: the same Play app signing page, under the Upload key certificate section.
• Your debug fingerprint: from the project with ./gradlew signingReport, or keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystore (the default debug password is android).
• Fingerprint of any binary: keytool -printcert -jarfile app.aab — useful for checking what you actually have in hand.

Where the app signing fingerprint has to be registered

Google names the services that check it: "those services authenticate your app using your app signing key's fingerprint", listing Google Maps, OAuth and Facebook Login as examples. In practice you register it in three places:

• Firebase console. Settings > General, select your Android app, add the SHA-1 under SHA certificate fingerprints, then download the updated google-services.json. Firebase is explicit that you must replace the old file: "Move this updated config file into your Android Studio project, replacing the now-outdated corresponding config file." (Firebase sign-in guide)
• Google Cloud console, OAuth clients. The Android-type OAuth client is validated against package name plus SHA-1. Google's client-auth guide notes that Google Play services "require you to provide the SHA-1 of your signing certificate so we can create an OAuth2 client and API key for your app".
• API key restrictions. An Android-restricted key pins package name and fingerprint together. Leave it pinned to the debug or upload fingerprint and Maps, Places or any other restricted API fails for testers even when sign-in itself works.

Keeping only the debug fingerprint registered is the most common version of this mistake: your sideloaded build passes every check, and no test you run on your own phone can tell you otherwise. Registering the app signing fingerprint does not remove the debug one — Firebase and Cloud both accept several fingerprints per app, and you want both.

Why this surfaces during closed testing

Closed testing is the first time anyone other than you installs the Play-signed build. Testers arrive through your opt-in link, Google Play delivers the bundle it re-signed, and the fingerprint your API provider knows is the one from your laptop. Sign-in fails for them, onboarding stops there, and nothing in Play Console tells you why.

Google treats the consequences as your problem to prevent. On the production access form it asks about tester engagement, and it names the failure conditions for continued testing: "having fewer than 12 opted-in testers or insufficient tester engagement during the testing period" (testing requirements article). Testers who cannot get past the login screen are not using your app.

Based on our analysis of 1,500+ closed-testing campaigns, this failure shows up as quiet disengagement rather than as an error report: installs happen, sessions do not, and the engagement question on the application form becomes hard to answer honestly.

There is a second audience with the same problem. Google requires working credentials for its own reviewers: "If your app requires user authentication, provide valid, working login credentials in Play Console so reviewers can fully test your app's features." If sign-in is broken by a fingerprint mismatch, the credentials in app access / test credentials do not work either, which is why the fix belongs before day one rather than after. For what engagement Google expects while the test runs, see do testers need to open the app every day.

How to fix it, in the order that works

Do this end to end; doing half of it leaves the mismatch in place:

1. Copy the app signing key fingerprints from Play Console — SHA-1 for Firebase and Android OAuth clients, SHA-256 where a service asks for it. Not the value from signingReport.
2. Add the fingerprint to your Firebase Android app and to the Android OAuth client in Google Cloud, keeping your existing debug fingerprint alongside it.
3. Download the fresh google-services.json and replace the copy in your project. Without this step the app still carries the old OAuth client information.
4. Rebuild the release bundle and upload it to the closed track, incrementing the version code.
5. Install from the opt-in link on a second device — that install is signed the way your testers' installs are. A sideload of your local .aab cannot prove the fix.
6. Then confirm reviewers can log in with the account listed in Play Console (test credentials), and only then invite the twelve people you are counting on.

How long the fix takes

Google's three pages on this subject — Play App Signing, client authentication and the Firebase sign-in guide — tell you exactly which fingerprint to register and where to paste it, but none of them states how long a newly added fingerprint takes to propagate. Treat that timing as unpublished rather than assuming a number: rebuild with the new config and test again, and if it still fails, the remaining causes are configuration, not waiting.

The checks that settle it, in order: package name on the OAuth client matches applicationId in your build; the SHA-1 on that client is the app signing one read from Play Console; the downloaded google-services.json in the project is the version Google issued after you added the fingerprint; and the device you test on installed the build from the Play-delivered test link.

Failures that look the same but are not

• Login works, everything else fails. Maps or Places blank while sign-in succeeds points at an API key still restricted to the debug fingerprint, not at the OAuth client.
• Reviewers cannot sign in at all. No working account was ever supplied — that is an app access problem, covered in app access: test credentials for reviewers.
• Testers cannot even install. Different failure entirely: opt-in, verification or device issues — see 0 testers currently opted in and Android developer verification and closed testing.
• Only some testers are affected. Compare what each person actually installed. A tester who joined your internal test earlier is not in the closed test at all — Google states that a user who opts into an internal test "is no longer eligible to receive an open or closed test" until they opt out — while a tester still sitting on an older release needs the new build to finish processing on the track before it reaches them.

What leaving this until day seven costs

An engagement problem discovered on day twelve has no cheap fix. The fix itself takes an hour, but the testers who already hit the login wall do not come back, and the days that ran while nobody could use the app leave you nothing to point at when the application asks what your testers did. "Insufficient tester engagement during the testing period" is one of the two reasons Google gives for sending you back to testing — the engagement questions are answered in production access form questions.

Our recommendation: install your own build from the opt-in link on a device that has never seen the app, sign in there, and do it before you invite the first tester. Two minutes on a clean device catches the mismatch while it is still free to fix. If your app was generated with an AI builder, watch the signing step specifically — Rork, for example, warns users "Do not ask the Rork agent to add its own signing keys, keystores, or SHA1 fingerprints" (Rork to Google Play), because a key the tool invents is one more certificate to reconcile with the one Google holds.

Also check whether your package name is registered under Android developer verification — that program also works with signing keys, and an unregistered package blocks installation outright (developer verification and closed testing).

FAQ: signing fingerprints during closed testing

Is the SHA-1 from `signingReport` the one Firebase wants? Only if you are not using Play App Signing. If your app is published as a bundle, Firebase and Google Cloud want the app signing key fingerprint read from Play Console, because that is the key on the build your testers install.

Which fingerprint does Google Sign-In check? Google's Play App Signing article says services including Google Maps, OAuth and Facebook Login "authenticate your app using your app signing key's fingerprint", so the Google-held app signing key is the one to register.

Should I keep the debug fingerprint registered? Yes. Register the app signing fingerprint in addition to it. Local development still signs with the debug key, and both Firebase and Google Cloud hold several fingerprints per Android app.

Developers report a status code 10 / DEVELOPER_ERROR when this is wrong. Is that from Google? No. That code appears in Google's public issue tracker and library issue threads as the common symptom of a fingerprint or package-name mismatch, but Google's Play App Signing and client-auth pages do not define it. Treat it as a strong hint from other developers, not as a documented error reference.

Do I have to change my upload key? No. The upload key signs what you upload; it is not what validates your app for API providers. Google also offers an upload key reset if that key is lost, which is a separate problem from a fingerprint mismatch.

Will this block the production access application itself? Not directly — the form asks about tester engagement, and testers who cannot sign in are not engaged. Fix it early enough that your 14 days contain real use; see production access rejected for what happens when they do not.