Fix Google Sign-In Error 10 in Closed Testing

The scope here is one failure: native Google sign-in that breaks in the copy Google Play delivers. It separates that from other errors that look similar, then covers frameworks, other sign-in providers and what testers should report. Every Google page cited here was checked on October 16, 2026, and community reports are labelled as such. The sources are listed at the end.

Fix Google Sign-In in the Play build

Match the app your testers installed to the package name and signing SHA-1 registered for it. Work through these steps in order; the Firebase and Google Cloud routes follow.

Add the Play certificate in Firebase

Select the matching Android app before you add its Play signing fingerprint. The steps follow Firebase's fingerprint help and its Google sign-in guide.

1. In the Firebase console, open the project your app uses, then Project settings > General.
2. Under Your apps, select the Android app whose package name matches the failing build.
3. Click Add fingerprint, paste the Play app signing SHA-1 and save. Add it next to the existing fingerprints rather than replacing them.
4. Under Authentication > Sign-in method, confirm that Google is enabled.
5. If Firebase prompts you to download an updated google-services.json, replace the file in your project. Firebase says the file “contains the OAuth client information required for Google sign-in,” so a changed file means a new build. Check that its project and package match the failing app.

Add a SHA-256 only where a specific Firebase service asks for one. Phone authentication, for example, uses SHA-256 for its Play Integrity path; Google Sign-In itself relies on the SHA-1.

Configure Google Cloud without Firebase

Two OAuth clients do two different jobs. The Android client registers your app; the Web client ID is the one your token request uses.

1. Select the project that issued your client IDs, then open Google Auth platform > Clients (Google Cloud help).
2. Look for an existing Android client with this package name and SHA-1 before you create another.
3. If it is missing, choose Create Client, set Application type to Android, enter a name, the package name and the Play app signing SHA-1, then Create. The Android form has a SHA-1 field; a SHA-256 does not go there.
4. Register each package and certificate pair you need, for example debug, local release and Play.
5. Leave the Web client in place for the token request, and never put a client secret inside the app.

Prove the repair

One successful sign-in does not prove the release is fixed. This checklist is our recommended acceptance test, not a Google rule; the last row matters because one developer's login passed once and still failed on the next sign-in, a session problem that a single check would miss.

Why does sign-in work in debug but fail in closed testing?

The app installed through Google Play can have a different signer from the APK you install locally. Google's client authentication guide notes that “Android Studio automatically signs your app with a debug certificate.” A release you build yourself uses whatever key that variant is configured with. With Play App Signing, your upload key signs the bundle you upload, and Google signs the APKs your testers receive with the app signing key.

Those keys have different roles, but they are not always different values: you can supply your own signing key, and some setups use one key for two roles. Compare the actual fingerprints rather than the key labels.

Read the fingerprints yourself

For builds on your machine, the Gradle signing report prints the SHA-1 and SHA-256 of every variant, and keytool reads the debug keystore directly (enter the keystore password when asked):

./gradlew signingReport

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

A local signing report does not tell you what signed the Play copy. To check the failing build itself, install it from the closed test on a device, pull it with adb and print its certificates with apksigner, which Google documents as showing “information about the APK's signing certificates.” Replace the package name and use the path the first command prints:

adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apk

I added the SHA-1 and it still fails

Compare the failing APK's certificate, its final application ID and the client IDs before changing more settings. Work down this ladder; each row rules out one layer.

Row 4 is not theoretical. In an Expo case reported in September 2026, adding fingerprints changed nothing; the fix was a typo in the client ID the backend accepted.

Multiple signing certificates or upgraded keys

A single app may need more than one signing identity registered. Google's current Play App Signing help describes hybrid signing with three app signing keys and asks you to register the fingerprints of each, and an app that upgraded its signing key can still have installs signed by an older one. Register the identities your installs actually carry and do not delete older entries that still work. Key rotation is out of scope here, and it is not a sign-in fix.

Another project already owns this package and SHA-1

Firebase's conflict help says a package name and SHA-1 pair “must be unique across all Firebase and Google Cloud projects.” If the console refuses your fingerprint because another project holds it, find which project owns that OAuth client before you delete anything. Google support can help locate the conflict; do not remove active clients or projects to guess your way through it.

Is error 10 the same as 12500, 12501 or canceled?

No. Read the exact error and the library that produced it before treating every failed sign-in as one problem. Google's common status codes reference defines DEVELOPER_ERROR = 10 as “The application is misconfigured.” The other codes below come from Google's historical play-services-auth 21.6.0 SDK.

Legacy Google Sign-In and Credential Manager

Google's Play services release notes list the deprecation of the Google Sign-In APIs in play-services-base on April 16, 2024, and Google announced the move to Credential Manager on September 11, 2024. The APIs were then removed from play-services-auth 22.0.0 on August 26, 2026 and from play-services-base 18.11.0 on September 17, 2026, with the note “Removed the APIs related to Google Sign-in.” That is an SDK change; it does not establish a shutdown date for apps already installed. New code and upgrades should follow Google's migration guide.

The two APIs fail differently. Credential Manager has no error 10; its troubleshooting guide warns that “A high volume of "cancellations" may actually indicate a misconfiguration.” So a cancellation can be a configuration fault or a real cancellation, and NoCredentialException is a different signal again.

Flutter, React Native, Expo and Unity checks

The native identity checks above apply to every framework, but setup, initialization and build configuration differ. Use the route for your framework and the library version your app actually resolves.

For React Native, the library maintainers provide a configuration check you can run from the project root:

npx @react-native-google-signin/config-doctor

What changes for Supabase, Facebook, Apple or Auth0?

The provider and the sign-in flow decide which certificate, client ID or callback has to match. A Google SHA-1 is the answer for native Google sign-in; for other providers it may be the wrong hash, the wrong format or irrelevant.

What should testers send the developer?

A useful report identifies the failing Play build and the exact point where sign-in stops. A tester cannot repair an OAuth registration by retrying, so the job is evidence, not persistence. Copy this template and send it to your testers:

App and Play testing link:
Installed app version or build:
Installed from: Play closed test / another route
Device and Android version:
Date, time and time zone:
Exact error text or a redacted screenshot:
Where it stopped: before the account picker / after choosing an account / after returning to the app
Could another sign-in method open the app?
Retest result and version:

Ask testers to stay opted in to the test while you fix it. Never ask for passwords, OAuth tokens, private keys or Play Console access. After your change, ask the same tester to open a feature that needs sign-in, then sign out and sign in again, and to record the version and the result.

Does error 10 affect my closed test or production access?

A sign-in configuration error is separate from enrollment. Error 10 is not a Play policy rejection code, and no Google rule we found says it resets your testers' opt-in period. Google's testing requirements page encourages you to improve the app during closed testing, so keep testers opted in and ship the fix to the same closed track. That is a reading of the published rules, not a promise covering every case.

Broken sign-in still matters. Google Play's functionality policy says “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally,” and a login wall stops testers from reaching the features they are meant to test. Fix it before you apply for production access, and give reviewers working sign-in details. If a review has already come back, see the Broken Functionality rejection.

For context: personal developer accounts created after November 13, 2023 need at least 12 testers continuously opted in for 14 days before they apply for production access for that app. After you apply, Google says “Review usually takes seven days or less, but can occasionally take longer.” If testers are missing from the count, check how they were invited before you touch sign-in.

Frequently Asked Questions

The Bottom Line

Play Console and Firebase menu labels are the fastest changing facts on this page. If a route above no longer matches your console, look for Play app signing under Protected with Play, and for fingerprints under your Android app in Firebase Project settings.