Android Developers: Passkey Design Patterns and Biometric Authentication
Google’s Android developer documentation.
License: Apache License 2.0 — confirmed per developer.android.com’s own /license page, which states the site’s documentation is licensed under Apache 2.0.
Key points
- User authentication with passkeys frames passkeys as a safer, more convenient password replacement built on a device’s own screen-lock (fingerprint, face, PIN, or pattern), and names four specific moments to promote passkey creation: during account creation (as the default sign-up option, with alternatives still reachable via an “Other options” page), during account recovery (right when a forgotten-password reset finishes, since the frustration just experienced makes people more receptive), immediately after signing in with a password, and inside account settings for existing users already in an account-management mindset.
- User authentication with passkeys gives exact content rules: lead with benefit before naming the technology, and don’t start the passkey creation flow without first stating the benefit; use familiar language tying a passkey to the device’s own screen lock rather than over-explaining the underlying technology; include the term “passkey” but don’t make it the header’s central focus, since it’s still an unfamiliar term to most people; use the exact button label “Create a passkey” (not “Add a passkey” or other variants) to stay consistent with the platform’s own Credential Manager screens; and always show a confirmation message after a passkey is successfully created.
- User authentication with passkeys covers passkey management: a settings page should show the password manager’s name and icon, when the passkey was created and last used, and a delete option — but should never highlight the device name a passkey was created on, since that wrongly implies the passkey only works on that one device. It also covers unified sign-in: Credential Manager consolidates passkeys, passwords, and federated sign-in into one account-selector screen rather than a separate button per method, and proposes the safest available method automatically (offering the passkey over the password when an account has both) — with a “More options”/“Sign-in options” escape hatch whenever a person can’t find their account or wants to use a different, saved credential.
- User authentication with passkeys also specifies a consistent, unified passkey icon (Google’s own, filled version only, light/dark-theme aware) for cross-app recognition, and a content style guide distinguishing “Sign in” (the verb) from “sign-in” (the noun/adjective), preferring “Sign in” over “Log in” for platform-terminology consistency.
- Show a biometric authentication dialog is overwhelmingly API/code documentation (
BiometricPrompt, Keystore, cipher setup) outside scope, but draws one clean design-relevant line: use Credential Manager (passkeys) for a device’s initial sign-in, and either Biometric Prompt or Credential Manager for a subsequent in-app re-authorization of a specific sensitive action. It also gives a risk-calibration rule for that re-authorization case: require an explicit user action to confirm biometric approval for a high-risk action like a purchase, but a lower-risk action can skip that explicit confirmation step and let the passive biometric check (e.g. face or iris recognition) resolve on its own — and notes the OS-provided dialog’s own cross-app consistency is itself part of why people trust it.