Repositori de GitHub
Consulta el codi font i els exemples a GitHub
SDK natiu: Aquest és l’enfocament recomanat per a aplicacions d’Android. Els SDK natius ofereixen la millor experiència d’usuari, una gestió optimitzada de la càmera i suport complet de NFC.
Requisits
Disponibilitat de funcionalitats segons el nivell de l’API: La detecció automàtica de documents i cares requereix l’API 24+ (detectors lleugers propis de Didit, inclosos a
didit-sdk-core). En dispositius amb API 23, el SDK recorre a la captura manual amb un botó d’obturador temporitzat. La resta de funcionalitats funcionen en tot el rang d’API 23+.El consentiment biomètric requereix el SDK natiu 4.10.0 o posterior. Per a les persones afectades per les lleis d’Illinois, Texas o Colorado, Didit pot demanar un consentiment biomètric explícit abans de la primera captura facial. El SDK d’Android 4.10.0 i les versions posteriors mostren aquest pas. Les versions anteriors no el poden mostrar: les seves sessions s’executen com abans, i la decisió indica que el consentiment no s’ha recollit (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Actualitza si verifiques persones en aquests estats.Instal·lació
Pas 1: Afegeix el repositori
Afegeix el repositori Maven de Didit al blocrepositories del teu settings.gradle.kts:
settings.gradle (Groovy), fes-ho així:
Pas 2: Afegeix la dependència
Afegeix la dependència de l’SDK albuild.gradle.kts de la teva aplicació:
(!) Pel que fa a la versió, assegura’t de consultar el repositori de GitHub per veure l’última versió.
build.gradle (Groovy), fes-ho així:
Variants de l’SDK
L’SDK d’Android es distribueix en artefactes separats, de manera que la teva aplicació només assumeix el cost binari de les funcionalitats que utilitza.me.didit:didit-sdk de dalt és el paquet complet. Tria el que s’adapti a la teva aplicació:
A partir de la
4.6.0, la signatura de carteres amb WalletConnect es distribueix nativament com a complement opcional propi, me.didit:didit-sdk-wallet.
El paquet complet me.didit:didit-sdk ja l’inclou, de manera que no canvia res si instal·les el paquet.
Si fas servir un dels artefactes més lleugers i vols que la confirmació de titularitat de la cartera s’executi de manera nativa dins de la teva aplicació, afegeix me.didit:didit-sdk-wallet al costat d’aquest; sense el complement, l’SDK completa la confirmació de la titularitat de la cartera mitjançant un flux segur al navegador, de manera que la funcionalitat continua funcionant en qualsevol cas.
Haver mogut WalletConnect fora de didit-sdk-core també ha suprimit diversos megabytes de dependències de cartera de totes les compilacions que no les necessiten.
Tots els artefactes es publiquen amb la mateixa versió, així que mantén-los a la 4.13.2.
Com reduir la mida de la descàrrega
Els models de detecció que s’usen per a la captura automàtica es descarreguen en temps d’execució i es guarden a la memòria cau, de manera que mai no compten per a la mida de la teva aplicació. El que la captura automàtica afegeix a l’aplicació és la biblioteca nativa del temps d’execució de ML, i aquest cost depèn de l’arquitectura de la CPU: aproximadament 10 MB per aarm64-v8a, 7 MB per a armeabi-v7a i 13 MB per a cadascuna de les dues arquitectures x86 dels emuladors.
Per pagar aquest cost només una vegada:
- Publica un Android App Bundle (AAB). Google Play distribueix només l’arquitectura i els idiomes del dispositiu, de manera que un telèfon arm64 instal·la aproximadament 10 MB de codi nadiu (uns 4 MB de descàrrega comprimida). En canvi, un APK universal inclou les quatre arquitectures i ocupa més de 40 MB, que és la causa més habitual de mides inesperadament grans.
-
Si distribueixes un únic APK i el teu públic són telèfons i tauletes ARM, restringeix les arquitectures incloses:
Mantén totes les ABI que els teus usuaris fan servir de veritat: afegeix
x86_64si t’adreces a Chromebooks o altres dispositius x86, o publica divisions d’APK per ABI perquè cap dispositiu deixi de tenir suport. -
Activa R8:
isMinifyEnabled = trueiisShrinkResources = trueal tipus de compilació de producció (minifyEnabled trueishrinkResources truesi fas servirbuild.gradleamb Groovy). L’SDK inclou les seves pròpies regles de consumidor, de manera que el codi de l’SDK que no s’utilitza s’elimina sense cap configuració addicional. -
Limita els idiomes inclosos amb
resConfigs(...)si no necessites totes les 48 configuracions regionals de l’SDK en una compilació d’APK; les divisions per configuració regional de l’AAB ho gestionen automàticament a Google Play.
Pas 3: Afegeix l’exclusió d’empaquetatge
Afegeix això al blocandroid de la teva aplicació per evitar conflictes de compilació:
Permisos
El SDK requereix els permisos següents. Es declaren alAndroidManifest.xml del SDK i es fusionaran automàticament amb el manifest de la teva aplicació:
Funcionalitats de càmera i NFC
El SDK declaraandroid.hardware.camera i android.hardware.nfc com a funcionalitats opcionals (android:required="false"). Així es garanteix que la teva aplicació es pugui instal·lar en dispositius sense càmera ni maquinari NFC: el SDK gestionarà adequadament la falta de maquinari en temps d’execució.
Inici ràpid
Pas 1: Inicialitza el SDK
Inicialitza el SDK al teuApplication.onCreate():
Pas 2: Inicia la verificació i gestiona els resultats
Mètodes d’integració
El SDK admet dos mètodes d’integració:Mètode 1: UniLink (el més senzill)
No cal backend. El SDK crea la sessió directament amb l’ID del flux de treball de la Didit Console. Limitat només avendorData.
Mètode 2: Sessió des del backend (recomanat per a producció)
El teu backend crea la sessió mitjançant l’API de creació de sessions de verificació (POST /v3/session/) amb suport complet de paràmetres (contact_details, expected_details, metadata, callback, etc.), i després passa el session_token al SDK.
- Associar les sessions amb els teus usuaris (
vendor_data) - Definir metadades personalitzades
- Configurar callbacks per sessió
- Proporcionar dades de contacte i dades esperades per a la validació creuada
Configuració
Personalitza el comportament del SDK:Opcions de configuració
Opcions de càmera
Les opcions de càmera coincideixen amb les opcions de càmera del Web SDK. Cada objectiu ésCameraLens.FRONT o CameraLens.BACK.
Si el dispositiu no té l’objectiu sol·licitat, el SDK utilitza la primera càmera que tingui.
El selector de càmera també s’amaga en dispositius que només tenen una càmera.
Estableix una opció del selector a false per bloquejar l’usuari a l’objectiu per defecte d’aquell pas.
Les opcions
showLanguageSelector, showCloseButton, showExitConfirmation i closeOnComplete coincideixen amb el DiditSdkConfiguration del Web SDK. Les opcions específiques de mòbil languageLocale i fontFamily existeixen perquè el SDK mòbil renderitza la interfície de verificació completa de manera nativa (a diferència del Web SDK, que delega a la interfície allotjada dins d’un iframe).Personalització i colors: els colors, els fons i la configuració de la pantalla d’introducció es configuren a través de la configuració de Marca blanca de la Didit Console, i no a la configuració del SDK. Així es garanteix una imatge de marca coherent a totes les plataformes.
Idiomes admesos
El SDK admet 54 idiomes. Si no s’especifica cap idioma, el SDK utilitza la configuració regional del dispositiu, amb l’anglès com a idioma de reserva.Opcions avançades
Per als paràmetres avançats de sessió (contact_details, expected_details, metadata, callback), utilitza el mètode Sessió des del backend. El teu backend crida l’API de creació de sessions de verificació amb tots els paràmetres i després passa el session_token al SDK.
Gestió dels resultats
La classe segelladaVerificationResult proporciona el resultat de la verificació:
Casos de resultat
Propietats de SessionData
Tipus d’error
Tots els errors són subclasses segellades deme.didit.sdk.VerificationError:
Connexió perduda
Si el dispositiu perd la connexió durant la verificació, l’SDK mostra una pantalla que se sobreposa al flux, «Sense connexió a Internet», en lloc de deixar un pas carregant. Continua comprovant-ho en segon pla i tanca la pantalla automàticament tan aviat com es pugui tornar a accedir a Didit, i l’usuari continua des del pas on era. La pantalla ofereix Torna-ho a provar i, quanshowCloseButton és true (el valor per defecte), Surt de la verificació.
En sortir, la verificació acaba amb VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), de manera que la teva aplicació sap que l’usuari ha sortit per la connexió.
Exemple complet de gestió del resultat
Observació de l’estat de l’SDK
Pots observar l’estat de l’SDK per crear una interfície de càrrega personalitzada:ProGuard / R8
L’SDK inclou les seves pròpies regles de ProGuard per al consumidor. No cal cap configuració addicional. Si uses el mode complet de R8, és possible que hagis d’afegir això al teugradle.properties:
Exemple de principi a fi (sessió al backend → SDK d’Android → resultat)
Aquest patró és la integració a punt per a producció. El teu backend crea la sessió, la teva aplicació Android rep elsession_token i l’SDK executa el flux.