> For the complete documentation index, see [llms.txt](https://docs.caf.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.caf.io/caf-sdk/android/standalone-modules/caffacelivenesslite/changelog.md). # Changelog ## Release notes ### Version 7.25.0 **Release date:** * 09/08/2026 #### What's new **Immediate result after capture** The liveness result now reaches your listener as soon as the capture finishes, instead of waiting for the backend transaction call to complete.No code change is required — you keep handling the same events. #### Breaking changes None. This version requires no changes to your integration. ### Version 7.23.0 **Release date:** * 08/24/2026 #### What's new **Faster camera start with session pre-warming** The Liveness flow is now split into `configure()`, `prewarm()` and `startLiveness()`. Calling `prewarm()` while the user is still on the previous screen creates the Liveness session in the background, so the camera opens without waiting for the network. `prewarm()` is optional — skip it and `startLiveness()` creates the session itself, exactly as before. #### Breaking changes `startLiveness()` no longer takes a `Context` or a `CafLivenessConfig`. Both move to the new `configure()` method, which you call once before starting. | Before | After | | ------------------------------------------ | ----------------------------------------------------------- | | `startLiveness(context, config, listener)` | `configure(context, config)` then `startLiveness(listener)` | | — | `prewarm()` (new, optional) | * `configure(context: Context, config: CafLivenessConfig)` stores the credentials and retains the application context. It makes no network request, so it is safe to call early. * `startLiveness(result: FaceLivenessLiteListener)` now takes only the listener. * Calling `startLiveness()` without `configure()` delivers `LivenessLiteEvent.Error` with type `CONFIGURATION_EXCEPTION`, and no request is made. * The event callback is unchanged — your existing handling of `Success`, `Failure`, `Error`, `Cancelled`, `Loading` and `Loaded` keeps working as is. * `release()` now also discards any pre-warmed session. The configuration from `configure()` is kept, so you can start again without reconfiguring. kotlin ```kotlin val livenessConfig = CafLivenessConfig( mobileToken = "", stage = CafStage.PROD, personId = "", showLoading = true, enableSecurity = true ) // Once, when the screen before Liveness is created CafFaceLivenessLite.instance.configure(context, livenessConfig) CafFaceLivenessLite.instance.prewarm() // When the user starts CafFaceLivenessLite.instance.startLiveness { event -> when (event) { is LivenessLiteEvent.Success -> { /* Handle Success */ } is LivenessLiteEvent.Failure -> { /* Handle Failure */ } is LivenessLiteEvent.Error -> { /* Handle Error */ } LivenessLiteEvent.Cancelled -> { /* The user abandoned the flow */ } LivenessLiteEvent.Loading -> { /* Show a loading indicator */ } LivenessLiteEvent.Loaded -> { /* Hide the loading indicator */ } } } ``` ## Version 2.21.0 ### **Release date:** * 08/07/2026 ### What's new **Customize the liveness screen** You can now brand the liveness screen through the new `uiCustomization` option in `CafLivenessConfig`. Colors, the app bar title, the logo and close icons, the font and the mask blur are all configurable. Every field is optional — anything you leave out keeps the default appearance, so existing integrations are unaffected. ```kotlin val uiCustomization = UiCustomization( font = LivenessFont.ResFont(R.font.your_font), appBar = AppBarCustomization( title = "Identity check", titleColor = Color.WHITE, color = navyColor, logoIcon = R.drawable.your_logo, closeButton = R.drawable.your_close_icon, ), mask = MaskCustomization(isBlurEnabled = true, color = navyColor), prompt = PromptCustomization( textColor = Color.WHITE, backgroundColor = greenColor, isRounded = true, ), ) val config = CafLivenessConfig( mobileToken = mobileToken, personId = personId, uiCustomization = uiCustomization ) CafFaceLivenessLite.instance.startLiveness( context = context, config = config, ) { event -> /* ... */ } ``` Colors are color values (`@ColorInt`), not color resources — resolve resources with `ContextCompat.getColor(...)` before passing them. Icons and fonts are resource ids. ## Version 7.18.0 ### **Release date:** * 07/30/2026 ### What's new: #### **Dynamic iProov service location** The SDK now follows the iProov SP provided by the backend. Server-side change — no integration changes required. #### **Signed response on failure** When a liveness attempt fails (for example, eyes closed or poor lighting), the SDK now also retrieves the transaction result and returns the `signedResponse` in the `Failure` event — previously available only on success. If the result can't be retrieved, an `Error` event is returned instead. #### Breaking changes The `LivenessLiteEvent` contract changed. Update your event handling: | Before | After | | ------------------------------- | -------------------------------------------- | | `Success(val response: String)` | `Success(val signedResponse: String)` | | `Failure(type, description)` | `Failure(signedResponse, type, description)` | | `Error(type, description)` | `Error(type, description, cause)` | * `Success.response` was renamed to `Success.signedResponse`. * `Failure` now includes `signedResponse`. * `Error` now includes `cause` (the originating `Throwable`). * `CafLivenessConfig.stage` now defaults to `CafStage.PROD` and no longer needs to be provided explicitly. ```kotlin CafFaceLivenessLite.instance.startLiveness( context = context, config = CafLivenessConfig( mobileToken = mobileToken, personId = personId, ), ) { event -> when (event) { is LivenessLiteEvent.Success -> handleSuccess(event.signedResponse) is LivenessLiteEvent.Failure -> handleFailure(event.type, event.description) is LivenessLiteEvent.Error -> handleError(event.type, event.cause) LivenessLiteEvent.Cancelled -> handleCancelled() LivenessLiteEvent.Loading, LivenessLiteEvent.Loaded -> Unit } } ``` Links: {% content-ref url="/pages/SWa4fYvXU4QHS0rTEBa7" %} [Face Liveness Lite](/caf-sdk/android/standalone-modules/caffacelivenesslite.md) {% endcontent-ref %} {% content-ref url="/pages/kzUUoJkdkppda386DUZv" %} [Handling Failures](/caf-sdk/android/getting-started-with-the-sdk/handling-failures.md) {% endcontent-ref %} {% content-ref url="/pages/CjjPANiCm0TOnbldUgeg" %} [Ui Customization](/caf-sdk/android/standalone-modules/caffacelivenesslite/ui-customization.md) {% endcontent-ref %} {% content-ref url="/pages/vsdoZhkDbnAXRhPVlR18" %} [Changelog](/caf-sdk/android/standalone-modules/caffacelivenesslite/changelog.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.caf.io/caf-sdk/android/standalone-modules/caffacelivenesslite/changelog.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.