Pular para o conteúdo principal
Um SDK Android leve e orientado pelo servidor para verificação de identidade, que exige configuração mínima.

Repositório no GitHub

Veja o código-fonte e exemplos no GitHub

SDK nativo: esta é a abordagem recomendada para apps Android. Os SDKs nativos oferecem a melhor experiência do usuário, gerenciamento otimizado da câmera e suporte completo a NFC.


Requisitos

Disponibilidade de recursos por nível de API: a detecção automática de documento e de rosto exige API 24+ (usando o runtime de ML incluído no SDK ou o runtime do Google Play services; veja as variantes do SDK). Em dispositivos com API 23, o SDK passa para a captura manual, com um botão de disparo temporizado. Todos os outros recursos funcionam em toda a faixa de API 23+.
O consentimento biométrico exige a versão nativa 4.10.0 ou posterior. Para pessoas abrangidas pelas leis de Illinois, Texas ou Colorado, a Didit pode solicitar consentimento biométrico explícito antes da primeira captura do rosto. O SDK Android 4.10.0 e versões posteriores exibem essa etapa. Versões anteriores não conseguem exibir a etapa: suas sessões funcionam como antes, e a decisão informa que o consentimento não foi coletado (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize o SDK se você verifica pessoas nesses estados.

Instalação

Etapa 1: Adicione o repositório

Adicione o repositório Maven da Didit ao bloco repositories do seu settings.gradle.kts:
Ou, se você usa settings.gradle (Groovy):

Etapa 2: Adicione a dependência

Adicione a dependência do SDK ao build.gradle.kts do seu app: (!) Quanto à versão, confira no repositório do GitHub qual é a mais recente.
Ou, se você usa build.gradle (Groovy):

Variantes do SDK

O SDK Android é distribuído como cinco artefatos separados, para que seu app só arque com o custo binário dos recursos que usa. O me.didit:didit-sdk acima é o pacote completo. Escolha exatamente um, com uma única exceção: os dois artefatos de detecção automática podem ser instalados juntos, como descrito abaixo:
Runtime de ML menor via Google Play services (opcional, desde a 4.7.0)
O me.didit:didit-sdk-autodetection-play oferece a mesma captura automática de documentos e de rosto que o didit-sdk-autodetection, mas executa a inferência no runtime de ML que o Google Play services já disponibiliza no dispositivo, em vez de incluir um no seu APK. O comportamento da detecção é idêntico (os dois mecanismos foram comparados quadro a quadro em uma matriz de dispositivos físicos antes do lançamento) e a inferência costuma ser mais rápida no runtime do Play. Para ativar, substitua o artefato:
O que muda:
  • Tamanho: cerca de 9,85 MB a menos de código nativo instalado por dispositivo (arm64), porque o runtime de ML deixa de ficar dentro do seu app. (Uma comparação com um APK universal não minificado de 4 ABIs mostra uma diferença maior, de ~43 MB, mas esse número contabiliza arquiteturas que nenhum dispositivo instala sozinho; o número por dispositivo acima é o que seus usuários realmente veem.)
  • Requisito: Google Play services. Em dispositivos sem ele (por exemplo, dispositivos Huawei sem GMS), ou se o runtime do Play não conseguir inicializar, o SDK faz o fallback automaticamente: para o runtime incluído no pacote quando o didit-sdk-autodetection também está instalado, ou para a captura manual caso contrário. Ele nunca trava por causa de um runtime indisponível.
  • Escolha de cobertura: distribua apenas o -play para ter o app menor (usuários sem GMS ficam com a captura manual), ou distribua os dois artefatos para manter a captura automática por ML em dispositivos sem GMS, com o tamanho original.
Os dois artefatos exigem o didit-sdk-core 4.7.0 ou mais recente.
O didit-sdk-autodetection-play é, por enquanto, opcional. A Didit acompanha seu desempenho em campo em comparação com o runtime incluído no pacote durante um ciclo de lançamentos após o lançamento; quando esses dados confirmarem a paridade, a expectativa é que o artefato do Play se torne a forma recomendada de instalar a detecção automática, e o didit-sdk-autodetection (incluído no pacote) continua sendo a recomendação padrão até lá.
Desde a 4.6.0, a assinatura nativa com carteira via WalletConnect é distribuída como um complemento opcional próprio, o me.didit:didit-sdk-wallet. O pacote completo me.didit:didit-sdk já o inclui, então nada muda se você instalar o pacote completo. Se você usa um dos artefatos mais enxutos e quer que a confirmação de propriedade da carteira rode nativamente dentro do seu app, adicione o me.didit:didit-sdk-wallet junto com ele; sem o complemento, o SDK conclui a confirmação de propriedade da carteira por um fluxo seguro no navegador, então o recurso continua funcionando de qualquer forma. Tirar o WalletConnect do didit-sdk-core também removeu vários megabytes de dependências de carteira de todos os builds que não precisam delas. Todos os artefatos são publicados com a mesma versão, então mantenha todos na 4.9.1.

Mantendo o download pequeno

Os modelos de detecção usados na captura automática são baixados em tempo de execução e armazenados em cache, então nunca contam no tamanho do seu app. O que a captura automática adiciona ao seu app é a biblioteca nativa do runtime de ML, e esse custo é por arquitetura de CPU: cerca de 10 MB para arm64-v8a, 7 MB para armeabi-v7a e 13 MB para cada uma das duas arquiteturas de emulador x86. Para arcar com esse custo apenas uma vez:
  1. Publique um Android App Bundle (AAB). O Google Play entrega apenas a arquitetura e os idiomas do próprio dispositivo, então um celular arm64 instala cerca de 10 MB de código nativo (aproximadamente 4 MB de download compactado). Já um APK universal reúne as quatro arquiteturas, mais de 40 MB, o que é a causa mais comum de medições de tamanho inesperadamente grandes.
  2. Se você distribui um único APK e seu público usa celulares e tablets ARM, restrinja as arquiteturas incluídas:
    Mantenha todas as ABIs que seus usuários realmente usam: adicione x86_64 se você atende Chromebooks ou outros dispositivos x86, ou publique APKs divididos por ABI para que nenhum dispositivo perca o suporte.
  3. Ative o R8: isMinifyEnabled = true e isShrinkResources = true no seu build type de release (minifyEnabled true / shrinkResources true se você usa build.gradle em Groovy). O SDK inclui suas próprias regras de consumidor, então o código não utilizado do SDK é removido sem nenhuma configuração extra.
  4. Limite os idiomas incluídos com resConfigs(...) se você não precisa de todas as 48 localidades do SDK em um build de APK; as divisões por idioma do AAB cuidam disso automaticamente no Google Play.

Etapa 3: Adicione a exclusão de empacotamento

Adicione isto ao bloco android do seu app para evitar conflitos de build:
Pronto! O Gradle resolve automaticamente todas as dependências transitivas.

Permissões

O SDK exige as permissões a seguir. Elas são declaradas no AndroidManifest.xml do SDK e serão mescladas automaticamente ao manifesto do seu app:

Recursos de câmera e NFC

O SDK declara android.hardware.camera e android.hardware.nfc como recursos opcionais (android:required="false"). Isso garante que o seu app possa ser instalado em dispositivos sem câmera ou sem hardware NFC, e o SDK lida de forma adequada com a ausência do hardware em tempo de execução.

Início rápido

Etapa 1: inicializar o SDK

Inicialize o SDK no Application.onCreate():

Etapa 2: iniciar a verificação e tratar os resultados


Métodos de integração

O SDK oferece dois métodos de integração: Não exige backend. O SDK cria a sessão diretamente usando o ID do seu fluxo de verificação (workflow) no Didit Console. Limitado apenas a vendorData.

Método 2: sessão pelo backend (recomendado para produção)

O seu backend cria a sessão pela API de criação de sessão de verificação (POST /v3/session/) com suporte completo a parâmetros (contact_details, expected_details, metadata, callback etc.) e depois repassa o session_token ao SDK.
Essa abordagem dá a você controle total sobre:
  • A associação das sessões aos seus usuários (vendor_data)
  • A definição de metadados personalizados
  • A configuração de callbacks por sessão
  • O envio de dados de contato e dados esperados para validação cruzada

Configuração

Personalize o comportamento do SDK:

Opções de configuração

Opções de câmera

As opções de câmera correspondem às opções de câmera do Web SDK. Cada lente é CameraLens.FRONT ou CameraLens.BACK. Se o dispositivo não tiver a lente solicitada, o SDK usa a primeira câmera disponível. O seletor de câmera também fica oculto em dispositivos que têm apenas uma câmera. Defina uma opção do seletor como false para restringir o usuário à lente padrão dessa etapa.
As opções showLanguageSelector, showCloseButton, showExitConfirmation e closeOnComplete correspondem à DiditSdkConfiguration do Web SDK. As opções exclusivas do mobile, languageLocale e fontFamily, existem porque o SDK mobile renderiza toda a interface de verificação de forma nativa (ao contrário do Web SDK, que delega ao frontend hospedado dentro de um iframe).
Temas e cores: cores, fundos e configurações da tela de introdução são definidos nas suas configurações de Marca própria no Didit Console, e não na configuração do SDK. Isso garante uma identidade visual consistente em todas as plataformas.

Suporte a idiomas

O SDK oferece suporte a 54 idiomas. Se nenhum idioma for especificado, o SDK usa a localidade do dispositivo, com inglês como alternativa.
Ver todos os idiomas compatíveis →

Opções avançadas

Para parâmetros avançados de sessão (contact_details, expected_details, metadata, callback), use o método Backend Session. O seu backend chama a API de criação de sessão de verificação com todos os parâmetros e depois repassa o session_token ao SDK.

Tratamento de resultados

A sealed class VerificationResult fornece o resultado da verificação:

Casos de resultado

Propriedades de SessionData

Tipos de erro

Todos os erros são subclasses seladas de me.didit.sdk.VerificationError:

Perda de conexão

Se o dispositivo perder a conexão durante a verificação, o SDK exibe uma tela “Sem conexão com a internet” durante o fluxo em vez de deixar uma etapa carregando indefinidamente. Ele continua verificando em segundo plano e fecha a tela sozinho assim que a Didit volta a ficar acessível, e o usuário continua da etapa em que estava. A tela oferece Tentar novamente e, quando showCloseButton é true (o padrão), Sair da verificação. Sair encerra a verificação com VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), para que seu app saiba que o usuário saiu devido à perda de conexão.

Exemplo completo de tratamento de resultados


Como observar o estado do SDK

Você pode observar o estado do SDK para criar uma interface de carregamento personalizada:

ProGuard / R8

O SDK inclui suas próprias regras do ProGuard do consumidor. Nenhuma configuração adicional é necessária. Se você usa o modo completo do R8, talvez precise adicionar isto ao seu gradle.properties:

Exemplo de ponta a ponta (sessão no backend → SDK Android → resultado)

Este padrão é a integração pronta para produção. Seu backend cria a sessão, seu app Android recebe o session_token e o SDK executa o fluxo.

1. Backend: criar a sessão

2. Android: trocar o token e iniciar o SDK

3. Backend: receber a decisão final via webhook

O resultado do SDK é prático para dar feedback na interface, mas o resultado oficial chega via webhook. Consulte o guia de webhooks para a verificação HMAC.

Exemplo completo


Última modificação em 1 de novembro de 2026