Build 1 publisher2 min readPublished September 12, 2026 at 2:49 AM PDT

Opting into quantum-ready Play signing invalidates the SHA-1 in your Android OAuth client

A developer's Play-delivered build returned nothing at all from Sign in with Google, because the fingerprint buttons on Play Console's app signing page no longer describe the certificate that signs the app.

The Engineer · Build desk

Illustration accompanying Opting into quantum-ready Play signing invalidates the SHA-1 in your Android OAuth client

What happened

A developer reported that Sign in with Google worked on development and preview builds, while the Play-delivered build showed no account picker, no error message and no crash when the button was tapped.
Credential Manager returns a result meaning cancelled whenever a sign-in cannot complete, which is the same result a user swiping the dialog away produces.
Registering that fingerprint fixed the sign-in within minutes and required no rebuild or new release.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

constraint Debug and preview channels cannot clear this class of bug, because they run the upload signature while Play delivers its own; the only build that exercises the real certificate is the one on a tester's phone.
exposure Any team that enrolled in the beta and configured its OAuth client from the console buttons has a sign-in path that fails for every Play Store user while internal installs keep passing review.
cost Debugging it takes days, and the person on call after a release is the one who spends them, since the API returns nothing to look up and the first plausible theory can be ruled out incorrectly.
decision Verification has to move from comparing console fields to reading the certificate off the installed artifact.

The reason this appears only in production is in the contract Credential Manager exposes to the app. When a sign-in cannot complete, it returns a result that means cancelled ^[6]. In the library the author was using, the catch blocks map `GetCredentialCancellationException` to a cancelled response and `NoCredentialException` to a no-saved-credential response ^[7]. Before that point Google asks two questions: is the package name registered, and does the app's certificate match the fingerprint on file ^[9]. A no to either is a refusal, and the refusal arrives as cancelled ^[9].

The post lists four conditions that land in that one bucket: a user swiping the dialog away, an app that is not registered properly, a certificate that does not match, and a consent screen still in Testing with this person absent from the tester list ^[8]. Three of the four are configuration faults on the developer's side ^[15].

Play App Signing is the part most Android teams already know. You sign with your upload key, and Play strips that signature and applies its own before delivering the app to users ^[10]. The installed app therefore carries a different fingerprint than the file you uploaded, so both the upload key and Play's signing key have to be registered with Google; register only the upload key and every Play Store install fails while local installs keep working ^[11].

The beta changes which certificate is authoritative. According to the dev.to post, if the app uses Play App Signing and the developer has opted into quantum-ready app signing (beta), the SHA-1 fingerprint buttons on Play Console's app signing page are not the certificate that signs the app ^[3]. The one to fingerprint is `deployment_cert.der`, one of three files behind Download certificates under Manage Play app signing, reached through Protect with Play and Play Store protection ^[4]. The post identifies that file without describing what the beta changes about the signing pipeline ^[17].

The author went to the OAuth client first. The Android client had the right package name, a SHA-1 copied straight from Play Console's app signing page, a consent screen published to production, and no unusual permissions requested ^[12]. On that evidence the fingerprint theory looked dead, and another day went into the test user's Google account instead ^[13]. "The console tells you what you configured. The phone tells you what's true," the author wrote ^[14].

Registering the deployment certificate's SHA-1 in the Android OAuth client fixed it with no rebuild, and sign-in started working within minutes ^[5]. Read the certificate off the app that is actually installed ^[18]. Finding that took several days ^[2].

What to watch

Whether Google labels the app signing page's SHA-1 buttons as non-authoritative for apps enrolled in the quantum-ready beta, or changes what those buttons return.
Whether the deployment certificate in the beta stays stable, since any rotation re-breaks every fingerprint already registered in an OAuth client.
Whether Credential Manager ever separates certificate rejection from user dismissal in the result it returns to the app.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[2]
The author wrote that it took several days to find the cause, which turned out to be a fingerprint Play Console does not show anymore.
ReportedSupported2 sources— sign in to open View cited source
[3]
The post states that if an app uses Play App Signing and the developer has opted into Quantum-ready app signing (beta), the SHA-1 fingerprint buttons on Play Console's App signing page are not the certificate that signs the app.
ReportedSupportedSource: dev.to post2 sources— sign in to open View cited source
[1]
A developer wrote on dev.to that Google Sign-In worked on the development build and the preview build, but on the version Google Play delivered to real testers, tapping "Sign in with Google" produced "no account picker, no error message, no crash. Just a button that did nothing."
ReportedSupportedSource: dev.to postView cited source
[4]
The remedy given: go to Play Console, Protect with Play, Play Store protection, Manage Play app signing, click Download certificates rather than the SHA-1 fingerprint buttons, take the resulting three files, use deployment_cert.der, compute its SHA-1 fingerprint, and put that fingerprint in the Android OAuth client in Google Cloud Console.
ReportedSupportedView cited source
[5]
The post states no rebuild was needed and that sign-in started working within minutes of registering the correct fingerprint.
ReportedSupportedView cited source
[6]
On modern Android, Sign in with Google runs through a system component called Credential Manager, and when it cannot complete a sign-in it hands the app back a result that means cancelled.
ReportedSupportedView cited source
[7]
The library code shown in the post catches GetCredentialCancellationException and returns OneTapResponse.cancelled(), and catches NoCredentialException and returns OneTapResponse.noSavedCredential().
ReportedSupportedView cited source
[8]
The post says Android uses one bucket for four cases: the user genuinely dismissed the dialog; the app is not registered properly with Google; the app's security certificate does not match what Google expects; the OAuth consent screen is still in Testing mode and this person is not on the tester list. There is no error code and no message.
ReportedSupportedView cited source
[9]
The post says Google checks whether the app's package name is registered and whether the app's signature matches the fingerprint on file, and that if either answer is no, Google refuses and the refusal comes back on Android as cancelled.
ReportedSupportedView cited source
[10]
Under Play App Signing, the developer signs the upload with an upload key, and Play then removes that signature and applies its own before sending the app to users; the feature exists so that losing your own key does not lock you out of updating the app.
ReportedSupportedView cited source
[11]
Because Play re-signs the app, the app on a user's phone has a different fingerprint than the uploaded file, so both the upload key fingerprint and Play's app signing key fingerprint must be registered with Google; registering only the upload key makes every Play Store install fail while every local install works.
ReportedSupportedView cited source
[12]
The author first checked Google Cloud Console: the Android OAuth client had the right package name, a SHA-1 fingerprint copied straight from Play Console's app signing page, a consent screen published to production, and no unusual permissions requested.
ReportedSupportedView cited source
[13]
The author concluded the fingerprint theory was dead and started investigating the user's Google account on the device, which cost another day.
ReportedSupportedView cited source
[14]
"The console tells you what you configured. The phone tells you what's true," the author wrote, describing the mistake as comparing a field in one console against a field in another console and trusting both, when neither described the app sitting on the phone.
ReportedSupportedView cited source
[17]
The post names deployment_cert.der as the certificate to fingerprint and does not describe what the quantum-ready app signing beta changes about the signing pipeline.
ReportedSupportedView cited source
[18]
The post says Google checks the certificate of the app that is actually installed, so that is the thing to measure.
ReportedSupportedView cited source
[15]
Of the four conditions the post says Android reports as cancelled, three are developer-side configuration faults (registration, certificate mismatch, consent screen in Testing mode) and one is a genuine user dismissal.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 12, 2026
Google Sign-In Works in Debug but Fails in Production on Android? Check This Hidden SHA-1

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Our only source is the developer's own write-up on dev.to, and it is written for whoever is stuck: Play Console, Protect with Play, Play Store protection, Manage Play app signing, then Download certificates instead of the SHA-1 buttons, then fingerprint deployment_cert.der and paste that into the Android OAuth client. The author reports sign-in working within minutes, with no rebuild. The part worth keeping even if your own bug turns out to be something else is what the beta did to the page: where Play Console used to show MD5, SHA-1 and SHA-256 rows for the app signing certificate, it now shows a Classical key button and a post-quantum key button, and the deployment certificate that signs the shipped app has no button. The author copied the only SHA-1 on offer, and wrote: "It was never going to work."

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence45

0100

One first-hand account, closed by a working fix

Everything in this story comes from a single dev.to post: the symptom, the third fingerprint the author read off a test phone, and the repair. As debugging write-ups go it is checkable. It names the file, deployment_cert.der, gives the exact console path, and reports sign-in working within minutes of registering that fingerprint with no rebuild. Against that, one developer's Play Console is the entire sample, and Google's own documentation for the beta appears nowhere in the reporting.

Adoption12

0100

One app inside an opt-in beta

The only usage in the record is the author's own app: Play App Signing with the quantum-ready beta switched on, shipping to testers through Play. Nobody in this reporting knows how many developers have opted into that beta, and no other affected app is named.

Hype gap

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
Geofencing beats GPS polling on power, then loses to the OEM battery optimiser
1 publisher
build
Sideloading becomes a registered activity: budgeting for Android's September 2026 deadline
1 publisher
security
Ghost casino apps exploit Google Play's ratings-free Early Access channel
2 publishers
build
A 5x publishing increase cost one site 1,000 indexed pages and every impression
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources