Google Play's zero-tap sign-in rule: what Firebase apps need by April 2027

From April 2027, Google Play requires Android apps that sign users in to sign them back in, without asking, when they restore the app onto a new phone. Firebase Authentication has no built-in way to do this. Every fact below was checked on its linked source page on 10 October 2026.

If you want the setup kit now, Play Restore Keys checks your setup for free (10 checks a day, no account). It does not test your app.

What the rule says

  • Google's technical quality requirements say that from April 2027, apps that support sign-in, optional or mandatory, must support zero-tap sign-in restoration. It applies when a user moves to a new phone or tablet and restores data from a cloud backup or another device.
  • Google checks one thing: "successful restore key retrieval". A restore key is what Google calls a Restore Credential.
  • Google's page names no fixed penalty. It says that missing a requirement "can affect an app's visibility and publishing capabilities on Google Play" and that apps found not meeting it will be notified.
  • Google gives no exact day in April 2027.

Who is out of scope

  • Apps without user accounts, and users who are signed out or in guest mode.
  • Games, for now. Google says guidance for games comes in 2027.
  • Permanently private apps and enterprise device-management apps.
  • Apps whose sign-in is bound by strict regulatory rules, if they ask for an exemption in Play Console before the enforcement date.
  • Watches, TVs and cars: the rule covers phones and tablets only.

Block Store no longer counts

Apps that had Block Store restoring sign-in in production on or before 30 September 2026 are treated as compliant. That date has passed. Block Store work done after it does not count, so a new integration needs restore keys.

Why a Firebase app needs a server

Restore keys are WebAuthn credentials, the same kind as passkeys. Google's implementation guide starts with this step: set up a relying party server "similar to the server for passkeys". The server creates the key options, stores the public key, and checks the key when the app restores on a new phone.

Firebase Authentication has no passkey support. The feature request has been open since 22 May 2025. As of 10 October 2026 it has no reply from Google. To turn a checked key into a Firebase session, your server also has to mint a custom token with the Admin SDK.

What to build

  1. Four server endpoints, for example Cloud Functions: registration options, registration verify (store the public key for the user), sign-in options and sign-in verify.
  2. A WebAuthn library on the server. A public reference server notes that silent restores can arrive with the user presence (UP) flag set to 0. Relax that check, and turn off user verification, for restore keys only.
  3. After a good sign-in check, call admin.auth().createCustomToken(uid) and return the token. The app calls signInWithCustomToken.
  4. In the app (androidx.credentials 1.5.0 or later, Android 9 or later): create the restore key after sign-in with cloud backup on. If that throws E2eeUnavailableException, create it again with cloud backup off. On first launch on the new phone, retrieve the key and send it to your sign-in verify endpoint.
  5. Delete the key with clearCredentialState when the user signs out, and when your server ends the session.

Google's restore key steps tie the key to your app's package name and do not mention an assetlinks.json file. Passkeys on the same domain do need one, with the relation delegate_permission/common.get_login_creds, and Google does not say whether restore keys are checked against it. Publishing the file is a small step that covers both.

If you use Supabase or Clerk

If your app uses Supabase or Clerk instead of Firebase Authentication, you may not need your own server. Supabase added restore keys to supabase_flutter on 14 September 2026, marked experimental and Flutter only. Clerk added them to its Android SDK in version 1.1.8 on 18 September 2026. Check your vendor's notes for the current state.

Check your setup for free

Play Restore Keys reads your package name, signing fingerprints and domain. It checks the assetlinks.json file on that domain and gives you the file to publish, the four endpoints, the app calls and a checklist. It has 10 free checks a day and needs no account. Nothing you enter is stored. It does not test your app and is not a Google Play compliance review.

Check your app