## TL;DR
Liveness needs a live camera stream, motion or face tracking, and modern web APIs, and a default Android WebView withholds several of them: camera permission requests never reach the user, WebRTC or getUserMedia is disabled, or the WebView build is years old. Grant camera permission through the WebView chrome client handler, enable JavaScript and media playback without user gesture where your vendor requires it, update the WebView component, and test the exact vendor flow in the app. Keep a fallback that hands the session to the system browser when the WebView cannot support it.

```text
kyc liveness check failed on android webview: how to fix
```

## Use this when
- Liveness succeeds in Chrome but fails or freezes inside your Android app.
- The camera never opens or the permission prompt never appears in app.
- Failures cluster on older Android devices and WebView versions.

## Not for this skill when
- Liveness fails everywhere including desktop browsers. That points at the vendor flow or account setup, not WebView.
- Users fail the liveness challenge itself, blinking or movement errors. That is challenge UX, not embedding.

## Steps
1. Reproduce in the app on a test device and note the exact failure point: permission, camera open, stream start, or challenge processing. Verify: the failure stage is identified on a named device and WebView version.
2. Implement the WebView permission request handler so the page camera request triggers a real Android permission prompt, and confirm the app declares the camera permission. Verify: the in app flow now prompts and the camera opens after approval.
3. Enable the WebView settings your liveness vendor lists, typically JavaScript, DOM storage, and media autoplay allowances, following the vendor Android WebView checklist. Verify: each vendor required setting is on in your WebView configuration.
4. Test across the oldest WebView version your app supports and record the minimum version where the flow completes. Verify: a device on the minimum version finishes a full liveness session.
5. Add a fallback: detect WebView failure or an unsupported version and offer to continue verification in the system browser, preserving the session link. Verify: a staged unsupported WebView reaches the browser fallback and completes there.

## Variant phrasings
### liveness fails in app webview android
Embedding phrasing.
### kyc camera not working android webview
Camera phrasing.
### onfido or persona liveness webview camera permission
Vendor plus permission phrasing.

Compatibility: Android WebView integrations of Onfido, Persona, Jumio, and similar liveness vendors. Exact settings follow your vendor Android WebView guide; the permission handler pattern is standard Android.

## Why it happens
Browsers grant camera flows a full feature set by default, while WebView is a locked down component the host app must configure piece by piece. Liveness vendors build for the browser feature set, so an unconfigured WebView fails in ways that look like vendor or user error, a frozen frame, a silent timeout, a generic failure, until someone tests the same flow outside the app.

## Edge cases / pitfalls
- Some vendors explicitly do not support WebView for liveness and require their native SDK or a browser redirect. Check support terms before engineering around them.
- Enterprise devices with camera policies can block the camera entirely. Detect and message that case separately.
- WebView updates ship through the Play Store, not your app release. A user on a frozen old WebView needs the browser fallback, not an app update prompt.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P2TPlt0jpvBxn1O26L6fTw