Android 9 and higher includes a BiometricPrompt API that app developers can use to integrate biometric authentication into their applications in a device- and modality-agnostic fashion. Only strong biometrics can integrate with BiometricPrompt. For more details, see Measuring Biometric Unlock Security.


Android 9 only includes fingerprint integration for BiometricPrompt. However, integrated support for other biometric modalities are forthcoming.

In Android 9 and higher, the FingerprintManager API is deprecated. If your bundled and system apps use this API, update them to use BiometricPrompt instead.


To ensure that users and developers have a seamless biometric experience, integrate your biometric stack with BiometricPrompt. Devices that enable BiometricPrompt API for any modality, including face, fingerprint, and iris, must adhere to these strength requirements. If they do not meet the strength requirements, then they cannot implement this API.

To integrate your biometric stack with BiometricPrompt:

  1. Add an instance of your BiometricManager class in /frameworks/base/core/java/android/hardware/biometrics/
  2. Make sure your instance hooks the authenticate() method that BiometricPrompt exposes.
  3. Update the framework to honor KEYGUARD_DISABLE_* flags for the added biometrics.
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:

  1. Make sure 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).
  2. If the hardware supports it, limit hardware access to the secure isolated environment and protect it with an SELinux policy. Make the communication channel (e.g. SPI, I2C, etc.) accessible only to the secure isolated environment with an explicit SELinux policy on all device files.
  3. To prevent accidental data breach an immunity to attacks, fingerprint acquisition, enrollment, and recognition must occur inside the secure isolated environment.
  4. Store only the encrypted form of biometric data or derivatives on the file system, even if the file system itself is encrypted.
  5. 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.
  6. 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 is 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.


If your device supports multiple biometrics, you can specify a default. However, you must allow users to change their preferred biometric in Settings.


Android 9 updated the FingerprintManager CTS verifier tests to test BiometricPrompt via BiometricPromptBoundKeysTest. For other biometrics, there are no formal CTS or CTS verifier tests yet.