Biometric factors allow for secure authentication on the Android platform.
The Android framework includes face and fingerprint biometric authentication.
Android can be customized to support other forms of biometric authentication
(such as Iris). All biometric implementations must meet security specifications
and have a strong rating in order to participate in the
BiometricPrompt
class. Biometrics are measured with the
Imposter
Accept Rate (IAR) and Spoof
Accept Rate (SAR).
For more details on biometric security specifications, see Measuring Biometric Unlock Security.
Source
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
andBiometricManager
instead. - Updated the
FingerprintManager
CTS verifier tests to testBiometricPrompt
usingBiometricPromptBoundKeysTest
.
Implementation
To ensure that users and developers have a seamless biometric experience,
integrate your biometric stack with BiometricPrompt
. Devices that
enable BiometricPrompt
for any modality, including face,
fingerprint, and iris, must adhere to these strength
requirements. If they don't meet the strength requirements, then they
can't implement this class.
To integrate your biometric stack with BiometricPrompt
and
BiometricManager
:
- Ensure that your <Modality>Service is properly hooked up to
BiometricService
and hooks theauthenticate()
method. 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
BiometricPrompt
user interfaces for fingerprint and face - Update the framework to honor
KEYGUARD_DISABLE_*
flags for the added biometrics. - Ensure that your device passes the CTS and CtsVerifier tests for every modality
that you've integrated into
BiometricPrompt
/BiometricManager
. For example, if you have both fingerprint and face, the tests must pass individually for each of them.

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 sensor driver or secure isolated environment (such as the TEE or Secure Element).
- 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 strong biometrics.
- Store only the encrypted form of biometric data or derivatives on the file system, even if the file system itself is encrypted.
- 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.
- Use the file-system path provided by the
set_active_group()
function or provide another way to erase all user template data when the user is removed. It's strongly recommended that biometric template files be stored as encrypted in the path provided. 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.
Customization
If your device supports multiple biometrics, the user should be able to
specify a default in settings. Your BiometricPrompt
implementation should prefer
the 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)
Validation
Your biometric implementation must pass the following tests:
- CTS BiometricManager
- CTS BiometricPrompt (sanity, in-depth testing relies on verifier)
- CtsVerifier BiometricPromptBoundKeysTest: Must pass individually with each modality that the device supports
- CtsVerifier BiometricTest: 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, face1.0), it must pass its relevant VTS test (fingerprint, face)