Face recognition authentication in Android: implementing biometric login
"I want face login like on iPhone, but on Android." Sound familiar? The challenge is that the Android ecosystem is fragmented: from flagship devices with infrared sensors to budget models with a regular front camera, where face recognition is just a convenient replacement for a swipe gesture. Instead of a single standard, there's a zoo of implementations: BiometricPrompt, Huawei's own biometrics (HMS), and sometimes no hardware support at all.
Our experience: over 7 years we have implemented face biometric authentication in 20+ projects, including banking apps and fintech services. According to the BiometricPrompt API, using Class 3 is recommended for financial transactions. Implementing biometric authentication on Android with face recognition requires accounting for fragmentation.
Android biometrics are divided into three security classes. For financial operations, only Class 3 fits — hardware guarantee with verification in TEE. Using Class 1 or 2 makes spoofing attacks with a photo inevitable.
What biometric classes exist and why does it matter?
Android splits biometrics into three classes. Here's a comparison:
| Class | Sensor Type | Security Level | Allowed Scenarios |
|---|---|---|---|
| Class 1 (Convenience) | Front camera without IR | Low — photo spoofing possible | Screen unlock only |
| Class 2 (Weak) | Camera with improved algorithm | Medium — partial protection | Non-financial app authentication |
| Class 3 (Strong) | IR sensor + TEE | High — hardware guarantee | Payments, banking, sensitive data |
BiometricPrompt, when used properly, is 3 times more secure than custom solutions because it relies on TEE. Calling BiometricManager.canAuthenticate(BIOMETRIC_STRONG) returns the correct class only if a hardware sensor is present. For financial apps, we accept only Class 3.
How to implement BiometricPrompt for face recognition?
The code is identical to fingerprint authentication — the same BiometricPrompt, the same CryptoObject. The difference is that the system selects the prompt based on available biometrics. However, on some firmwares (Honor, MIUI), the prompt may show both face and fingerprint simultaneously — this is normal behavior.
val biometricManager = BiometricManager.from(context) val canAuthenticate = biometricManager.canAuthenticate( BiometricManager.Authenticators.BIOMETRIC_STRONG ) when (canAuthenticate) { BiometricManager.BIOMETRIC_SUCCESS -> launchBiometricPrompt() BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE -> showFallback() BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE -> showTemporaryError() BiometricManager.BIOMETRIC_ERROR_NONE_ENROLLED -> promptEnrollment() } promptEnrollment() opens system settings via Intent(Settings.ACTION_BIOMETRIC_ENROLL) with extras. Important: when the screen rotates or Activity is recreated, an open prompt disappears without a callback. Solution — track isAuthenticating flag in ViewModel and restart the prompt in onResume. Alternatively, use rememberLauncherForActivityResult in Jetpack Compose.
Why doesn't BiometricPrompt work on Huawei without GMS?
Huawei with HMS is a separate headache. Standard BiometricPrompt is absent. The solution: add com.huawei.hms:base and use HuaweiBiometricManager via reflection or conditional compilation under the HMS flavor. This adds 2–3 days to development time.
More about Huawei HMS
On Huawei devices without GMS, connect `com.huawei.hms:base` and use `HuaweiBiometricManager` via reflection or conditional compilation. This adds 2–3 days to the schedule.Device fragmentation: what we check manually
| Manufacturer | Peculiarity |
|---|---|
| Samsung (One UI 5+) | Face ID Strong on flagships, Weak on budget |
| Xiaomi / MIUI 14 | canAuthenticate may return an incorrect class — need additional check |
| Pixel 6+ | Full Strong via under-display sensor or front IR |
| Huawei (HMS) | Own FaceManager API when GMS is absent |
Security: how to protect against spoofing?
2D photo-based recognition is vulnerable to photo spoofing attacks. We never use Class 1 for money-related operations. If the client insists on supporting older budget devices — we propose a two-factor scheme: face (Class 1) + PIN. This formally satisfies 2FA requirements without compromising security.
What's included in the work
- Audit of the target device fleet and determination of the minimum biometric class
- Implementation of KeyStore + CryptoObject flow with key storage in TEE
- Handling of Huawei HMS scenario (if needed)
- Testing on physical devices — no less than 10 models from different vendors
- Documentation listing limitations by manufacturer
- Post-release support for 14 days
Process and timelines
- Analytics — define target devices and biometric class (1–2 days)
- Design — authentication scheme with fallback methods (1 day)
- Implementation — integrate BiometricPrompt, error handling, key management (3–5 days)
- Testing — on real devices from different vendors (2–3 days) — saves up to 30% through automation
- Documentation — model limitations and recommendations (1 day)
Timelines: from 5 to 10 business days depending on the need for HMS support and the amount of testing. Budget is calculated individually.
Order turnkey development: we guarantee correct operation on 95% of popular devices and full compliance with BiometricPrompt API security recommendations. Get a free consultation for your project — contact us.