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 blocorepositories do seu settings.gradle.kts:
settings.gradle (Groovy):
Passo 2: adicionar a dependência
Adicione a dependência do SDK aobuild.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.
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 paraarm64-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:
- 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.
-
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_64se visar Chromebooks ou outros dispositivos x86, ou publique divisões de APK por ABI para que nenhum dispositivo perca suporte. -
Ative o R8:
isMinifyEnabled = trueeisShrinkResources = trueno tipo de compilação de lançamento (minifyEnabled true/shrinkResources truese usarbuild.gradleem 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. -
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 blocoandroid da sua aplicação para evitar conflitos de compilação:
Permissões
O SDK requer as seguintes permissões. Estas são declaradas noAndroidManifest.xml do SDK e serão integradas automaticamente no manifesto da sua aplicação:
Funcionalidades de câmara e NFC
O SDK declaraandroid.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 emApplication.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:Método 1: UniLink (o mais simples)
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 avendorData.
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.
- 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.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 seladaVerificationResult indica 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:
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, quandoshowCloseButton 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 seugradle.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 osession_token e o SDK executa o fluxo.