Saltar al contingut principal
Un SDK d’Android lleuger i guiat pel servidor per a la verificació d’identitat, amb una configuració mínima.

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 bloc repositories del teu settings.gradle.kts:
Si fas servir settings.gradle (Groovy), fes-ho així:

Pas 2: Afegeix la dependència

Afegeix la dependència de l’SDK al build.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ó.
Si fas servir 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 a arm64-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:
  1. 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.
  2. 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_64 si t’adreces a Chromebooks o altres dispositius x86, o publica divisions d’APK per ABI perquè cap dispositiu deixi de tenir suport.
  3. Activa R8: isMinifyEnabled = true i isShrinkResources = true al tipus de compilació de producció (minifyEnabled true i shrinkResources true si fas servir build.gradle amb 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.
  4. 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 bloc android de la teva aplicació per evitar conflictes de compilació:
Ja està! Gradle resoldrà automàticament totes les dependències transitives.

Permisos

El SDK requereix els permisos següents. Es declaren al AndroidManifest.xml del SDK i es fusionaran automàticament amb el manifest de la teva aplicació:

Funcionalitats de càmera i NFC

El SDK declara android.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 teu Application.onCreate():

Pas 2: Inicia la verificació i gestiona els resultats


Mètodes d’integració

El SDK admet dos mètodes d’integració: No cal backend. El SDK crea la sessió directament amb l’ID del flux de treball de la Didit Console. Limitat només a vendorData.

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.
Aquest enfocament et dona control total sobre:
  • 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 és CameraLens.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.
Consulta tots els idiomes admesos →

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 segellada VerificationResult proporciona el resultat de la verificació:

Casos de resultat

Propietats de SessionData

Tipus d’error

Tots els errors són subclasses segellades de me.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, quan showCloseButton é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 teu gradle.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 el session_token i l’SDK executa el flux.

1. Backend: crear la sessió

2. Android: intercanviar i iniciar l’SDK

3. Backend: rebre la decisió final mitjançant webhook

El resultat de l’SDK és útil per a la retroacció a la interfície, però el resultat autoritatiu arriba mitjançant webhook. Consulta la guia de webhooks per a la verificació HMAC.

Exemple complet


Darrera modificació el 7 de novembre del 2026