Android SDK

Integrate SmartComply identity verification and liveness detection into your Android app.

SmartComply Android SDK

The SmartComply Android SDK delivers a fully self-contained identity verification flow for Android apps. Launch one Activity and the SDK handles session management, country and ID-type selection, document capture, identity verification, and liveness detection automatically.

Features

• Single-Activity launch — start verification with one Intent and receive a typed result back
• Two verification modes — document photo capture or ID number data entry, configured from your Dashboard
• Guide-box document capture — frames the ID card precisely so images are always clean and correctly cropped
• Liveness detection — a passive camera scan (blink plus natural head movement) runs automatically after identity verification, with no step-by-step prompts
• Dynamic ID types — channels and fields are fetched live from your Dashboard configuration
• Multi-country support — renders a country picker automatically when more than one country is configured
• Dark and light mode — theme adapts to the system setting; override via the launch intent
• Your brand, not ours: colour and logo come from the Dashboard, your name appears while the session is being set up, and the font is passed by your app. See Branding
• Any backend host: production, staging, or your own, without a rebuild

---

Requirements

• Android API 24 (Android 7.0) or later
• Kotlin 2.1 or later — the SDK is compiled with the Kotlin 2.1 toolchain, so an older consumer compiler rejects it
• Java 17 — the SDK targets JVM 17
• Jetpack Compose enabled in your module

---

Installation

1 — Add Maven Central

In settings.gradle.kts (already present in most projects):

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

2 — Add the dependency

In your app or feature module build.gradle.kts:

dependencies {
    implementation("io.github.386konsult:android-sdk:1.1.2")
}

Use 1.0.5 or later. 1.0.3 and 1.0.4 crash the host app: both read HTTP responses on the main thread, and 1.0.3 additionally crashes when the SDK is closed from a UI callback. Neither can be withdrawn from Maven Central, so pin deliberately.

1.1.2 changes when the liveness selfie is taken. Up to 1.1.1 it fired on a fixed timer half a second after the camera opened, before anything had looked for a face, so the autoshot on the dashboard was routinely of nobody, of a ceiling, or of half a face. It now waits for a frame with a whole face in it. That adds up to 2.5 seconds to the start of the check for a user who is slow to get into frame, and nothing at all for one who is already there. Read Liveness before you upgrade.

Take 1.1.1 or later, not 1.1.0. In 1.1.0 every liveness selfie uploads rotated 90 degrees, so a verification that passes can still report “Face Detected: No” in the dashboard’s Biometrics panel. 1.1.1 is that one fix and changes nothing else.

1.1.0 changes how documents are captured. The camera step now takes a photograph rather than a still of the viewfinder, so it binds a second CameraX use case in your process, uploads an image roughly five times larger in pixels, and takes a moment on the shutter where it used to be instant. Read Document images before you upgrade, and re-test your document flow. It also fixes a genuine ID being rejected with “No face detected” and a first run on a device that has never used ML Kit.

1.0.7 changed two behaviours and they still apply. RESULT_STATUS holds the real verdict, and the success screen does not mean a pass. Read Result Extras before upgrading from 1.0.6 or below.

3 — Enable Compose

android {
    buildFeatures {
        compose = true
    }
}

---

Credentials

Both values come from your Adhere Dashboard and both are permanent. Reuse the same pair for every verification.

Value	Where to find it	Notes
apiKey	Settings → API Keys	A 64-character alphanumeric string with no prefix
clientId	Settings → Integrations → SDK Setup, then the row menu → Integration → Client ID	The UUID of your SDK Config. It is issued by Adhere — do not generate one

clientId is not a per-attempt value. Generating your own UUID returns 404 SDK_CONFIG_NOT_FOUND on the very first call, because the server resolves it against an existing SDK Config record.

---

Permissions

The SDK declares these permissions automatically via manifest merge. You do not need to add them manually unless your project uses a custom manifest merge strategy:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />

SmartComplyActivity requests the CAMERA permission at runtime before it starts the flow, so if you launch through the Activity your app does not need to request it separately. If you embed SmartComplyFlowScreen directly, see Advanced: Custom Host Activity.

From 1.1.0 one meta-data entry merges in as well:

<meta-data android:name="com.google.mlkit.vision.DEPENDENCIES" android:value="face" />

It asks Play Services to fetch the face detection model when your app installs. Without it the model is fetched the first time a detector runs, and that first call fails: the document check reported it as “Could not verify image. Please retake.” no matter how many times the user retook, and liveness ignored every action the user performed until it timed out. If your build strips unknown meta-data, keep this one.

---

Quick Start

1 — Register the result launcher

In your Activity or Fragment:

import androidx.activity.result.contract.ActivityResultContracts
import com.smartcomply.sdk.ui.SmartComplyActivity

val verificationLauncher = registerForActivityResult(
    ActivityResultContracts.StartActivityForResult()
) { result ->
    val data = result.data ?: return@registerForActivityResult
    when (data.getStringExtra(SmartComplyActivity.RESULT_TYPE)) {
        SmartComplyActivity.TYPE_SUCCESS -> {
            val entryId    = data.getIntExtra(SmartComplyActivity.RESULT_ENTRY_ID, -1)
            val status     = data.getStringExtra(SmartComplyActivity.RESULT_STATUS)
            val idTypeName = data.getStringExtra(SmartComplyActivity.RESULT_ID_TYPE_NAME)
            // Branch on `status`: "passed", "failed", or "processing" when the backend
            // had not resolved in time. Reaching this branch is not a pass.
        }
        SmartComplyActivity.TYPE_CANCELLED -> {
            // User pressed back, or denied the camera permission prompt on launch.
        }
        SmartComplyActivity.TYPE_FAILURE -> {
            // apiKey or clientId was blank, so the flow never started.
            val why = data.getStringExtra(SmartComplyActivity.RESULT_ERROR_MSG)
        }
    }
}

2 — Launch verification

import com.smartcomply.sdk.client.Environment

val intent = SmartComplyActivity.buildIntent(
    from        = this,
    apiKey      = "YOUR_API_KEY",     // Settings → API Keys
    clientId    = "YOUR_CLIENT_ID",   // Settings → Integrations → SDK Setup
    environment = Environment.PRODUCTION
)
verificationLauncher.launch(intent)

Jetpack Compose

If you are launching from a composable, use rememberLauncherForActivityResult:

import androidx.activity.compose.rememberLauncherForActivityResult
import androidx.activity.result.contract.ActivityResultContracts
import androidx.compose.ui.platform.LocalContext
import com.smartcomply.sdk.ui.SmartComplyActivity
import com.smartcomply.sdk.client.Environment

@Composable
fun StartVerificationButton() {
    val context = LocalContext.current

    val launcher = rememberLauncherForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { result ->
        val data = result.data ?: return@rememberLauncherForActivityResult
        when (data.getStringExtra(SmartComplyActivity.RESULT_TYPE)) {
            SmartComplyActivity.TYPE_SUCCESS   -> { /* branch on RESULT_STATUS */ }
            SmartComplyActivity.TYPE_CANCELLED -> { /* back pressed, or camera denied */ }
            SmartComplyActivity.TYPE_FAILURE   -> { /* read RESULT_ERROR_MSG */ }
        }
    }

    Button(onClick = {
        val intent = SmartComplyActivity.buildIntent(
            from        = context,
            apiKey      = "YOUR_API_KEY",
            clientId    = "YOUR_CLIENT_ID",
            environment = Environment.PRODUCTION
        )
        launcher.launch(intent)
    }) {
        Text("Verify Identity")
    }
}

---

buildIntent Parameters

fun buildIntent(
    from:        Context,
    apiKey:      String,
    clientId:    String,
    darkTheme:   Boolean? = null,                    // null = follow system
    environment: Environment = Environment.PRODUCTION,
    fontResId:   Int? = null,                        // null = platform default
    baseUrl:     String? = null                      // null = use environment
): Intent

Parameter	Default	Description
from	—	The calling Context
apiKey	—	Your Adhere API key — find it in the Dashboard
clientId	—	Your SDK Config’s Client ID from the Dashboard. Permanent — reuse it for every verification
darkTheme	null	true forces dark mode, false forces light, null follows the device setting
environment	PRODUCTION	See Environments below
fontResId	null	A font resource from your own app, e.g. R.font.inter. See Branding. Added in 1.0.7
baseUrl	null	Overrides environment’s host. See A different host. Added in 1.0.7

---

Environments

Value	Base URL
Environment.PRODUCTION	https://adhere-api.smartcomply.com
Environment.SANDBOX	http://localhost:8000

SANDBOX targets a server running on the handset itself, for local backend development. It is not a hosted test environment. Use PRODUCTION for all integration work.

A different host

Environment covers the two hosts you ship against. For anything else, a staging deployment or a QA build that has to reach more than one backend without being rebuilt, override it. Added in 1.0.7.

SmartComplyActivity.buildIntent(
    from = context, apiKey = "...", clientId = "...",
    baseUrl = "https://your-staging-host.example.com"
)

// or, on SDKConfig directly
SDKConfig(apiKey = "...", clientId = "...", baseUrl = "https://your-staging-host.example.com")

A trailing slash is trimmed, and a blank value falls back to environment rather than being treated as a host, so a build reading this off an empty field does not post verifications to a relative URL.

SANDBOX is a plain http:// target, which Android blocks by default from API 28 onwards. Without an opt-in the flow dies at the loading screen with a network error that looks like a backend outage. If you genuinely need it, scope the exception to localhost rather than reaching for android:usesCleartextTraffic="true", which permits cleartext for every host your app talks to.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <domain-config cleartextTrafficPermitted="true">
    <domain includeSubdomains="false">localhost</domain>
    <domain includeSubdomains="false">10.0.2.2</domain>
  </domain-config>
</network-security-config>

<application android:networkSecurityConfig="@xml/network_security_config" ...>

PRODUCTION is HTTPS and needs none of this.

SmartComplyActivity.buildIntent defaults to PRODUCTION, but the SDKConfig constructor used by the embedded flow defaults to SANDBOX. Set environment explicitly when you construct SDKConfig yourself.

---

Result Extras

Read from the Intent returned to your activity result callback.

Constant	Type	Present when
RESULT_TYPE	String	Always: "success", "cancelled", or "failure"
RESULT_ENTRY_ID	Int	TYPE_SUCCESS — the verification’s entry ID
RESULT_STATUS	String	TYPE_SUCCESS: "passed", "failed", or "processing" if the backend had not resolved in time
RESULT_SUBMITTED_AT	String	TYPE_SUCCESS — ISO 8601 timestamp
RESULT_VERIFIED_NAME	String	TYPE_SUCCESS: the verified name, when the backend returned one
RESULT_ID_TYPE_NAME	String	TYPE_SUCCESS — e.g. "National Identity Number (NIN)", "Passport"
RESULT_ID_NUMBER	String	TYPE_SUCCESS: the ID number, from the user in data mode or from OCR in document mode
RESULT_ERROR_MSG	String	TYPE_FAILURE only: why the launch was rejected, e.g. "SmartComply: apiKey is required"

From 1.0.7 the Activity returns TYPE_FAILURE when apiKey or clientId is blank, which is the usual sign of an unset BuildConfig field or a missing CI value. That result carries no other extras. Before 1.0.7 the same input crashed the host app, so no released version returned TYPE_FAILURE for anything else.

RESULT_VERIFIED_NAME and RESULT_ID_NUMBER are populated from the result poll as well as from submit, from 1.0.7. In document mode they previously appeared only when OCR happened to finish before the user completed liveness, so whether a user saw their own name came down to timing.

Branch on RESULT_STATUS. Reaching this callback is not a pass.

From 1.0.7 the SDK polls the backend for the terminal outcome and puts it here, so "passed" means passed and "failed" means failed. But every submitted entry shows the end user the success screen, including a failed one. That is deliberate and was asked for: tenants wanted their user to see a submitted verification as accepted and to read the real verdict themselves. The screen is neutral-positive; this value is not.

So a TYPE_SUCCESS result with RESULT_STATUS of "failed" is a normal outcome you must handle. Code that treats TYPE_SUCCESS as a pass will admit users who failed verification.

"processing" means the backend had not resolved within about 15 seconds. The entry exists and is billed, and the outcome arrives on your webhook.

Before 1.0.7 RESULT_STATUS was always "processing" and carried no verdict at all, so the result was a submission receipt.

The liveness.completed webhook is the authoritative record. The value here is the same verdict delivered earlier for convenience, and it is absent when the worker is slow; the webhook always arrives.

Also changed in 1.0.7: pressing back on the success screen now returns TYPE_SUCCESS, not TYPE_CANCELLED. It previously reported a cancellation for a verification that had succeeded and been billed. If your TYPE_CANCELLED branch assumed “nothing happened”, it was already wrong, but it will now be reached less often.

---

Verification Flow

The SDK steps through these screens automatically.

Step	Description
Loading	Session creation and brand config fetch
Welcome	Brand splash, country picker, and ID type selection
Camera Permission	Requested in onCreate, before the Loading screen, on the SmartComplyActivity path. On the embedded SmartComplyFlowScreen path it is requested in both modes, before the ID-input or capture step
Camera Permission Denied	Embedded SmartComplyFlowScreen path only: “Camera Access Required” screen with Open Settings and Go Back. On the SmartComplyActivity path a denial returns TYPE_CANCELLED instead and this screen is never shown
Document Capture (front)	Camera view with a guide box, a shutter, and Upload from gallery
Document Capture (back)	Shown when the channel’s requires_back_side is required or optional. The server decides, not the app. On optional the screen also shows a This ID has no back side control, which skips straight to liveness
ID Input	Form fields for data-mode verification (BVN, NIN, etc.)
Liveness	Passive camera scan: see Liveness below
Processing	Upload and backend submission in progress
Success	Shown for every submitted entry. The verdict is in RESULT_STATUS, not on the screen
Failure	Pre-submission errors only: config or network failure, liveness timeout. Offers Try Again

Document images

Document photos are capped at 5 MB server-side, in JPG or PNG. Both routes are held to 1600px on the long edge and re-encoded at JPEG quality 85, so a full-resolution phone photo does not fail with File too large. Maximum size is 5MB.

From 1.1.0 the camera route produces a real photograph. Up to 1.0.7 it read the viewfinder and cropped that, which on a 1080p screen is roughly 700 real pixels across the card. It now binds a CameraX ImageCapture alongside the preview, tied to the preview’s field of view so the guide box crops the same rectangle out of both, and only that rectangle is decoded so a 12MP frame never becomes a 48 MB bitmap.

Three things follow, and all three are worth re-testing before you ship 1.1.0:

• Your app binds Preview + ImageCapture where it bound only Preview. This is well inside the three use cases every CameraX device guarantees.
• A front capture goes from about 918x578 to about 1586x999. If anything downstream of you was sized around the old output, it will see something different.
• The shutter is no longer instant and shows a progress indicator while the still is taken. UI tests that tapped the shutter and immediately asserted on the review screen need to wait.

A gallery pick is also rotated to match its EXIF orientation from 1.1.0. Before that it was uploaded as decoded, so a normal phone photo reached the backend sideways.

Before the review screen the SDK checks the front photo contains a face. A failure is a warning, not a block: the user can still confirm, because a false negative would otherwise trap someone holding a genuine but unusual ID. The backend OCR is the check that actually rejects. The back photo is not checked.

From 1.1.0 that check runs ML Kit’s accurate model. The fast one it used before does not find the portrait on a laser-engraved card, so genuine IDs of that kind, Kenya’s Maisha Namba among them, were told “No face detected”.

---

Branding

The flow carries your brand, not Adhere’s. Colour and logo come from the SDK Config on the dashboard, so they change without an app release, and your name is shown while the session is being set up. The font is the one exception and is passed by the host.

What	Set where	Shows up as
Brand name	Dashboard, SDK Config	The loading screen (“Setting up <name>…”) and the logo’s content description
Theme colour	Dashboard, SDK Config	Primary buttons, highlights, progress
Logo	Dashboard, SDK Config	The mark on the welcome screen
Font	Your app, at launch	Every screen

The welcome heading and subheading are fixed SDK copy: “Verify Your Identity”, then one of two lines keyed off the verification mode.

Logo

Upload it under Settings → Integrations → SDK → Brand Details. PNG, JPEG or WebP, up to 512 KB and 1024x1024 pixels. Requires 1.0.7.

It is drawn on its own, with no box or border behind it, and bounded by height rather than fitted into a square so a wordmark stays legible. Only the SDK’s fallback shield sits in a tinted frame.

The logo belongs to the SDK Config, not the company. A branch running several configs for different products gives each its own mark, and a config with no logo shows the SDK’s own shield rather than falling back to the company logo on your profile page. If you want the same mark everywhere, upload it to each config.

A logo never delays or blocks a verification. The SDK fetches it after the welcome screen is already on screen, on a three second budget, and keeps its own shield if the fetch fails. It is also decoded with a size cap, so an oversized image cannot exhaust memory on the handset.

The logo is rendered by the Android and iOS SDKs. The Web SDK does not show it yet, so a config used by both will carry your mark on mobile and the default on web.

Font

Passed by your app, because the SDK neither ships nor downloads font files: your loading, caching and licensing stay yours. Requires 1.0.7.

Through buildIntent, with a font resource:

val intent = SmartComplyActivity.buildIntent(
    from      = context,
    apiKey    = "YOUR_API_KEY",
    clientId  = "YOUR_CLIENT_ID",
    fontResId = R.font.inter        // res/font in your own app
)

Or, if you host SmartComplyFlowScreen yourself, with a FontFamily directly, which is the only way to control each weight:

SmartComplyFlowScreen(
    sdk        = sdk,
    fontFamily = FontFamily(
        Font(R.font.inter_regular,  FontWeight.Normal),
        Font(R.font.inter_medium,   FontWeight.Medium),
        Font(R.font.inter_semibold, FontWeight.SemiBold),
        Font(R.font.inter_bold,     FontWeight.Bold)
    ),
    onComplete = { result -> }
)

Point fontResId at an XML font family rather than a single font file and the platform resolves real faces per weight on API 28+. A single file is used for every weight, which flattens the SDK’s type hierarchy.

A font resource that cannot be loaded, including one R8 has stripped, falls back to the platform font. It does not fail the verification.

---

Liveness

Two actions are drawn from BLINK and TURN_HEAD in random order and detected passively. Both are watched on every frame, neither is named to the user, and the HUD only reports how many are done: there is no prompted sequence.

Action	What satisfies it
BLINK	Mean eye-closure across both eyes reaching 0.22, for one frame
TURN_HEAD	About 7.5 degrees of yaw in either direction, held two frames

The scan has a 20 second cap.

When the autoshot is taken

Two stills leave the device. The autoshot is taken before the scan starts and uploaded with the entry; the snapshot is taken once both actions are done and uploaded with the video. Both come off the analysis stream, so neither is a composed photograph: 720px on the long edge at JPEG quality 72.

From 1.1.2 the autoshot waits for a face. Up to 1.1.1 it fired on a fixed delay(500) after the camera bound, and nothing had looked for a face by then, because detection did not start until recording did. The one frame of the session that became the selfie was the only frame no detector had ever seen, so clients reported autoshots of nobody, of ceilings, and of half a face.

It now runs face detection from the first frame and holds the shot until three consecutive frames show a face that is wholly inside the frame with an 8% margin, spans at least 18% of the frame width, and is within 30 degrees of facing the camera. What changes for you:

• Timing. A 400ms settle, then up to 2.5 seconds waiting. On a TECNO KI7 a user already in frame cleared it in about 1 second. A user who never presents a face waits the full 2.5 seconds and then gets the old behaviour, so the fallback is never a worse image than 1.1.1 produced, only a later one.
• The challenge window is unaffected. The wait sits before liveness.create, so the 20 second cap still starts with a full 20 seconds.
• The HUD. “Position your face in the oval” now shows during that wait, where earlier versions went straight from camera-ready to detecting.

The margin check is the part doing the work. ML Kit reports a face running off the side of the frame as readily as one in the middle, and a chin cut off at the edge is what the backend cannot find a face in: measured on device, a selfie with the face box bottom at 0.97 of the frame height came back Face Detected: No, and one at 0.90 came back detected at 0.95 confidence.

Upgrade past 1.1.0 for the liveness stills. Up to and including 1.1.0 the autoshot and snapshot uploaded in the camera’s sensor orientation, rotated 90 degrees from upright, because the rotation arrives as metadata and was not applied. On-device detection was never affected, so the challenges always worked, but the backend was handed a sideways face: a passing verification could report Face Detected: No with no face confidence. Fixed in 1.1.1, where the rotation is baked into the pixels. If you read the autoshot or snapshot yourself, from 1.1.1 they are upright, 480x640 rather than 640x480 on a portrait capture, and carry no EXIF orientation tag. The liveness .mp4 was never affected.

Reaching the cap fails the check. Nothing is uploaded and nothing is billed, and the user is offered Try Again. Earlier versions submitted anyway and reported success with no actions completed: if you are on 1.0.6 or below, expect that behaviour.

What the success screen means

Nothing about the verdict. Every submitted entry reaches it, whether the backend passed or failed the check.

The submit call returns processing, because the backend resolves face matching on a worker moments later. The SDK polls for up to about 15 seconds and puts whatever it learns in RESULT_STATUS, then shows the success screen either way. A user who failed is not told so and is not offered a retry.

This is a product decision, not an oversight: tenants asked for the end user to see a submitted verification as accepted, and to act on the real verdict themselves from the dashboard and the webhook. It means you have to close the loop with a user who failed.

Pre-submission failures are unaffected and still show the failure screen with Try Again: a denied camera, a configuration or network error, and reaching the 20 second liveness cap. Nothing has been billed at that point and the user can recover on the spot.

---

SDK Configuration

data class SDKConfig(
    val apiKey:             String,
    val clientId:           String,
    val environment:        Environment = Environment.SANDBOX,
    val requestTimeoutMs:   Long        = 30_000L,
    val verifyTimeoutMs:    Long        = 90_000L,
    val uploadTimeoutMs:    Long        = 120_000L,
    val maxUploadRetries:   Int         = 3,
    val debug:              Boolean     = false,
    val baseUrl:            String?     = null
)

Parameter	Default	Description
apiKey	—	Your Adhere API key (required)
clientId	—	Your SDK Config’s Client ID (required)
environment	SANDBOX	Set this explicitly — see Environments
requestTimeoutMs	30000	Timeout in milliseconds for standard API calls
verifyTimeoutMs	90000	Timeout for onboarding/verify alone, which blocks on a government identity provider. At the 30s default it intermittently timed out client-side while the server completed the check and billed for it
uploadTimeoutMs	120000	Timeout in milliseconds for image and video upload
maxUploadRetries	3	Total upload attempts, not retries after the first. Only transport failures are retried; an API error is surfaced immediately. The final submit is not retried
debug	false	Prints verbose network logs to Logcat when true
baseUrl	null	Overrides environment’s host. See A different host. Added in 1.0.7

---

Error Handling

SmartComplyActivity handles and displays all error states inside the flow: an invalid key, an expired session, or an exhausted upload retry all render the SDK’s own failure screen with a Try Again button. From 1.0.7 the Activity also returns immediately, before any screen renders, when apiKey or clientId is blank. Otherwise it returns a result only when the user completes the flow or backs out.

Scenario	Cause	Resolution
Failure screen, invalid key	apiKey is wrong or the branch is not enabled for onboarding	Check your key in the Adhere Dashboard
Failure screen, no configuration found	clientId is not an active SDK Config	Copy the Client ID from Settings → Integrations → SDK Setup. Do not generate a UUID
Failure screen, session expired	Session tokens have a 30-minute TTL	Relaunch. A new session is created on each launch; your clientId never changes
TYPE_CANCELLED	User pressed back, or denied the camera permission prompt on launch	Reconcile against the webhook before assuming the user abandoned the flow
TYPE_FAILURE	apiKey or clientId was blank at launch, so the flow never started	Read RESULT_ERROR_MSG. Check the value is actually reaching buildIntent; a blank string is not the same as a wrong key, which shows the failure screen instead

---

Advanced: Custom Host Activity

If you need to embed the verification flow directly inside your own ComponentActivity instead of launching a separate screen, you can use SmartComplyFlowScreen as a Compose composable:

import com.smartcomply.sdk.SmartComply
import com.smartcomply.sdk.client.SDKConfig
import com.smartcomply.sdk.client.Environment
import com.smartcomply.sdk.ui.SmartComplyFlowScreen

val sdk = SmartComply(
    SDKConfig(
        apiKey      = "YOUR_API_KEY",
        clientId    = "YOUR_CLIENT_ID",
        environment = Environment.PRODUCTION   // required: SDKConfig defaults to SANDBOX
    )
)

// In your composable:
SmartComplyFlowScreen(
    sdk        = sdk,
    darkTheme  = null,            // null = follow system setting
    fontFamily = null,            // null = platform default; see Branding
    onComplete = { result ->
        // result.entryId, result.status, result.submittedAt
    }
)

Your host Activity must be a ComponentActivity and must be in the foreground with an active window. Embedding SmartComplyFlowScreen inside a Dialog or bottom sheet will cause the camera to fail on some devices.

You do not need to request CAMERA yourself. From 1.0.2 the composable routes through its own permission screen in both verification modes, before the ID-input or document-capture step, and skips it silently once the permission is granted.

On 1.0.1 and earlier data mode never asked, so if the permission had not already been granted the camera never opened: the liveness preview stayed black and the flow ended with Recording failed: Recording finalized with error code 4. If you are pinned to an older version, request CAMERA yourself before entering the flow, or launch through SmartComplyActivity, which always asked for both modes.

---

Dependencies

From 1.0.3 the SDK no longer depends on Ktor. It uses OkHttp directly, so your own Ktor version cannot conflict with ours.

On 1.0.2 and earlier, an app that uses Ktor 3 crashes on launch:

java.lang.NoClassDefFoundError: Failed resolution of:
Lio/ktor/client/plugins/contentnegotiation/ContentNegotiation;
    at com.smartcomply.sdk.SmartComply.<init>

Those versions were compiled against Ktor 2.3.12 and exported it, so Gradle resolved the conflict to your newer Ktor and linked our code against a version where the classes we call had been removed. There is no workaround on your side. Upgrade to 1.0.5.

---

ProGuard / R8

There is nothing to do. The SDK ships consumer ProGuard rules inside the AAR, so R8 applies them to your app automatically. They keep the generated kotlinx.serialization serializers and SmartComplyActivity; OkHttp ships its own rules in its jar.

On 1.0.0, a minified build crashes on launch with a NoClassDefFoundError on a Ktor class. That version shipped no consumer rules. Upgrade to 1.0.5.