Repositorio de GitHub
Consulta el código fuente y los ejemplos en GitHub
SDK nativo: Este es el enfoque recomendado para apps de Android. Los SDK nativos ofrecen la mejor experiencia de usuario, un manejo optimizado de la cámara y compatibilidad completa con NFC.
Requisitos
Disponibilidad de funciones según el nivel de API: La detección automática de documentos y rostros requiere API 24+ (con el runtime de ML incluido o con el runtime de Google Play services; consulta las variantes del SDK). En dispositivos con API 23, el SDK recurre a la captura manual con un botón de captura temporizado. Todas las demás funciones están disponibles en todo el rango de API 23+.
El consentimiento biométrico requiere la versión nativa 4.10.0 o posterior. Para las personas amparadas por las leyes de Illinois, Texas o Colorado, Didit puede solicitar un consentimiento biométrico explícito antes de la primera captura facial. El SDK de Android 4.10.0 y posteriores muestran ese paso. Las versiones anteriores no pueden mostrarlo: sus sesiones se ejecutan como hasta ahora y la decisión indica que el consentimiento no se recopiló (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Actualiza el SDK si verificas a personas de esos estados.Instalación
Paso 1: Añade el repositorio
Añade el repositorio Maven de Didit al bloquerepositories de tu settings.gradle.kts:
settings.gradle (Groovy):
Paso 2: Añade la dependencia
Añade la dependencia del SDK albuild.gradle.kts de tu app:
(!) En cuanto a la versión, asegúrate de consultar el repositorio de GitHub para conocer la versión más reciente.
build.gradle (Groovy):
Variantes del SDK
El SDK de Android se distribuye como cinco artefactos independientes, de modo que tu app solo asume el coste en tamaño binario de las funciones que utiliza.me.didit:didit-sdk, el de arriba, es el paquete completo. Elige exactamente uno, con una única
excepción: los dos artefactos de detección automática pueden instalarse juntos, como se describe más abajo:
Runtime de ML más ligero mediante Google Play services (opcional, desde 4.7.0)
me.didit:didit-sdk-autodetection-play ofrece la misma captura automática de documentos y rostros que
didit-sdk-autodetection, pero ejecuta la inferencia en el runtime de ML que Google Play services ya
proporciona en el dispositivo, en lugar de incluir uno en tu APK.
El comportamiento de la detección es idéntico (ambos motores se compararon fotograma a fotograma entre sí
en una matriz de dispositivos físicos antes del lanzamiento) y la inferencia suele ser más rápida con el runtime de Play.
Para activarlo, sustituye el artefacto:
- Tamaño: unos 9.85 MB menos de código nativo instalado por dispositivo (arm64), porque el runtime de ML ya no está dentro de tu app. (Una comparación con un APK universal sin minificar y con 4 ABI muestra una diferencia mayor, de ~43 MB, pero esa cifra cuenta varias veces arquitecturas que ningún dispositivo instala a la vez; la cifra por dispositivo indicada arriba es la que realmente perciben tus usuarios).
- Requisito: Google Play services. En dispositivos que no lo tienen (por ejemplo, dispositivos Huawei
sin GMS), o si el runtime de Play no se inicializa, el SDK recurre automáticamente a una alternativa:
al runtime incluido cuando también está instalado
didit-sdk-autodetection, o a la captura manual en caso contrario. Nunca falla porque un runtime no esté disponible. - Elección de cobertura: distribuye solo
-playpara conseguir la app más pequeña (los usuarios sin GMS tendrán captura manual), o distribuye ambos artefactos para mantener la captura automática con ML en dispositivos sin GMS con el tamaño original.
didit-sdk-core 4.7.0 o posterior.
didit-sdk-autodetection-play es opcional por ahora. Didit hace seguimiento de su rendimiento en producción frente
al runtime incluido durante un ciclo de versiones tras su lanzamiento; cuando esos datos confirmen la paridad, se prevé que el
artefacto de Play pase a ser la forma recomendada de instalar la detección automática, y
didit-sdk-autodetection (incluido) sigue siendo la recomendación predeterminada hasta entonces.4.6.0, la firma nativa con wallets mediante WalletConnect se distribuye como un complemento opcional propio, me.didit:didit-sdk-wallet.
El paquete completo me.didit:didit-sdk ya lo incluye, así que no cambia nada si instalas el paquete completo.
Si usas uno de los artefactos más ligeros y quieres que la confirmación de propiedad de la wallet se ejecute de forma nativa dentro de tu app, añade me.didit:didit-sdk-wallet junto a él; sin el complemento, el SDK completa la confirmación de propiedad de la wallet mediante un flujo seguro en el navegador, así que la función sigue funcionando en ambos casos.
Sacar WalletConnect de didit-sdk-core también eliminó varios megabytes de dependencias de wallet de todas las compilaciones que no las necesitan.
Todos los artefactos se publican con la misma versión, así que mantenlos en 4.9.1.
Cómo mantener reducido el tamaño de descarga
Los modelos de detección que usa la captura automática se descargan en tiempo de ejecución y se almacenan en caché, por lo que nunca cuentan para el tamaño de tu app. Lo que la captura automática añade a tu app es la biblioteca nativa del runtime de ML, y ese coste es por arquitectura de CPU: aproximadamente 10 MB paraarm64-v8a, 7 MB para armeabi-v7a y 13 MB para cada una de las dos arquitecturas x86 de emulador.
Para asumir ese coste una sola vez:
- Publica un Android App Bundle (AAB). Google Play entrega solo la arquitectura y los idiomas propios del dispositivo, así que un teléfono arm64 instala unos 10 MB de código nativo (unos 4 MB de descarga comprimida). En cambio, un APK universal empaqueta las cuatro arquitecturas (más de 40 MB), que es la causa más habitual de mediciones de tamaño inesperadamente grandes.
-
Si distribuyes un único APK y tu público usa teléfonos y tabletas ARM, restringe las arquitecturas incluidas:
Conserva todas las ABI que realmente usan tus usuarios: añade
x86_64si te diriges a Chromebooks u otros dispositivos x86, o publica APK divididos por ABI para que ningún dispositivo pierda compatibilidad. -
Activa R8:
isMinifyEnabled = trueeisShrinkResources = trueen tu tipo de compilación de release (minifyEnabled true/shrinkResources truesi usasbuild.gradleen Groovy). El SDK incluye sus propias reglas de consumidor, por lo que el código del SDK que no se usa se elimina sin configuración adicional. -
Limita los idiomas incluidos con
resConfigs(...)si no necesitas las 48 configuraciones regionales del SDK en una compilación APK; en Google Play, la división por idioma de los AAB se encarga de esto automáticamente.
Paso 3: Añade la exclusión de empaquetado
Añade esto al bloqueandroid de tu app para evitar conflictos de compilación:
Permisos
El SDK requiere los siguientes permisos. Están declarados en elAndroidManifest.xml del SDK y se fusionarán automáticamente en el manifiesto de tu aplicación:
Características de cámara y NFC
El SDK declaraandroid.hardware.camera y android.hardware.nfc como características opcionales (android:required="false"). Así tu aplicación puede instalarse en dispositivos sin cámara o sin hardware NFC, y el SDK gestionará correctamente la ausencia de hardware en tiempo de ejecución.
Inicio rápido
Paso 1: Inicializa el SDK
Inicializa el SDK en elApplication.onCreate() de tu aplicación:
Paso 2: Inicia la verificación y gestiona los resultados
Métodos de integración
El SDK admite dos métodos de integración:Método 1: UniLink (el más sencillo)
No requiere backend. El SDK crea la sesión directamente con el ID de tu flujo de verificación (workflow) de Didit Console. Solo admitevendorData.
Método 2: Sesión desde el backend (recomendado para producción)
Tu backend crea la sesión mediante la API de creación de sesiones de verificación (POST /v3/session/) con soporte completo de parámetros (contact_details, expected_details, metadata, callback, etc.) y después pasa el session_token al SDK.
- Asociar sesiones con tus usuarios (
vendor_data) - Definir metadatos personalizados
- Configurar callbacks por sesión
- Proporcionar datos de contacto y datos esperados para la validación cruzada
Configuración
Personaliza el comportamiento del SDK:Opciones de configuración
Opciones de cámara
Las opciones de cámara coinciden con las opciones de cámara del Web SDK. Cada lente esCameraLens.FRONT o CameraLens.BACK.
Si el dispositivo no tiene la lente solicitada, el SDK usa la primera cámara disponible.
El selector de cámara también se oculta en los dispositivos que solo tienen una cámara.
Establece una opción del selector en false para restringir al usuario a la lente predeterminada de ese paso.
Las opciones
showLanguageSelector, showCloseButton, showExitConfirmation y closeOnComplete coinciden con la DiditSdkConfiguration del Web SDK. Las opciones exclusivas de móvil languageLocale y fontFamily existen porque el SDK móvil renderiza de forma nativa toda la interfaz de verificación (a diferencia del Web SDK, que delega en el frontend alojado dentro de un iframe).Temas y colores: los colores, los fondos y la configuración de la pantalla de introducción se definen en la configuración de marca blanca de Didit Console, no en la configuración del SDK. Así se garantiza una imagen de marca coherente en todas las plataformas.
Idiomas compatibles
El SDK admite 54 idiomas. Si no se especifica ningún idioma, el SDK usa la configuración regional del dispositivo, con el inglés como idioma alternativo.Opciones avanzadas
Para los parámetros avanzados de sesión (contact_details, expected_details, metadata, callback), usa el método Backend Session. Tu backend invoca la API de creación de sesiones de verificación con todos los parámetros y después pasa el session_token al SDK.
Gestión de resultados
La clase selladaVerificationResult proporciona el resultado de la verificación:
Casos de resultado
Propiedades de SessionData
Tipos de error
Todos los errores son subclases selladas deme.didit.sdk.VerificationError:
Pérdida de conexión
Si el dispositivo pierde la conexión durante la verificación, el SDK muestra una pantalla de “Sin conexión a internet” en lugar de dejar un paso en estado de carga. Sigue comprobando en segundo plano y cierra la pantalla por sí solo en cuanto Didit vuelve a estar disponible, y el usuario continúa desde el paso en el que estaba. La pantalla ofrece Intentar de nuevo y, cuandoshowCloseButton es true (el valor predeterminado), Salir de la verificación.
Al salir, la verificación termina con VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), de modo que tu aplicación sabe que el usuario salió debido a un problema de conexión.
Ejemplo completo de gestión de resultados
Observación del estado del SDK
Puedes observar el estado del SDK para crear una interfaz de carga personalizada:ProGuard / R8
El SDK incluye sus propias reglas de ProGuard de consumidor. No se necesita ninguna configuración adicional. Si usas el modo completo de R8, es posible que tengas que añadir esto a tugradle.properties:
Ejemplo de principio a fin (sesión en el backend → SDK de Android → resultado)
Este patrón es la integración lista para producción. Tu backend crea la sesión, tu aplicación Android recibe elsession_token y el SDK ejecuta el flujo.