Skip to main content

Requirements

  • minSdk 26 (Android 8.0)
  • JDK 17
  • Jetpack Compose in the host app
  • A physical device for capture steps

1. Get access to the packages

Artifacts are published to GitHub Packages. Ask your Legal Talent contact to add your GitHub users to the partner team, then create a classic personal access token with read:packages and repo (read). Store the credentials in ~/.gradle/gradle.properties, never in the project:
GitHub Packages requires authentication even for public packages. On CI, inject gpr.user / gpr.token as Gradle properties from your secrets store.

2. Add the dependency

settings.gradle.kts
app/build.gradle.kts
Declare both, with the same version. legaltalent-ui brings core, forensics and liveness into your app at runtime, but releases up to 0.2.0 do not put legaltalent-core on your compile classpath, and the flow’s own parameters (KYCEnvironment, KYCSession) live there. From 0.3.0 the legaltalent-ui line is enough. Use legaltalent-core alone for a headless integration. legaltalent-ui and legaltalent-liveness bring Amplify Face Liveness, which needs core library desugaring in your app module:
app/build.gradle.kts
Amplify’s Cognito client puts OkHttp 5 (5.0.0-alpha.14, the version the AWS SDK for Kotlin ships against) on your classpath and every legaltalent-* module runs on it. Gradle resolves your app to that version on its own. Do not pin OkHttp to 4.x (a strictly constraint, resolutionStrategy.force, or a BOM from another library): the build still succeeds, but the liveness step fails at runtime. Check what your app resolved with ./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep okhttp.

3. Permissions and network

The SDK’s manifest already declares CAMERA (and NFC in the NFC module); the SDK requests the runtime permission when a capture step opens. You don’t need to add anything. Workflows with an nfc_read step need the legaltalent-nfc artifact and a reader; see NFC chip step. The SDK records fraud-prevention device signals. Before publishing, update your Google Play Data safety form as described in Device signals, and consider enabling Play Integrity there. Keep HTTPS only. Recommended res/xml/network_security_config.xml:

4. Create a session on your backend

Your backend creates the session with its API key and returns only the access_token to the app:
Return data.access_token to the app. See Create Session for every parameter.
Never call POST /kyc/sessions from the app, and never embed the API key in the APK.

5. Present the flow

environment defaults to KYCEnvironment.DEV. Always pass it explicitly: STAGING while you integrate, PRODUCTION when you go live. The token must come from the same environment.
The flow state lives in a ViewModel keyed by the access token, so it survives configuration changes such as rotation.

6. Handle the result

onComplete fires once, after the last step is submitted. Treat it as a UX signal:
  1. Navigate away from the flow and show a “verification in progress” screen.
  2. Wait for your backend to receive kyc.session.processed (or the manual approved / rejected events), or poll GET /kyc/sessions/{id} from your backend.
  3. Update the app from your backend’s state.
If the applicant closes the flow, onExit fires after a confirmation dialog. The session stays open until it expires, so presenting the flow again with the same token resumes where they left off.

Logging

Every module reports through LegalTalentLogging (legaltalent-core). The default level is WARN, written to logcat under the emitting component’s tag (LegalTalentFlow, LegalTalentLiveness, LegalTalentClip, …). level is the only gate: DEBUG shows debug lines without any setprop log.tag.…. Headless use of legaltalent-core on a plain JVM goes to java.util.logging. The SDK never logs applicant data: no tokens, images, field values or chip contents.

Headless

Errors are thrown as LegalTalentError; see Reference.