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

Repositório no GitHub

Consulte o código-fonte e os exemplos no GitHub

SDK nativo: Esta é a abordagem recomendada para aplicações Android. Os SDKs nativos oferecem a melhor experiência do utilizador, um tratamento otimizado da câmara e suporte completo a NFC.


Requisitos

Disponibilidade de funcionalidades por nível de API: a deteção automática de documentos e de rostos requer API 24+ (detetores leves próprios da Didit, incluídos em didit-sdk-core). Em dispositivos com API 23, o SDK recorre à captura manual, com um botão de disparo temporizado. Todas as restantes funcionalidades funcionam em todo o intervalo abrangido pela API 23+.
O consentimento biométrico requer o SDK nativo 4.10.0 ou posterior. Para pessoas abrangidas pela legislação do Illinois, do Texas ou do Colorado, a Didit pode pedir um consentimento biométrico explícito antes da primeira captura facial. O SDK Android 4.10.0 e versões posteriores apresentam essa etapa. As versões anteriores não a conseguem apresentar: as suas sessões são executadas como antes, e a decisão indica que o consentimento não foi recolhido (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize se verifica pessoas nesses estados.

Instalação

Passo 1: adicionar o repositório

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

Passo 2: adicionar a dependência

Adicione a dependência do SDK ao build.gradle.kts da sua aplicação: (!) Quanto à versão, certifique-se de que consulta o repositório do GitHub para ver a versão mais recente.
Ou, se usar build.gradle (Groovy):

Variantes do SDK

O SDK para Android é distribuído em artefactos separados, pelo que a sua aplicação só paga o custo binário das funcionalidades que usa. me.didit:didit-sdk acima é o pacote completo. Escolha o que se adapta à sua aplicação: Desde a versão 4.6.0, a assinatura nativa de carteiras com WalletConnect é distribuída como um complemento opcional próprio, me.didit:didit-sdk-wallet. O pacote completo me.didit:didit-sdk já o inclui, por isso nada muda se instalar o pacote. Se usar um dos artefactos mais leves e quiser que a confirmação de titularidade da carteira seja executada nativamente na sua aplicação, adicione me.didit:didit-sdk-wallet junto a ele; sem o complemento, o SDK concretiza a titularidade da carteira através de um fluxo seguro no navegador, pelo que a funcionalidade continua a funcionar em qualquer dos casos. Mover o WalletConnect para fora de didit-sdk-core também eliminou vários megabytes de dependências de carteiras de todas as compilações que não as necessitam. Todos os artefactos são publicados na mesma versão, por isso mantenha-os na versão 4.13.2.

Manter o tamanho da transferência reduzido

Os modelos de deteção usados na captura automática são transferidos em tempo de execução e guardados em cache, pelo que nunca contam para o tamanho da sua aplicação. O que a captura automática acrescenta à aplicação é a biblioteca nativa do ambiente de execução de ML, e esse custo depende da arquitetura da 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 pagar esse custo apenas uma vez:
  1. Publique um Android App Bundle (AAB). A Google Play entrega apenas a arquitetura e os idiomas do próprio dispositivo, pelo que um telemóvel arm64 instala cerca de 10 MB de código nativo (cerca de 4 MB de transferência comprimida). Um APK universal, em contrapartida, inclui as quatro arquiteturas, com mais de 40 MB, o que é a causa mais comum de medições de tamanho inesperadamente grandes.
  2. Se distribuir um único APK e o seu público for constituído por utilizadores de telemóveis e tablets ARM, restrinja as arquiteturas incluídas:
    Mantenha todas as ABI que os seus utilizadores realmente usam: acrescente x86_64 se visar Chromebooks ou outros dispositivos x86, ou publique divisões de APK por ABI para que nenhum dispositivo perca suporte.
  3. Ative o R8: isMinifyEnabled = true e isShrinkResources = true no tipo de compilação de lançamento (minifyEnabled true / shrinkResources true se usar build.gradle em Groovy). O SDK inclui as suas próprias regras de consumidor, pelo que o código do SDK não utilizado é removido sem configuração adicional.
  4. Limite os idiomas incluídos com resConfigs(...) se não precisar de todos os 48 idiomas do SDK numa compilação em APK; as divisões de idioma do AAB tratam disto automaticamente na Google Play.

Passo 3: adicionar a exclusão de empacotamento

Adicione isto ao bloco android da sua aplicação para evitar conflitos de compilação:
É tudo! O Gradle resolve automaticamente todas as dependências transitivas.

Permissões

O SDK requer as seguintes permissões. Estas são declaradas no AndroidManifest.xml do SDK e serão integradas automaticamente no manifesto da sua aplicação:

Funcionalidades de câmara e NFC

O SDK declara android.hardware.camera e android.hardware.nfc como funcionalidades opcionais (android:required="false"). Isto garante que a sua aplicação pode ser instalada em dispositivos sem câmara ou hardware NFC: o SDK trata a ausência de hardware de forma adequada em tempo de execução.

Início rápido

Passo 1: Inicializar o SDK

Inicialize o SDK em Application.onCreate():

Passo 2: Iniciar a verificação e tratar os resultados


Métodos de integração

O SDK suporta dois métodos de integração: Não requer backend. O SDK cria a sessão diretamente com o ID do seu fluxo de verificação na Didit Console. Limitado apenas a vendorData.

Método 2: Sessão no backend (recomendado para produção)

O seu backend cria a sessão através da API de criação de sessões de verificação (POST /v3/session/), com suporte total dos parâmetros (contact_details, expected_details, metadata, callback, etc.), e depois transmite o session_token ao SDK.
Esta abordagem oferece controlo total sobre:
  • Associar sessões aos seus utilizadores (vendor_data)
  • Definir metadados personalizados
  • Configurar callbacks por sessão
  • Fornecer detalhes de contacto e detalhes esperados para validação cruzada

Configuração

Personalize o comportamento do SDK:

Opções de configuração

Opções de câmara

As opções de câmara correspondem às opções de câmara do Web SDK. Cada objetiva é CameraLens.FRONT ou CameraLens.BACK. Se o dispositivo não tiver a objetiva pedida, o SDK usa a primeira câmara de que dispõe. O seletor de câmara também fica oculto em dispositivos que tenham apenas uma câmara. Defina uma opção de seletor como false para fixar o utilizador na objetiva predefinida dessa etapa.
As opções showLanguageSelector, showCloseButton, showExitConfirmation e closeOnComplete correspondem à DiditSdkConfiguration do Web SDK. As opções específicas para dispositivos móveis languageLocale e fontFamily existem porque o SDK para dispositivos móveis apresenta a interface completa de verificação de forma nativa (ao contrário do Web SDK, que delega no frontend alojado dentro de um iframe).
Temas e cores: As cores, os fundos e as definições do ecrã de introdução são configurados nas suas definições de Marca branca na Didit Console, e não na configuração do SDK. Isto garante uma identidade visual consistente em todas as plataformas.

Suporte de idiomas

O SDK suporta 54 idiomas. Se não for indicado nenhum idioma, o SDK usa a localidade do dispositivo, com inglês como alternativa.
Ver todos os idiomas suportados →

Opções avançadas

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

Processamento dos resultados

A classe selada VerificationResult indica 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:

Ligação perdida

Se o dispositivo perder a ligação durante a verificação, o SDK cobre o fluxo com um ecrã “Sem ligação à Internet” em vez de deixar um passo a carregar. Continua a verificar em segundo plano e fecha o ecrã automaticamente assim que a Didit voltar a estar acessível, e o utilizador continua a partir do passo em que estava. O ecrã oferece Tentar novamente e, quando showCloseButton tem o valor true (predefinido), Sair da verificação. Sair termina a verificação com VerificationResult.Failed(error = VerificationError.NetworkError, session = ...), para que a sua aplicação saiba que o utilizador saiu por causa da ligação.

Exemplo completo de tratamento do resultado


Observar o estado do SDK

Pode observar o estado do SDK para criar uma interface de carregamento personalizada:

ProGuard / R8

O SDK inclui as suas próprias regras ProGuard para a aplicação que integra o SDK. Não é necessária nenhuma configuração adicional. Se utilizar o modo completo do R8, pode ser necessário 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. O seu backend cria a sessão, a sua aplicação 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 através de webhook

O resultado do SDK é útil para o feedback na interface, mas o resultado definitivo chega através de webhook. Consulte o Guia de webhooks para a verificação HMAC.

Exemplo completo


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