Play Games Services Sign-In Fails in Closed Testing: The SHA-1 Fix

The short answer: the certificate, not the SDK

Short answer: when Play Games Services sign-in fails for people on your closed test, the usual cause is a mismatch between the certificate the tester's copy of the game is signed with and the SHA-1 fingerprint stored on your Android OAuth client. Google's own setup guide handles this directly: “If your game is distributed from the Play Store, use the app signing by Google Play. Copy the SHA-1 fingerprint from the app signing page of the Play Console.”

The second cause sits one level up. Sign-in also fails for a Google account that is not on your Play Games Services tester list, even when that account is on your closed-testing list and has already installed the build. Those are different lists, in different parts of Play Console, and only one of them is the one you filled in when you invited 12 testers.

Both failures look the same from the tester's side: a sign-in dialog that closes, or an error with no useful text. Neither tells you which of the two is wrong, which is why teams spend a week changing SDK versions for a problem that lives in a fingerprint field.

Four settings have to agree before a tester can sign in. They live in three separate consoles, which is the whole difficulty:

1. Package name — the identifier in your manifest or Gradle config. It must match the Android application linked in Play Games Services character for character.
2. Signing certificate — the SHA-1 of the certificate on the copy the tester installed. For anything Play delivered, that is the app signing key certificate, not the upload key.
3. Tester membership — the Google account must be on the Play Games Services allowlist, either added individually or covered by an enabled release track.
4. Published game settings — the Play Games Services configuration must be published, not left sitting in Ready to Test.

Which SHA-1 the tester's copy actually carries

Play App Signing splits your signing identity in two. You sign the bundle you upload with an upload key that lives in a keystore you control. Google then strips that signature, re-signs the artifact with the app signing key, and serves that version to devices. A tester who installs from the Play opt-in link therefore runs a build signed by a certificate you have never held.

That is why keytool -list -keystore release.keystore gives you the wrong fingerprint for a Play-delivered test. The app signing certificate cannot be read off your own disk; you read it in Play Console under Setup → App integrity → App signing, on the App signing key certificate row. The Upload key certificate row directly above it is the one people copy by mistake, because it is the one that matches the keystore they have.

Google states the consequence in the same walkthrough: “Make sure to record the package name and signing certificate that you configured in this step. Using a different certificate or package name in your application will cause authentication failures.”

Threads on the Unity Play Games plugin tracker are full of developers who fixed sign-in by switching the OAuth client from the app signing SHA-1 to the upload key SHA-1. That does not contradict the rule; it tells you which copy of the game they were launching. If sign-in works with the upload-key client and fails with the app-signing client for the same account, the account is fine and the build being tested is one you signed yourself. Community reports are useful for recognising the symptom, but they are not the specification — the instruction above is.

Three lists, and only one is your closed-testing list

A closed test with 12 opted-in testers fills exactly one list. Play Games Services checks a different one, and the OAuth consent screen checks a third. All three have to contain the account that is trying to sign in.

• Closed-testing testers — Test and release → Testing → Closed testing → Testers. Controls who can install from the Play link.
• Play Games Services testers — Grow users → Play Games Services → Setup and management → Testers. The allowlist that authorises sign-in and endpoint calls.
• OAuth test users — Google Cloud → APIs & Services → OAuth consent screen. While the consent screen is in testing mode, only accounts added here can complete consent.

This is how a tester can install the game, open it, and be told sign-in failed: installation and authorisation are separate decisions made by separate systems, and the second one never looks at your closed-testing list. If the tester cannot find the app to install at all, that is a different failure — testers who cannot see the app on Play.

The publisher account is not exempt. Google's troubleshooting page is blunt about it: “The account that created the game in the Play Console does not automatically become a tester. If you wish to authenticate to the game with that account, you must add it as a tester explicitly.”

There are two ways to populate the Play Games list without maintaining a second email list. The first is the testers switch on that page, which — in Google's wording — lets you “automatically include any users who opted into testing for your app.” The second is to enable the release track itself: Grow users → Play Games Services → Setup and management → Testers → Release tracks → Add tracks, then select your closed track. Google: “You can grant access to test your game to all users who have access to test APKs on a given release track. This works the same as if you had added them to the tester list individually.”

The delay that makes a correct setup look broken

Two propagation windows stack on top of each other. The test link itself is not instant: “After publishing an open, closed, or internal test for the first time, the test link can take several hours to become available to testers.” The Play Games allowlist lags too: “The tester accounts you added should be able to access Play Games Services within a couple of hours.”

A tester who was added at the same moment the release went live is therefore a bad test of your configuration. Add the Play Games testers or enable the track a day before you publish, then diagnose. Expect hours rather than seconds after any change to the fingerprint or the allowlist as well; reports on the plugin tracker describe sign-in starting to work long after the edit, with nothing else changed.

The practical cost is diagnostic, not technical. If you treat the first hour as evidence of a misconfiguration, you change a second variable before the first one has taken effect, and now you have two unknowns.

The publish step people skip: game settings

Play Games Services has its own publish action, separate from publishing the app. The two can diverge, and Google says so in as many words: “it is possible to publish the application without publishing the games settings.” An app that is live on a closed track with game settings still marked Ready to Test authenticates testers against an unpublished configuration.

During a closed test the game itself is normally unpublished, which makes the allowlist the only thing standing between your testers and the endpoints: “If your game is in an unpublished state, grant access to your testers by adding their user accounts to the allowlist. Otherwise, your testers will encounter OAuth and 404 errors when attempting to access Play Games Services endpoints, such as the platform authentication endpoint.”

That sentence is worth reading twice, because a 404 from a Play Games endpoint during a closed test reads like a broken leaderboard or a bad game ID. It is usually an authorisation answer.

One condition attached to publishing is easy to miss. If the console refuses to publish the game, check that exactly one client ID has This app is preferred for new installations enabled — Google lists that as the cause when publishing fails.

The package name is the other half of the pair

The fingerprint is only checked against a package name, and both must match the Android application linked in Play Games Services. Change one without the other and you get the same authentication failure as a wrong SHA-1, with no message pointing at the package.

Treat the package name as final before the first upload, because Play does: “Once you upload an artifact, the package name for that app is fixed and cannot be changed.” In a game that already has a closed track running, a renamed package is not an edit — it is a second app record with its own listing, its own tester roster and a 14-day clock starting from zero.

The application ID that Play Games expects in the manifest is a separate value from the package name. Google describes it as “the digits (typically 12 or more) at the beginning of the client ID provided by the Play Console”, labelled Project ID on the configuration page. Copying the client ID itself into that field produces a game that launches normally and fails every Play Games call.

Testers who install your APK are not testing the same game

Any copy that does not arrive through the Play test link carries a different signature. Someone who installs the APK you sent over chat is running an upload-key-signed build with no Play-delivered identity, and Play Games will not authenticate it unless a client ID exists for that certificate. This is the common case when a team sidesteps the opt-in flow because the link was slow.

Emulators are the same trap in a different shape. An emulator image without Google Play services cannot complete Play Games sign-in at all, so it cannot validate this path — what emulators can and cannot stand in for during a closed test is worth reading before you build a test plan around one.

For a test that is measured in days, the risk is asymmetric: a sideloaded build can work perfectly for you and fail for every tester, and the only way to see the difference is to check which certificate the build was signed with. The Play opt-in link is the reference, not a convenience.

Why a sign-in failure is also a testing-requirement failure

For a personal developer account created after 13 November 2023, the closed test is not a recommendation: “At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days.”

Opt-in is the floor, not the whole check, and the free-text answers are what the reviewer reads (the questions on the production access form and what to write). The form asks about engagement during the test, and Google's guidance on being asked to keep testing names the same thing: “Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period.” A game whose first action is a sign-in wall that fails for part of the roster produces a technically compliant test and an application that is hard to defend.

Based on our analysis of 1,500+ closed-testing campaigns, games that stall rarely stall at installation. They stall on the first screen after launch, and the cause is usually an account or configuration decision made weeks earlier rather than a defect in the build. That is our campaign record, not a Google statistic, and we do not publish a pass rate from it.

The clock has its own rules once the roster is live, and a roster that looks full in your email list can read as empty in Play Console (why the opted-in count shows 0). An account that opts out cannot backdate the days it missed — “Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement” — and what a mid-test uninstall does to a tester's opt-in is a separate question from what it does to engagement. Both are covered in what counts as a closed tester.

A pre-test checklist for a game with Play Games Services

Run this before you start counting days, not after a tester reports a failure.

1. Confirm the package name is final. It cannot change once an artifact is uploaded.
2. Read the SHA-1 from Setup → App integrity → App signing key certificate — not from your keystore, and not from the upload key row.
3. Create or update the Android OAuth client in Google Cloud with that SHA-1 and the exact package name.
4. Add a second client for your debug keystore if you install builds yourself; same package name.
5. Add yourself and every tester to Play Games Services → Testers, or enable the closed track under Release tracks.
6. Publish the game settings with Publish Game — publishing the app does not do it.
7. Check that exactly one client ID is marked as preferred for new installations, or publishing may fail.
8. Publish the OAuth consent screen in Google Cloud before release, not after.
9. Wait a couple of hours, then have one tester sign in from a Play-installed copy before you rely on the 14 days.

Questions that come up while debugging this

Why does sign-in work on my phone but fail for every tester? You are almost certainly launching a build you signed. Testers install the Play-delivered copy, which carries the app signing certificate. Give yourself the same experience: install from the opt-in link.

Do closed testers get Play Games Services access automatically? Not by default. They are authorised for Play Games either when the Google account is added to the Play Games testers list or when the track they are on is enabled under Release tracks. Google's testers switch can also include anyone who opted into testing.

Which SHA-1 do I use if I do not use Play App Signing? The release keystore you sign with. keytool -list -keystore <path-to-keystore> -v prints it. Add the debug keystore's fingerprint as a second client so local builds authenticate too.

How long should I wait after adding testers? Google says the added accounts should have access “within a couple of hours”, and a first test link can take several hours. A failure at minute five is not evidence.

Can testers see achievements and leaderboards before release? Yes, once they are in the test group: “Once users opt in to your test group, they can sign in using Google Play Games Services, earn draft or published achievements, and post to draft or published leaderboards.”

What does a 404 from a Play Games endpoint mean during a closed test? Usually that the caller is not authorised — game settings unpublished or the account missing from the allowlist. It is rarely a wrong game ID.

Does uploading a fixed build reset the 14 days? The requirement is measured in continuous opt-in, and Google explicitly expects updates during the test: “Continue running closed tests while resolving user-reported issues and bugs.” Fixing sign-in mid-test is the intended workflow, not a restart.

Everything looks right and one tester still fails. Where do I look next? Their Google account on the device, not the one you have on the list. Play sign-in uses whichever account is active in the Play Store on that phone.

Where each rule in this article comes from

Everything above that describes Google's requirements is taken from these pages, read on 7 November 2026. Anything labelled as our observation is not from them.

• Set up Google Play Games Services — app signing SHA-1, two client IDs, tester allowlist, release-track access, propagation timing.
• Troubleshooting Play Games Services — publisher account as tester, unpublished game settings, preferred client ID.
• Set up an open, closed, or internal test — test link delay, PGS testers page and testers switch, package name fixed after upload.
• App testing requirements for new personal developer accounts — 12 testers, continuous 14 days, engagement, continued-testing reasons.