Google sign-in worked everywhere except Play installs.

In June, Google sign-in in our Android app started failing for one group of people: anyone who had installed it from the Play Store. Debug builds worked. Beta builds sent through Firebase App Distribution worked. The exact same code, downloaded from Play, showed “Google sign-in failed” and nothing else. The cause wasn’t in our code at all. It was a signing key we had never held, and once we understood it, a line in our own setup notes turned out to be wrong too.

The app on your users’ phones isn’t the one you signed

Since August 2021, new apps on Google Play have had to ship as Android App Bundles, and app bundles go through Play App Signing. That means two keys are involved, and they do different jobs.

The upload key is the one in your keystore file. You sign the bundle with it, and it only proves to Google that the upload came from you. The app signing key lives on Google’s side. Play checks your upload signature, generates the APKs for each device, and signs those with the app signing key. That second signature is the one Android sees when someone installs your app from the store.

So you end up with two certificates and two sets of fingerprints. Every build you make yourself, whether that’s a debug run, a sideloaded release, or a Firebase beta, carries your upload (or debug) certificate. Every Play install carries Google’s. Most of the time nothing cares which one it is. A handful of services do.

Everything that checks a fingerprint

Google’s documentation is direct about this: services such as Google Maps, OAuth and Facebook Login “authenticate your app using your app signing key’s fingerprint.” If you registered only the fingerprint from your own keystore, those services will accept your test builds and reject your real users. The common cases are:

• Google Sign-In through Firebase. Firebase creates an Android OAuth client for each SHA-1 you add to the app. No client for the Play key means native sign-in has no match on Play installs.
• API keys restricted to your Android app, such as Maps, which check the package name and the SHA-1 together.
• Facebook Login, which wants the key hash of whatever certificate signed the installed app.
• Android App Links. The assetlinks.json file on your website lists the SHA-256 fingerprints allowed to open your links. With only the upload fingerprint listed, Play installs send those links to the browser.

That was our bug exactly. The Firebase project had two SHA-1 fingerprints registered, debug and upload, and not the app signing one. The only sign of trouble anywhere was a generic error string, because our sign-in screen caught every exception and showed the same message. (We’ve written before about why that habit costs you hours.)

The fix takes minutes and no rebuild

In Play Console, open your app’s Play app signing page. It has moved between menus over the years and currently sits under Protected with Play, so searching the console for “app signing” is quickest. The page shows both certificates, with SHA-1 and SHA-256 fingerprints for each. Copy the ones listed under App signing key, not Upload key.

Then add them next to the fingerprints you already have. Don’t replace anything. Your own builds still need the upload and debug fingerprints, and every one of these services accepts a list. For us, adding the Play SHA-1 to the Firebase app created a new OAuth client on the spot. Sign-in started working on Play installs within minutes, with no new build and no store update, because the check runs on Google’s servers and not in the APK.

The upside: a lost upload key isn’t the end

The same split that caused our bug also takes away most of the risk of losing a key. Our project notes said that losing the upload keystore would “permanently lock” our Play listing. That was true of Android before Play App Signing. It isn’t true for an app enrolled in it, and Google’s help page says so plainly: “If you lose your upload key or suspect that it was compromised, you are not locked out of your app.”

The recovery goes like this. Generate a new upload key, export its certificate as a PEM file with keytool, and on the Play app signing page choose Request upload key reset, giving a reason and attaching the PEM. You need admin access to the developer account. Google doesn’t publish how long the reset takes. Third-party guides report anything from 48 hours to several days, so plan for days and don’t start the process the night before a release. Your users notice nothing, because the key their installed app is checked against never changed.

The real danger is with older apps. If an app was published before August 2021 and its developer kept managing their own signing key, Google can’t help, and the help page says that key “cannot be reset if you manage it yourself… and lose it.” Without it you can’t publish an update that installs over the existing app. The only way out is a new package name, which means a new listing with no reviews, no ratings and no install history. If you own an app like that, enrolling it in Play App Signing while you still have the key is the most valuable ten minutes you’ll spend this month.

Apple splits the risk differently

On iOS the certificates are the easy part to replace. Apple’s certificate support page says that if your membership is valid, revoking or letting a distribution certificate expire doesn’t affect apps already on the App Store. You make a new certificate and sign the next build with it. Two catches: builds already uploaded but not yet submitted for review “may be marked as Invalid Binary” if their certificate was revoked, and each team gets only one distribution certificate of each type, which only the Account Holder or an Admin can create. If you build with Xcode Cloud, as we do for iOS, Apple manages that signing for you.

The files that hurt to lose on Apple’s side are the .p8 private keys: App Store Connect API keys, push notification keys and Sign in with Apple keys. You can download each one exactly once. Losing one doesn’t lock you out of anything. You revoke it, make a new one and reconfigure every server and service that used the old one. That job is easy to underestimate when the key is wired into three different backends.

The short list

• Register the app signing fingerprints from Play Console with every service that checks one: Firebase, restricted API keys, Facebook, assetlinks.json. Keep the upload and debug ones as well.
• Test your first Play internal-testing build installed from Play, not sideloaded.
• Back up the upload keystore and its passwords somewhere that isn’t your laptop. Losing it costs a few days, not the app, but there’s no reason to spend those days.
• If you have an older app that isn’t enrolled in Play App Signing, enroll it now.
• Store every Apple .p8 the moment you download it, with its Key ID next to it.

Signing isn’t the only thing Play changes between your build and the user’s phone. Version codes have their own rules, and we tripped over those two months later.