Repository GitHub
Visualizza il codice sorgente e gli esempi su GitHub
SDK nativo: è il metodo consigliato per le app Android. Gli SDK nativi offrono la migliore esperienza utente, una gestione ottimizzata della fotocamera e il supporto NFC completo.
Requisiti
Disponibilità delle funzionalità per livello API: il rilevamento automatico di documenti e volti richiede API 24+ (rilevatori leggeri di Didit, inclusi in
didit-sdk-core). Sui dispositivi API 23 l’SDK ripiega sull’acquisizione manuale con un pulsante di scatto a tempo. Tutte le altre funzionalità funzionano sull’intero intervallo API 23+.Il consenso biometrico richiede la versione nativa 4.10.0 o successiva. Per le persone coperte dalla normativa dell’Illinois, del Texas o del Colorado, Didit può chiedere un consenso biometrico esplicito prima della prima acquisizione del volto. L’SDK Android 4.10.0 e le versioni successive mostrano questo passaggio. Le versioni precedenti non possono mostrarlo: le loro sessioni proseguono come prima e la decisione riporta il consenso come non raccolto (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Esegui l’aggiornamento se verifichi persone in questi stati.Installazione
Passaggio 1: aggiungi il repository
Aggiungi il repository Maven di Didit al bloccorepositories del tuo settings.gradle.kts:
settings.gradle (Groovy):
Passaggio 2: aggiungi la dipendenza
Aggiungi la dipendenza dell’SDK al filebuild.gradle.kts della tua app:
(!) Per la versione, controlla il repository GitHub per l’ultima release disponibile.
build.gradle (Groovy):
Varianti dell’SDK
L’SDK Android è distribuito come artefatti separati, quindi la tua app paga in termini di dimensioni del binario solo per le funzionalità che usa.me.didit:didit-sdk qui sopra è il bundle completo. Scegli quello più adatto alla tua app:
A partire dalla versione
4.6.0, la firma del wallet nativa con WalletConnect è distribuita come add-on opzionale separato, me.didit:didit-sdk-wallet.
Il bundle completo me.didit:didit-sdk lo include già, quindi se installi il bundle non cambia nulla.
Se usi uno degli artefatti più leggeri e vuoi che la conferma della proprietà del wallet avvenga in modo nativo all’interno della tua app, aggiungi me.didit:didit-sdk-wallet accanto ad esso; senza l’add-on, l’SDK completa la verifica della proprietà del wallet tramite un flusso sicuro nel browser, quindi la funzionalità continua a funzionare in entrambi i casi.
Spostare WalletConnect fuori da didit-sdk-core ha inoltre eliminato diversi megabyte di dipendenze dei wallet da ogni build che non ne ha bisogno.
Tutti gli artefatti sono pubblicati con la stessa versione, quindi mantienili alla versione 4.13.2.
Come mantenere piccolo il download
I modelli di rilevamento usati per la cattura automatica vengono scaricati a runtime e memorizzati nella cache, quindi non incidono mai sulla dimensione della tua app. Ciò che la cattura automatica aggiunge alla tua app è la libreria nativa del runtime ML, e questo costo dipende dall’architettura della CPU: circa 10 MB perarm64-v8a, 7 MB per armeabi-v7a e 13 MB per ciascuna delle due architetture x86 degli emulatori.
Per pagare questo costo una sola volta:
- Pubblica un Android App Bundle (AAB). Google Play distribuisce solo l’architettura e le lingue del dispositivo, quindi un telefono arm64 installa circa 10 MB di codice nativo (circa 4 MB di download compresso). Un APK universale invece include tutte e quattro le architetture, oltre 40 MB, che è la causa più comune di misurazioni di dimensione inaspettatamente elevate.
-
Se distribuisci un singolo APK e il tuo pubblico usa telefoni e tablet ARM, limita le architetture incluse:
Mantieni tutti gli ABI che i tuoi utenti usano davvero: aggiungi
x86_64se punti a Chromebook o altri dispositivi x86, oppure pubblica split APK per ABI in modo che nessun dispositivo perda il supporto. -
Abilita R8: imposta
isMinifyEnabled = trueeisShrinkResources = truenel tipo di build di release (minifyEnabled true/shrinkResources truese usibuild.gradlein Groovy). L’SDK include le proprie regole consumer, quindi il codice dell’SDK non utilizzato viene rimosso senza alcuna configurazione aggiuntiva. -
Limita le lingue incluse con
resConfigs(...)se non ti servono tutte le 48 lingue dell’SDK in una build APK; gli split per lingua dell’AAB lo gestiscono automaticamente su Google Play.
Passaggio 3: aggiungi l’esclusione del packaging
Aggiungi questo al bloccoandroid della tua app per evitare conflitti di build:
Permessi
L’SDK richiede i seguenti permessi. Sono dichiarati nel fileAndroidManifest.xml dell’SDK e verranno uniti automaticamente al manifest della tua app:
Funzionalità di fotocamera e NFC
L’SDK dichiaraandroid.hardware.camera e android.hardware.nfc come funzionalità opzionali (android:required="false"). In questo modo la tua app può essere installata su dispositivi senza fotocamera o hardware NFC: l’SDK gestisce correttamente l’assenza dell’hardware durante l’esecuzione.
Avvio rapido
Passaggio 1: inizializza l’SDK
Inizializza l’SDK inApplication.onCreate():
Passaggio 2: avvia la verifica e gestisci i risultati
Metodi di integrazione
L’SDK supporta due metodi di integrazione:Metodo 1: UniLink (il più semplice)
Non richiede un backend. L’SDK crea la sessione direttamente usando l’ID del tuo workflow dalla Didit Console. È limitato al solovendorData.
Metodo 2: sessione backend (consigliato per la produzione)
Il tuo backend crea la sessione tramite l’API per la creazione della sessione di verifica (POST /v3/session/), con supporto completo dei parametri (contact_details, expected_details, metadata, callback e altri), quindi passa il session_token all’SDK.
- Associazione delle sessioni ai tuoi utenti (
vendor_data) - Impostazione di metadati personalizzati
- Configurazione dei callback per sessione
- Fornitura dei dettagli di contatto e dei dettagli attesi per la validazione incrociata
Configurazione
Personalizza il comportamento dell’SDK:Opzioni di configurazione
Opzioni della fotocamera
Le opzioni della fotocamera corrispondono alle opzioni della fotocamera del Web SDK. Ogni obiettivo èCameraLens.FRONT o CameraLens.BACK.
Se il dispositivo non dispone dell’obiettivo richiesto, l’SDK usa la prima fotocamera disponibile.
Anche il pulsante per cambiare fotocamera è nascosto sui dispositivi che hanno una sola fotocamera.
Imposta un’opzione del selettore su false per bloccare l’utente sull’obiettivo predefinito di quel passaggio.
Le opzioni
showLanguageSelector, showCloseButton, showExitConfirmation e closeOnComplete corrispondono a DiditSdkConfiguration del Web SDK. Le opzioni specifiche per dispositivi mobili languageLocale e fontFamily esistono perché l’SDK mobile visualizza l’intera interfaccia di verifica in modo nativo (a differenza del Web SDK, che delega al frontend ospitato all’interno di un iframe).Tema e colori: colori, sfondi e impostazioni della schermata introduttiva si configurano tramite le tue impostazioni White label nella Didit Console, non nella configurazione dell’SDK. Così il branding resta coerente su tutte le piattaforme.
Supporto linguistico
L’SDK supporta 54 lingue. Se non viene specificata alcuna lingua, l’SDK usa la lingua del dispositivo, con l’inglese come lingua di riserva.Opzioni avanzate
Per i parametri avanzati della sessione (contact_details, expected_details, metadata, callback), usa il metodo Sessione backend. Il tuo backend chiama l’API per la creazione della sessione di verifica con tutti i parametri, quindi passa il session_token all’SDK.
Gestione dei risultati
La classe sealedVerificationResult fornisce l’esito della verifica:
Casi del risultato
Proprietà di SessionData
Tipi di errore
Tutti gli errori sono sottoclassi sealed dime.didit.sdk.VerificationError:
Connessione persa
Se il dispositivo perde la connessione durante la verifica, l’SDK copre il flusso con una schermata “Nessuna connessione a Internet” invece di lasciare un passaggio in caricamento. Continua a verificare in background e chiude la schermata da sola non appena Didit torna raggiungibile; l’utente prosegue dal passaggio in cui si trovava. La schermata offre Riprova e, quandoshowCloseButton è true (il valore predefinito), Esci dalla verifica.
Uscendo, la verifica termina con VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), così la tua app sa che l’utente è uscito a causa della connessione.
Esempio completo di gestione del risultato
Osservare lo stato dell’SDK
Puoi osservare lo stato dell’SDK per creare un’interfaccia di caricamento personalizzata:ProGuard / R8
L’SDK include le proprie regole ProGuard consumer. Non è necessaria alcuna configurazione aggiuntiva. Se usi la modalità completa di R8, potresti dover aggiungere questo al tuogradle.properties:
Esempio end-to-end (sessione lato backend → SDK Android → risultato)
Questo schema è l’integrazione pronta per la produzione. Il tuo backend crea la sessione, la tua app Android riceve ilsession_token e l’SDK esegue il flusso.