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|
- 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.
- 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_ENROLLintent 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.
- Introduces the
BiometricManagerclass that developers can use to query the availability of biometric authentication.
- Includes fingerprint and face authentication integration for
- Includes fingerprint integration only for
- Deprecates the FingerprintManager class. If your bundled and system apps use
this class, update them to use
- Updated the
FingerprintManagerCTS verifier tests to test
To ensure that users and developers have a seamless biometric experience,
integrate your biometric stack with
APIs. Devices with biometric sensors must adhere to these strength
To integrate your biometric stack with the
- Ensure that your
<Modality>Serviceis properly registered with
BiometricServicevia the IBiometricService#registerAuthenticator method and implements the
IBiometricAuthenticatorinterface. 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.
- Ensure that your new modality is properly supported in SystemUI.
There are default
BiometricPromptuser 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:
- 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.
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 methodor 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
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