How to Inspect Biometric Sensors and Authentication Modalities on Android Using ADB dumpsys biometric

Modern Android devices integrate multiple biometric modalities—ranging from capacitive and ultrasonic fingerprint scanners to 3D structured light and camera-based face recognition sensors. To protect sensitive credentials and cryptographic keys, the Android security architecture classifies each sensor into strict security tiers via the Android Biometric Framework. When developing applications that integrate with BiometricPrompt, testing authentication fallback behaviors, or diagnosing biometric lockout bugs, inspecting the biometric subsystem directly via the Android Debug Bridge (ADB) using dumpsys biometric provides comprehensive visibility into sensor tiers, enrollment states, and authentication histories.

Architecture of the Android Biometric Subsystem

The Android biometric framework is orchestrated by the BiometricService daemon. This service acts as an abstraction gateway managing individual modal providers—such as fingerprint, face, and iris services. Each biometric sensor communicates with a dedicated Hardware Abstraction Layer (HAL) running inside a Trusted Execution Environment (TEE) or dedicated security chip (such as Titan M).

Under Android Compatibility Definition Document (CDD) guidelines, biometric sensors are categorized into three strength tiers based on Spoof Acceptance Rate (SAR) and Imposter Acceptance Rate (IAR):

• Class 3 (Strong): Meets stringent spoof resistance criteria (SAR < 7%). Eligible to unlock the KeyStore, generate cryptographic auth-per-use keys, and authorise financial payment transactions.
• Class 2 (Weak): Moderately secure biometrics. Can unlock the device lockscreen but cannot decrypt auth-bound cryptographic keys in KeyStore.
• Class 1 (Convenience): Basic optical face recognition. Unlocks the screen but requires secondary PIN or password verification after reboot or timeout.

Inspecting Biometric Service Diagnostics via ADB

To inspect the complete biometric hardware registry and active sensor status, establish an ADB connection to your device and run:

adb shell dumpsys biometric

The service outputs an exhaustive diagnostic report detailing registered sensors, user enrollment statuses, authentication session logs, and lockout timers.

Querying Registered Sensors and Strength Tiers

To view the hardware modalities and security tiers declared by your device OEM, filter the dump output:

adb shell dumpsys biometric | grep -A 15 "Sensors:"

A typical multi-sensor device returns:

Sensors:
  ID(0), Type: FINGERPRINT, Modality: 2, Strength: 15 (STRONG)
    Enrolled: true, User: 0
    Hardware state: STATE_IDLE
  ID(1), Type: FACE, Modality: 8, Strength: 255 (CONVENIENCE)
    Enrolled: true, User: 0
    Hardware state: STATE_IDLE

Key parameters include:

• Modality: Bitmask indicating the biometric type (e.g., 2 for fingerprint, 8 for face).
• Strength: The evaluated security tier (e.g., 15 / STRONG for Class 3, 255 / CONVENIENCE for Class 1). Applications targeting BIOMETRIC_STRONG in BiometricPrompt.PromptInfo.Builder will automatically filter out convenience sensors.
• Hardware state: Indicates whether the sensor hardware is currently idle, actively scanning, or in a hardware error state.

Auditing Active Authenticators and Lockout States

Android enforces temporary and permanent lockouts when repeated biometric authentication attempts fail. After five unsuccessful attempts, the system enforces a 30-second lockout; repeated failures permanently lock the sensor until the user authenticates with their primary PIN or pattern.

To inspect the current lockout state for a specific user profile:

adb shell dumpsys biometric | grep -A 10 "Lockout:"

If the report indicates LOCKOUT_TIMED or LOCKOUT_PERMANENT, the sensor will reject incoming BiometricPrompt requests with an ERROR_LOCKOUT code without attempting to read the sensor.

Tracing Authentication Sessions and Historical Events

When debugging application issues where biometric prompts dismiss unexpectedly or fail to return auth tokens, inspecting historical events helps identify whether the error was triggered by user cancellation, timeout, or sensor error.

Inspect the recent authentication history log:

adb shell dumpsys biometric | grep -A 25 "AuthSession:"

The session ledger records critical event data:

AuthSession:
  ClientPackage: com.example.bankingapp
  ModalityRequested: 15 (STRONG)
  State: STATE_AUTH_PAUSED
  Error: 5 (BIOMETRIC_ERROR_CANCELED)
  Timestamp: 11-07 10:14:22.410

This entry clarifies the exact client package that requested authentication, the modalities permitted by the app, and the exact return code returned by the framework.

Simulating Biometric Enrolment and Prompts in Emulators

If testing on the Android Emulator, you can simulate fingerprint touch events directly via ADB to validate success and failure callbacks:

# Simulate valid touch with registered fingerprint ID 1
adb emu finger touch 1

# Simulate unrecognized finger touch (triggers authentication failure)
adb emu finger touch 2

Combining emulator finger injection with dumpsys biometric inspection provides a complete validation workflow for authenticating enterprise, healthcare, and banking applications.