[Android] Zero-Tap Sign-In requirement from Google Play.

[rohansohonee1]

https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html?utm_source=email&utm_medium=msa&utm_campaign=elevating-app-quality-q3-2026

Google Play has a requirement for using the Zero-Tap Sign-In for apps starting from April 2027.

How do we use this and the API listed with Firebase Authentication?

Firebase Support said:

Firebase Authentication SDK does not have a built-in wrapper or automatic integration for the Android Restore Credentials API. Integrating this feature would require a custom solution implemented in your application.

A "custom implementation" implies we would have to stop using the Firebase Authentication product entirely?

[rohansohonee1]

Firebase Support responded with:

Please note that help in designing apps or implementation of features falls outside of the scope of our support. By “custom implementation” I meant that this new requirement from Google Play is not related to Firebase itself and has to be handled fully using the Android SDK. As Firebase Support I have limited knowledge in working with Android development and I’m not able to help in implementing this feature due to the scope of our support.

That being said, to the best of my understanding of the documentation provided by Google Play this is the basic implementation:

• Once a user logs into your app, create a RestoreCredential.
• Save it to Android Credential Manager.
• Add logic to your app which checks on first start-up if a RestoreCredential exists.
• If it exists, use it to log-in the user to your app.

[rohansohonee1]

Can we start by doing the following?

1. Creating our own backend server which will need to be using a WebAuthn library to store the restore keys.
2. Use FirebaseAuth signInWithCustomToken to login the user.
3. Create or use an existing plugin https://pub.dev/packages/android_restore_credentials

[Harshul1484]

No, you don't have to stop using Firebase Authentication. "Custom implementation" means Firebase won't create or verify the restore key for you. Firebase Auth can still be the sign-in system, with the restore key as an extra credential that your own backend checks before handing the app a Firebase custom token. Your three steps are the right shape; here is what each one involves.

Google's implementation guide describes restore keys as WebAuthn credentials: "If you already have a server set up to handle authentication with passkeys, use the same server-side implementation for restore keys." (Restore Credentials implementation)

1. Create the restore key (old device, after any Firebase sign-in)

• The app asks your backend (for example a Cloud Function that checks the caller's Firebase ID token) for WebAuthn registration options (PublicKeyCredentialCreationOptionsJSON), with the user handle mapped to the Firebase uid.
• On Android: CreateRestoreCredentialRequest(requestJson) → credentialManager.createCredential(...).
• Send the response to the backend, verify it with any WebAuthn server library (for example @simplewebauthn/server in Cloud Functions), and store the credential ID and public key against the uid (Firestore works).

2. Restore on the new device (first app launch)

• Fetch authentication options (PublicKeyCredentialRequestOptionsJSON) from the backend.
• GetRestoreCredentialOption(authenticationJson) → credentialManager.getCredential(...) → RestoreCredential.
• The backend verifies the assertion, looks up the uid from the credential ID, and returns admin.auth().createCustomToken(uid).
• The app calls FirebaseAuth.instance.signInWithCustomToken(token). It's the same uid, so the user's data and linked providers are all still there.

3. Sign-out

• Call ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL) alongside FirebaseAuth.signOut(). Google recommends deleting the key on sign-out.

Flutter specifics
There's no FlutterFire wrapper for this, and the API currently ships in androidx.credentials / credentials-play-services-auth 1.7.0-alpha03. A small Kotlin MethodChannel covering the create/get/clear calls is the most predictable route. android_restore_credentials may do the same job, but check which androidx version it uses before relying on it.

Two gotchas

• If you mint custom tokens inside Cloud Functions without a service-account key file, the function's service account needs the Service Account Token Creator role. Otherwise createCustomToken fails with an iam.serviceAccounts.signBlob permission error.
• The same guide notes that notifications aren't restored with the credential. If you use FCM, fetch the new FCM token and send it to your backend after the restore sign-in.