Passer au contenu principal
Un SDK Android léger et piloté par le serveur pour la vérification d’identité, avec une configuration minimale.

Dépôt GitHub

Consultez le code source et les exemples sur GitHub

SDK natif: Il s’agit de l’approche recommandée pour les applications Android. Les SDK natifs offrent la meilleure expérience utilisateur, une gestion optimisée de la caméra et une prise en charge complète du NFC.


Prérequis

Disponibilité des fonctionnalités par niveau d’API : L’autodétection de documents et de visages nécessite l’API 24+ (les détecteurs légers propres à Didit, inclus dans didit-sdk-core). Sur les appareils dotés de l’API 23, le SDK bascule sur une capture manuelle avec un bouton de déclenchement temporisé. Toutes les autres fonctionnalités fonctionnent sur l’ensemble de la plage d’API 23+.
Le consentement biométrique nécessite la version native 4.10.0 ou ultérieure. Pour les personnes couvertes par les lois de l’Illinois, du Texas ou du Colorado, Didit peut demander un consentement biométrique explicite avant la première capture de visage. Le SDK Android 4.10.0 et versions ultérieures affichent cette étape. Les versions antérieures ne peuvent pas afficher l’étape : leurs sessions se déroulent comme auparavant, et la décision indique que le consentement n’a pas été collecté (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Mettez à niveau si vous vérifiez des personnes dans ces États.

Installation

Étape 1 : Ajouter le dépôt

Ajoutez le dépôt Maven de Didit au bloc repositories de votre fichier settings.gradle.kts :
Si vous utilisez settings.gradle (Groovy) :

Étape 2 : Ajouter la dépendance

Ajoutez la dépendance du SDK au fichier build.gradle.kts de votre application : (!) Concernant la version, vérifiez la dernière version sur le dépôt GitHub.
Si vous utilisez build.gradle (Groovy) :

Variantes du SDK

Le SDK Android est distribué sous forme d’artefacts distincts, de sorte que votre application n’inclut que la taille binaire des fonctionnalités qu’elle utilise. me.didit:didit-sdk ci-dessus est le bundle complet. Choisissez celui qui convient à votre application : Depuis la 4.6.0, la signature de portefeuille native via WalletConnect est proposée sous forme de module complémentaire optionnel distinct, me.didit:didit-sdk-wallet. Le bundle complet me.didit:didit-sdk l’inclut déjà, donc rien ne change si vous installez le bundle. Si vous utilisez l’un des artefacts plus légers et souhaitez que la confirmation de propriété du portefeuille soit effectuée nativement dans votre application, ajoutez me.didit:didit-sdk-wallet à côté ; sans ce module complémentaire, le SDK effectue la confirmation de propriété via un parcours sécurisé dans le navigateur, de sorte que la fonctionnalité continue de fonctionner dans les deux cas. Le déplacement de WalletConnect hors de didit-sdk-core a également retiré plusieurs mégaoctets de dépendances de portefeuille de chaque build qui n’en a pas besoin. Tous les artefacts sont publiés dans la même version, gardez-les donc sur 4.13.2.

Réduire la taille du téléchargement

Les modèles de détection utilisés pour la capture automatique sont téléchargés à l’exécution puis mis en cache, de sorte qu’ils ne comptent jamais dans la taille de votre application. Ce qu’ajoute la capture automatique à votre application, c’est la bibliothèque native du runtime ML, et ce coût dépend de l’architecture CPU : environ 10 Mo pour arm64-v8a, 7 Mo pour armeabi-v7a, et 13 Mo pour chacune des deux architectures x86 des émulateurs. Pour ne payer ce coût qu’une seule fois :
  1. Publiez un Android App Bundle (AAB). Google Play ne livre que l’architecture et les langues propres à l’appareil, donc un téléphone arm64 installe environ 10 Mo de code natif (environ 4 Mo de téléchargement compressé). Un APK universel, en revanche, regroupe les quatre architectures, soit plus de 40 Mo, ce qui est la cause la plus courante de mesures de taille anormalement élevées.
  2. Si vous distribuez un APK unique et que votre public utilise des téléphones et tablettes ARM, limitez les architectures embarquées :
    Conservez toutes les ABI que vos utilisateurs utilisent réellement : ajoutez x86_64 si vous ciblez les Chromebooks ou d’autres appareils x86, ou publiez des APK distincts par ABI afin que tous les appareils restent pris en charge.
  3. Activez R8 : isMinifyEnabled = true et isShrinkResources = true dans le type de build de publication (minifyEnabled true / shrinkResources true si vous utilisez le build.gradle Groovy). Le SDK fournit ses propres règles de consommation, donc le code inutilisé du SDK est supprimé sans configuration supplémentaire.
  4. Limitez les langues embarquées avec resConfigs(...) si vous n’avez pas besoin des 48 paramètres régionaux du SDK dans un build APK ; les divisions de langues des AAB le font automatiquement sur Google Play.

Étape 3 : Ajouter l’exclusion lors du packaging

Ajoutez ceci au bloc android de votre application pour éviter les conflits de build :
Et voilà ! Gradle résout automatiquement toutes les dépendances transitives.

Autorisations

Le SDK requiert les autorisations suivantes. Celles-ci sont déclarées dans le fichier AndroidManifest.xml du SDK et seront automatiquement fusionnées dans le manifeste de votre application :

Fonctionnalités Appareil photo et NFC

Le SDK déclare android.hardware.camera et android.hardware.nfc comme fonctionnalités facultatives (android:required="false"). Cela garantit que votre application peut être installée sur des appareils dépourvus d’appareil photo ou de matériel NFC — le SDK gérera de manière fluide l’absence de matériel au moment de l’exécution.

Démarrage rapide

Étape 1 : Initialiser le SDK

Initialisez le SDK dans la méthode Application.onCreate() :

Étape 2 : Démarrer la vérification et traiter les résultats


Méthodes d’intégration

Le SDK prend en charge deux méthodes d’intégration : Aucun backend requis. Le SDK crée directement la session en utilisant votre identifiant de workflow depuis la Console Didit. Limité uniquement à vendorData.

Méthode 2 : Session backend (recommandée pour la production)

Votre backend crée la session via l’API Create Verification Session (POST /v3/session/) avec la prise en charge complète des paramètres (contact_details, expected_details, metadata, callback, etc.), puis transmet le session_token au SDK.
Cette approche vous donne un contrôle total sur :
  • L’association des sessions à vos utilisateurs (vendor_data)
  • La définition de métadonnées personnalisées
  • La configuration des rappels par session
  • La transmission des coordonnées et des informations attendues pour la validation croisée

Configuration

Personnalisez le comportement du SDK :

Options de configuration

Options de l’appareil photo

Les options de l’appareil photo correspondent aux options de l’appareil photo du Web SDK. Chaque objectif est CameraLens.FRONT ou CameraLens.BACK. Si l’appareil ne dispose pas de l’objectif demandé, le SDK utilise le premier appareil photo disponible. Le sélecteur d’appareil photo est également masqué sur les appareils qui ne possèdent qu’un seul appareil photo. Définissez une option de sélecteur sur false pour imposer à l’utilisateur l’objectif par défaut de cette étape.
Les options showLanguageSelector, showCloseButton, showExitConfirmation et closeOnComplete correspondent au DiditSdkConfiguration du Web SDK. Les options spécifiques au mobile languageLocale et fontFamily existent parce que le SDK mobile affiche l’intégralité de l’interface de vérification de manière native (contrairement au Web SDK qui délègue au frontend hébergé dans une iframe).
Thème et couleurs : les couleurs, les arrière-plans et les paramètres de l’écran d’introduction sont configurés par le biais de vos paramètres de marque blanche dans la Console Didit, et non dans la configuration du SDK. Cela garantit une image de marque cohérente sur toutes les plateformes.

Prise en charge des langues

Le SDK prend en charge 54 langues. Si aucune langue n’est spécifiée, le SDK utilise les paramètres régionaux de l’appareil avec l’anglais comme langue de secours.
Voir toutes les langues prises en charge →

Options avancées

Pour les paramètres de session avancés (contact_details, expected_details, metadata, callback), utilisez la méthode de session via le backend. Votre backend appelle l’API Create Verification Session avec l’ensemble des paramètres, puis transmet le session_token au SDK.

Traitement des résultats

La classe scellée VerificationResult fournit le résultat de la vérification :

Cas de résultats

Propriétés de SessionData

Types d’erreurs

Toutes les erreurs sont des sous-classes scellées de me.didit.sdk.VerificationError :

Perte de connexion

Si l’appareil perd sa connexion pendant la vérification, le SDK affiche un écran « Pas de connexion Internet » par-dessus le flux au lieu de laisser une étape en chargement. Il continue de vérifier en arrière-plan et ferme automatiquement cet écran dès que Didit est de nouveau accessible, permettant à l’utilisateur de reprendre à l’étape où il s’était arrêté. L’écran propose Réessayer et, lorsque showCloseButton est true (valeur par défaut), Quitter la vérification. Quitter met fin à la vérification avec VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), afin que votre application sache que l’utilisateur est parti à cause de la connexion.

Exemple complet de traitement des résultats


Observer l’état du SDK

Vous pouvez observer l’état du SDK pour afficher une interface de chargement personnalisée :

ProGuard / R8

Le SDK inclut ses propres règles ProGuard destinées aux consommateurs. Aucune configuration supplémentaire n’est requise. Si vous utilisez le mode complet de R8, vous devrez peut-être ajouter ceci à votre gradle.properties :

Exemple de bout en bout (Session backend → SDK Android → Résultat)

Ce modèle constitue l’intégration prête pour la production. Votre backend crée la session, votre application Android reçoit le session_token, et le SDK exécute le workflow.

1. Backend — créer la session

2. Android — échanger et démarrer le SDK

3. Backend — recevoir la décision finale par webhook

Le résultat du SDK est pratique pour le retour visuel dans l’interface, mais la décision faisant foi arrive par webhook. Consultez le guide des webhooks pour la vérification HMAC.

Exemple complet


Dernière modification le 7 novembre 2026