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 blocorepositories do seu settings.gradle.kts:
settings.gradle (Groovy):
Etapa 2: Adicione a dependência
Adicione a dependência do SDK aobuild.gradle.kts do seu app:
(!) Quanto à versão, confira no repositório do GitHub qual é a mais recente.
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. Ome.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)
Ome.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:
- 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-autodetectiontambé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
-playpara 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.
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á.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 paraarm64-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:
- 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.
-
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_64se você atende Chromebooks ou outros dispositivos x86, ou publique APKs divididos por ABI para que nenhum dispositivo perca o suporte. -
Ative o R8:
isMinifyEnabled = trueeisShrinkResources = trueno seu build type de release (minifyEnabled true/shrinkResources truese você usabuild.gradleem 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. -
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 blocoandroid do seu app para evitar conflitos de build:
Permissões
O SDK exige as permissões a seguir. Elas são declaradas noAndroidManifest.xml do SDK e serão mescladas automaticamente ao manifesto do seu app:
Recursos de câmera e NFC
O SDK declaraandroid.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 noApplication.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:Método 1: UniLink (o mais simples)
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 avendorData.
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.
- 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.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 classVerificationResult fornece o resultado da verificação:
Casos de resultado
Propriedades de SessionData
Tipos de erro
Todos os erros são subclasses seladas deme.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, quandoshowCloseButton é 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 seugradle.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 osession_token e o SDK executa o fluxo.