Biometrics Stay organized with collections Save and categorize content based on your preferences.

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 as, 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.

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.

Source

Android 12

• Introduces the BiometricManager.Strings API, which provides localized strings for apps that use BiometricPrompt for authentication. These strings are intended to be device-aware and provide more specificity about which authentication type(s) may be used.
• Includes under-display fingerprint sensor (UDFPS) support.

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.

Implementation

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.In addition, all implementations must pass the CtsBiometricsTestCases CTS module.

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.

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 Trusted Execution Environment (TEE). 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()

Customization

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)

Device-specific authentication strings

Starting in Android 12, contextual authentication strings are made available to developers through the BiometricManager.Strings API. You may customize the resource values returned by this API to implement device-specific strings. If you do, ensure that any new strings are translated for all locales that the device supports. Additionally, make sure the following properties are preserved:

For example, consider a device that has a Class 2 face sensor with an enrolled face, an enrolled PIN, and a Class 3 fingerprint sensor with no enrolled fingerprints. The following table provides sample strings for each combination of allowed authenticators and invoked BiometricManager.Strings method:

Validation

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)