Zum Hauptinhalt springen
Ein leichtgewichtiges, serverseitig gesteuertes Android SDK für Identitätsverifizierung mit minimalem Konfigurationsaufwand.

GitHub-Repository

Quellcode und Beispiele auf GitHub ansehen

Native SDK: Dies ist der empfohlene Ansatz für Android-Apps. Native SDKs bieten das beste Nutzererlebnis, eine optimierte Kamerasteuerung und volle NFC-Unterstützung.


Anforderungen

Funktionsverfügbarkeit nach API-Level: Die automatische Erkennung von Dokumenten und Gesichtern erfordert API 24+ (eigene schlanke Detektoren von Didit, enthalten in didit-sdk-core). Auf Geräten mit API 23 greift das SDK auf die manuelle Aufnahme mit einer zeitgesteuerten Auslösetaste zurück. Alle anderen Funktionen funktionieren im gesamten Bereich ab API 23+.
Die biometrische Einwilligung erfordert natives SDK 4.10.0 oder neuer. Für Personen, die den Gesetzen von Illinois, Texas oder Colorado unterliegen, kann Didit vor der ersten Gesichtsaufnahme eine ausdrückliche biometrische Einwilligung einholen. Das Android SDK ab Version 4.10.0 zeigt diesen Schritt an. Frühere Versionen können ihn nicht anzeigen: Ihre Sitzungen laufen wie bisher weiter, und die Entscheidung meldet die Einwilligung als nicht erfasst (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Aktualisieren Sie das SDK, wenn Sie Personen in diesen Bundesstaaten verifizieren.

Installation

Schritt 1: Repository hinzufügen

Fügen Sie das Didit-Maven-Repository dem repositories-Block in Ihrer settings.gradle.kts hinzu:
Oder falls Sie settings.gradle (Groovy) verwenden:

Schritt 2: Abhängigkeit hinzufügen

Fügen Sie die SDK-Abhängigkeit in der build.gradle.kts Ihrer App hinzu: (!) Prüfen Sie bei der Version im GitHub-Repository die aktuelle Version.
Oder falls Sie build.gradle (Groovy) verwenden:

SDK-Varianten

Das Android SDK wird als separate Artefakte bereitgestellt, sodass Ihre App nur die Binärgröße der Funktionen enthält, die sie tatsächlich nutzt. me.didit:didit-sdk oben ist das vollständige Bundle. Wählen Sie die Variante, die zu Ihrer App passt: Seit 4.6.0 wird die native WalletConnect-Wallet-Signierung als eigenes optionales Add-on ausgeliefert, me.didit:didit-sdk-wallet. Das vollständige Bundle me.didit:didit-sdk enthält es bereits, daher ändert sich nichts, wenn Sie das Bundle installieren. Wenn Sie eine der schlankeren Varianten verwenden und die Bestätigung der Wallet-Inhaberschaft nativ in Ihrer App ausführen lassen möchten, fügen Sie me.didit:didit-sdk-wallet daneben hinzu. Ohne dieses Add-on schließt das SDK die Wallet-Inhaberschaft über einen sicheren Browser-Ablauf ab, sodass die Funktion in beiden Fällen weiterhin funktioniert. Das Auslagern von WalletConnect aus didit-sdk-core hat außerdem mehrere Megabyte an Wallet-Abhängigkeiten aus allen Builds entfernt, die diese nicht benötigen. Alle Artefakte werden in derselben Version veröffentlicht. Verwenden Sie daher überall 4.13.2.

Download-Größe gering halten

Die Erkennungsmodelle für die automatische Aufnahme werden zur Laufzeit heruntergeladen und zwischengespeichert, sodass sie die Größe Ihrer App nie erhöhen. Die automatische Aufnahme fügt Ihrer App jedoch die native Bibliothek der ML-Laufzeit hinzu. Diese Kosten richten sich nach der CPU-Architektur: etwa 10 MB für arm64-v8a, 7 MB für armeabi-v7a und 13 MB für jede der beiden x86-Emulator-Architekturen. Um diese Kosten nur einmal zu tragen:
  1. Veröffentlichen Sie ein Android App Bundle (AAB). Google Play liefert nur die Architektur und Sprachen des jeweiligen Geräts aus. Ein arm64-Smartphone installiert damit etwa 10 MB nativen Code (rund 4 MB als komprimierter Download). Ein universelles APK packt dagegen alle vier Architekturen und ist über 40 MB groß, und das ist die häufigste Ursache für unerwartet große Größenangaben.
  2. Wenn Sie ein einzelnes APK verteilen und Ihre Zielgruppe ARM-Smartphones und -Tablets nutzt, beschränken Sie die gebündelten Architekturen:
    Behalten Sie jede ABI bei, die Ihre Nutzer tatsächlich verwenden: Fügen Sie x86_64 hinzu, wenn Sie Chromebooks oder andere x86-Geräte ansprechen, oder veröffentlichen Sie ABI-spezifische APK-Splits, damit kein Gerät die Unterstützung verliert.
  3. R8 aktivieren: isMinifyEnabled = true und isShrinkResources = true im Release-Build-Typ (minifyEnabled true / shrinkResources true, wenn Sie das Groovy-build.gradle verwenden). Das SDK bringt eigene Consumer-Regeln mit, daher wird nicht verwendeter SDK-Code ohne zusätzliche Konfiguration entfernt.
  4. Gebündelte Sprachen begrenzen mit resConfigs(...), wenn Sie in einem APK-Build nicht alle 48 SDK-Locales benötigen. AAB-Sprachsplits übernehmen dies bei Google Play automatisch.

Schritt 3: Packaging-Ausschluss hinzufügen

Fügen Sie dies dem android-Block Ihrer App hinzu, um Build-Konflikte zu vermeiden:
Das war’s! Gradle löst alle transitiven Abhängigkeiten automatisch auf.

Berechtigungen

Das SDK benötigt die folgenden Berechtigungen. Sie sind in der AndroidManifest.xml des SDK deklariert und werden automatisch in das Manifest Ihrer App übernommen:

Kamera- und NFC-Funktionen

Das SDK deklariert android.hardware.camera und android.hardware.nfc als optionale Funktionen (android:required="false"). So lässt sich Ihre App auch auf Geräten ohne Kamera oder NFC-Hardware installieren. Das SDK behandelt fehlende Hardware zur Laufzeit ordnungsgemäß.

Schnellstart

Schritt 1: SDK initialisieren

Initialisieren Sie das SDK in Ihrer Application.onCreate():

Schritt 2: Verifizierung starten und Ergebnisse verarbeiten


Integrationsmethoden

Das SDK unterstützt zwei Integrationsmethoden: Kein Backend erforderlich. Das SDK erstellt die Sitzung direkt anhand der Workflow-ID aus der Didit Console. Beschränkt auf vendorData.

Methode 2: Backend-Sitzung (empfohlen für die Produktion)

Ihr Backend erstellt die Sitzung über die API zum Erstellen einer Verifizierungssitzung (POST /v3/session/) mit vollständiger Parameterunterstützung (contact_details, expected_details, metadata, callback usw.) und übergibt anschließend den session_token an das SDK.
Dieser Ansatz gibt Ihnen die volle Kontrolle über:
  • Die Zuordnung von Sitzungen zu Ihren Benutzern (vendor_data)
  • Das Festlegen benutzerdefinierter Metadaten
  • Die Konfiguration von Callbacks pro Sitzung
  • Die Angabe von Kontaktdaten und erwarteten Daten für die Kreuzvalidierung

Konfiguration

Passen Sie das Verhalten des SDK an:

Konfigurationsoptionen

Kameraoptionen

Die Kameraoptionen entsprechen den Kameraoptionen des Web SDK. Jedes Objektiv ist CameraLens.FRONT oder CameraLens.BACK. Wenn das Gerät das angeforderte Objektiv nicht besitzt, verwendet das SDK die erste verfügbare Kamera. Der Kameraumschalter wird auch auf Geräten mit nur einer Kamera ausgeblendet. Setzen Sie eine Umschalter-Option auf false, um den Benutzer auf das Standardobjektiv dieses Schritts festzulegen.
Die Optionen showLanguageSelector, showCloseButton, showExitConfirmation und closeOnComplete entsprechen dem DiditSdkConfiguration des Web SDK. Die mobilspezifischen Optionen languageLocale und fontFamily existieren, weil das mobile SDK die vollständige Verifizierungs-UI nativ rendert (anders als das Web SDK, das die gehostete Frontend-Anwendung innerhalb eines Iframes einbindet).
Theming und Farben: Farben, Hintergründe und Einstellungen des Einstiegsbildschirms werden über Ihre White-Label-Einstellungen in der Didit Console konfiguriert, nicht in der SDK-Konfiguration. So bleibt das Branding auf allen Plattformen einheitlich.

Sprachunterstützung

Das SDK unterstützt 54 Sprachen. Wenn keine Sprache angegeben wird, verwendet das SDK die Locale des Geräts und greift auf Englisch als Ausweichsprache zurück.
Alle unterstützten Sprachen anzeigen →

Erweiterte Optionen

Für erweiterte Sitzungsparameter (contact_details, expected_details, metadata, callback) verwenden Sie die Methode Backend-Sitzung. Ihr Backend ruft die API zum Erstellen einer Verifizierungssitzung mit allen Parametern auf und übergibt anschließend den session_token an das SDK.

Ergebnisse verarbeiten

Die Sealed-Klasse VerificationResult liefert das Ergebnis der Verifizierung:

Ergebnisfälle

Eigenschaften von SessionData

Fehlertypen

Alle Fehler sind Sealed-Unterklassen von me.didit.sdk.VerificationError:

Verbindungsverlust

Verliert das Gerät während der Verifizierung die Verbindung, legt das SDK über den Ablauf einen Bildschirm mit „Keine Internetverbindung“, statt einen Schritt weiterhin laden zu lassen. Im Hintergrund wird die Verbindung weiter geprüft, und sobald Didit wieder erreichbar ist, schließt sich der Bildschirm automatisch. Der Benutzer setzt die Verifizierung bei dem Schritt fort, bei dem er war. Der Bildschirm bietet Try Again und, wenn showCloseButton auf true gesetzt ist (Standardwert), Exit Verification. Beim Beenden wird die Verifizierung mit VerificationResult.Failed(error = VerificationError.NetworkError, session = ...) beendet, sodass Ihre App erkennt, dass der Benutzer die Verifizierung wegen der Verbindungsunterbrechung verlassen hat.

Vollständiges Beispiel zur Ergebnisverarbeitung


Status des SDK beobachten

Den Status des SDK können Sie für eigene Ladeanzeigen beobachten:

ProGuard / R8

Das SDK enthält eigene Consumer-ProGuard-Regeln. Es ist keine zusätzliche Konfiguration nötig. Wenn Sie den R8-Vollmodus verwenden, müssen Sie unter Umständen Folgendes in Ihre gradle.properties aufnehmen:

End-to-End-Beispiel (Backend-Sitzung → Android SDK → Ergebnis)

Dieses Muster ist die produktionsreife Integration. Ihr Backend erstellt die Sitzung, Ihre Android-App empfängt den session_token, und das SDK führt den Ablauf aus.

1. Backend: Sitzung erstellen

2. Android: Token austauschen und SDK starten

3. Backend: Endgültige Entscheidung per Webhook empfangen

Das Ergebnis des SDK eignet sich gut für Rückmeldungen in der Oberfläche, das maßgebliche Ergebnis kommt jedoch per Webhook. Informationen zur HMAC-Prüfung finden Sie im Webhooks-Leitfaden.

Vollständiges Beispiel


Zuletzt geändert am 7. November 2026