Saltar al contenido principal
Un SDK de Android ligero y controlado desde el servidor para la verificación de identidad, que requiere una configuración mínima.

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 bloque repositories de tu settings.gradle.kts:
O, si usas settings.gradle (Groovy):

Paso 2: Añade la dependencia

Añade la dependencia del SDK al build.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.
O, si usas 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:
Qué cambia:
  • 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 -play para 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.
Ambos artefactos requieren 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.
Desde 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 para arm64-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:
  1. 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.
  2. 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_64 si te diriges a Chromebooks u otros dispositivos x86, o publica APK divididos por ABI para que ningún dispositivo pierda compatibilidad.
  3. Activa R8: isMinifyEnabled = true e isShrinkResources = true en tu tipo de compilación de release (minifyEnabled true / shrinkResources true si usas build.gradle en 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.
  4. 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 bloque android de tu app para evitar conflictos de compilación:
¡Listo! Gradle resolverá automáticamente todas las dependencias transitivas.

Permisos

El SDK requiere los siguientes permisos. Están declarados en el AndroidManifest.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 declara android.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 el Application.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: No requiere backend. El SDK crea la sesión directamente con el ID de tu flujo de verificación (workflow) de Didit Console. Solo admite vendorData.

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.
Este enfoque te da control total para:
  • 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 es CameraLens.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.
Ver todos los idiomas compatibles →

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 sellada VerificationResult proporciona el resultado de la verificación:

Casos de resultado

Propiedades de SessionData

Tipos de error

Todos los errores son subclases selladas de me.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, cuando showCloseButton 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 tu gradle.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 el session_token y el SDK ejecuta el flujo.

1. Backend: crear la sesión

2. Android: intercambiar el token e iniciar el SDK

3. Backend: recibir la decisión final mediante webhook

El resultado del SDK resulta práctico para dar feedback en la interfaz, pero el resultado que prevalece llega mediante webhook. Consulta la guía de webhooks para la verificación HMAC.

Ejemplo completo


Última modificación el 1 de noviembre de 2026