Biometrics offer a more convenient, but potentially less secure way of confirming your identity with a device. Under the tiered authentication model, primary authentication (that is, knowledge-factor based modalities such as PIN, pattern, and password) provides the highest level of security. Biometrics are in the secondary tier of authentication, offering a balance of convenience and security. The Android CDD defines three classes of biometric strength: Class 3 (formerly Strong), Class 2 (formerly Weak), and Class 1 (formerly Convenience). Each class has a set of prerequisites, privileges, and constraints - please see the CDD above for more details. All three classes are allowed to integrate with lockscreen, but only Strong and Weak authenticators are allowed to integrate with the android.hardware.biometrics APIs. This table describes each authenticator and the functionality they support.

Authenticator Lockscreen BiometricPrompt Integration Keystore (time-based key) Keystore (operation-based key)
BIOMETRIC_STRONG (Class 3) Yes Yes Yes Yes
BIOMETRIC_WEAK (Class 2) Yes Yes No No
(Class 1)
Yes No No No
  1. This functionality has been added in Android 11, see this for details

The Android framework includes support for face and fingerprint biometric authentication. Android can be customized to support other biometric modalities (such as Iris). However, biometric integration will depend on biometric security, not modality. For more details on biometric security specifications, see Measuring Biometric Unlock Security.


Android 11

  • Introduces the BiometricManager.Authenticators interface, which provides constants that developers can use to specify the types of authentication accepted by their apps.
  • Adds the ACTION_BIOMETRIC_ENROLL intent action, which developers can use to direct the user to enroll an authentication method that meets the requirements of their apps.
  • Adds the AuthenticationResult#getAuthenticationType() method, which developers can use to check whether the user authenticated using a biometric credential or a device credential.
  • Provides additional support for auth-per-use keys within the BiometricPrompt class.

Android 10

  • Introduces the BiometricManager class that developers can use to query the availability of biometric authentication.
  • Includes fingerprint and face authentication integration for BiometricPrompt

Android 9

  • Includes fingerprint integration only for BiometricPrompt.
  • Deprecates the FingerprintManager class. If your bundled and system apps use this class, update them to use BiometricPrompt and BiometricManager instead.
  • Updated the FingerprintManager CTS verifier tests to test BiometricPrompt using BiometricPromptBoundKeysTest.


To ensure that users and developers have a seamless biometric experience, integrate your biometric stack with BiometricPrompt, BiometricManager, and ACTION_BIOMETRIC_ENROLL APIs. Devices with biometric sensors must adhere to these strength requirements.
To integrate your biometric stack with the BiometricPrompt and BiometricManager APIs:

  1. Ensure that your <Modality>Service is properly registered with BiometricService via the IBiometricService#registerAuthenticator method and implements the IBiometricAuthenticator interface. Common modalities (fingerprint, face) extend from a common superclass. If you need to integrate an unsupported modality, follow the fingerprint/face example and the CDD guidelines for biometrics.
  2. Ensure that your new modality is properly supported in SystemUI. There are default BiometricPrompt user interfaces for fingerprint and face. This should include any layout or theme changes required for your device. I.e. corresponding layout changes for an in-display fingerprint sensor.

To integrate your biometric stack with the ACTION_BIOMETRIC_ENROLL API:

  1. Modify the BiometricEnrollActivity to present your enrollment flow. Note that your biometric can be presented only if it meets the requested strength. If your device supports more than one, this action should present a list the user can choose from.
BiometricPrompt architecture
Figure 1. BiometricPrompt architecture

HAL implementation guidelines

Follow these biometric HAL guidelines to ensure that biometric data is not leaked and is removed when a user is removed from a device:

  • Make sure that raw biometric data or derivatives (such as templates) are never accessible from outside the secure isolated environment (such as the TEE or Secure Element). All stored data must be encrypted with a device-specific key known only to the TEE (Trusted Execution Environment). If the hardware supports it, limit hardware access to the secure isolated environment and protect it with an SELinux policy. Make the communication channel (for example, SPI, I2C) accessible only to the secure isolated environment with an explicit SELinux policy on all device files.
  • Biometric acquisition, enrollment, and recognition must occur inside the secure isolated environment to prevent data breaches and other attacks. This requirement only applies to Class 3 (formerly Strong) and Class 2 (formerly Weak) biometrics.
  • To protect against replay attacks, sign biometric templates with a private, device-specific key. For Advanced Encryption Standard (AES), at a minimum sign a template with the absolute file-system path, group, and biometric ID such that template files are inoperable on another device or for anyone other than the user that enrolled them on the same device. For example, prevent copying biometric data from a different user on the same device or from another device.
  • If you need to store data outside of the TEE, use the file-system path provided by the setActiveUser() HIDL method or provide another way to erase all user template data when the user is removed. The reason is to protect leaking of user data. Devices that don't use this path must clean up after the user is removed. It's required by CDD that biometric data and derivative files be stored encrypted - especially if not in TEE If this is infeasible due to the storage requirements of the secure isolated environment, add hooks to ensure removal of the data when the user is removed or the device is wiped. See LockSettingsService.removeBiometricsForUser()


If your device supports multiple biometrics, the user should be able to specify a default in settings. Your BiometricPrompt implementation should prefer the Class 3 (formerly Strong) biometric as the default unless the user explicitly overrides it, then a warning message needs to be displayed explaining the risks associated with the biometric (for example, A photo of you may unlock your device)


Your biometric implementation must pass the following tests:

  • CTS BiometricManager
  • CTS BiometricPrompt (sanity, in-depth testing relies on verifier)
  • CtsVerifier Biometric Test section: Must pass individually with each modality that the device supports

In addition, if your device supports a biometric that has an AOSP HIDL (fingerprint@2.1, fingerprint@2.2, face1.0), it must pass its relevant VTS test (fingerprint, face)