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 demrepositories-Block in Ihrer settings.gradle.kts hinzu:
settings.gradle (Groovy) verwenden:
Schritt 2: Abhängigkeit hinzufügen
Fügen Sie die SDK-Abhängigkeit in derbuild.gradle.kts Ihrer App hinzu:
(!) Prüfen Sie bei der Version im GitHub-Repository die aktuelle Version.
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ürarm64-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:
- 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.
-
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_64hinzu, 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. -
R8 aktivieren:
isMinifyEnabled = trueundisShrinkResources = trueim Release-Build-Typ (minifyEnabled true/shrinkResources true, wenn Sie das Groovy-build.gradleverwenden). Das SDK bringt eigene Consumer-Regeln mit, daher wird nicht verwendeter SDK-Code ohne zusätzliche Konfiguration entfernt. -
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 demandroid-Block Ihrer App hinzu, um Build-Konflikte zu vermeiden:
Berechtigungen
Das SDK benötigt die folgenden Berechtigungen. Sie sind in derAndroidManifest.xml des SDK deklariert und werden automatisch in das Manifest Ihrer App übernommen:
Kamera- und NFC-Funktionen
Das SDK deklariertandroid.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 IhrerApplication.onCreate():
Schritt 2: Verifizierung starten und Ergebnisse verarbeiten
Integrationsmethoden
Das SDK unterstützt zwei Integrationsmethoden:Methode 1: UniLink (am einfachsten)
Kein Backend erforderlich. Das SDK erstellt die Sitzung direkt anhand der Workflow-ID aus der Didit Console. Beschränkt aufvendorData.
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.
- 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 istCameraLens.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.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-KlasseVerificationResult liefert das Ergebnis der Verifizierung:
Ergebnisfälle
Eigenschaften von SessionData
Fehlertypen
Alle Fehler sind Sealed-Unterklassen vonme.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, wennshowCloseButton 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 Ihregradle.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 densession_token, und das SDK führt den Ablauf aus.