Resultado de um SDK

Essa página explica os motivos que levam ao encerramento de um SDK. Para isso, verifique a instância da classe do objeto SDKFailure presente no objeto de resultado.

instanceof	Descrição	Exemplo	SDKs presentes
null	O SDK foi encerrado com sucesso. Seus objetos de retorno estão corretamente preenchidos	Quando o usuário executa os passos internos com sucesso	DocumentDetector PassiveFaceLiveness FaceAuthenticator
InvalidTokenReason	O token informado não é válido para o produto correspondente	Parametrizar "test123" como token no builder do SDK	DocumentDetector PassiveFaceLiveness FaceAuthenticator
PermissionReason	Está faltando alguma permissão obrigatória para executar o SDK	Iniciar o DocumentDetector sem a permissão de câmera concedida	DocumentDetector PassiveFaceLiveness FaceAuthenticator AddressCheck
AvailabilityReason	O SDK ainda não está disponível para uso. A variável SDKFailure.getMessage() contém instruções para o usuário	O dispositivo está com o armazenamento interno lotado ao instalar o app, não sendo possível instalar o modelo de detecção facial juntos	PassiveFaceLiveness FaceAuthenticator
NetworkReason	Falha de conexão com a internet	O usuário ficou sem internet durante o facematch no FaceAuthenticator	DocumentDetector PassiveFaceLiveness FaceAuthenticator AddressCheck
ServerReason	Quando uma requisição do SDK recebe um status code de falha	Em teoria, não deve acontecer. Se presenciar algo nesse sentido, comunique-nos!	DocumentDetector PassiveFaceLiveness FaceAuthenticator AddressCheck
SecurityReason	Quando o SDK não pode ser iniciado devido a uma razão de segurança	Quando o Google Security Provider não está atualizando	DocumentDetector PassiveFaceLiveness FaceAuthenticator
StorageReason	Não há espaço no armazenamento interno do dispositivo do usuário	Quando não há espaço no armazenamento interno durante a captura da foto do documento	DocumentDetector PassiveFaceLiveness FaceAuthenticator
LibraryReason	Quando uma biblioteca interna ao SDK não pode ser iniciada	Esquecer a configuração noCompress acarretará nesta falha no DocumentDetector	DocumentDetector
InvalidFaceReason	Não existe um registro facial para o peopleId informado	Quando o usuário realizar uma autenticação com um peopleId que não possui registro facial	FaceAuthenticator

Exemplo

O exemplo a seguir mostra como descobrir e tratar o motivo de encerramento do SDK DocumentDetector:

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (requestCode == REQUEST_CODE){
        if (resultCode == RESULT_OK && data != null){
            DocumentDetectorResult mDocumentDetectorResult = (DocumentDetectorResult) data.getSerializableExtra(DocumentDetectorResult.PARAMETER_NAME);
            SDKFailure sdkFailure = mDocumentDetectorResult.getSDKFailure();
            if (sdkFailure == null){ // ou sdkFailure == null
                // o SDK encerrou com sucesso
            } else if (sdkFailure instanceof InvalidTokenReason){
                // o token informado por parâmetro não é válido, revise-o
            } else if (sdkFailure instanceof PermissionReason){
                // falta uma permissão ser concedida pelo usuário para iniciar o SDK
            } else if (sdkFailure instanceof AvailabilityReason){
                // a String sdkFailure.getMessage() contém instruções ao usuário
            } else if (sdkFailure instanceof NetworkReason){
                // falha de conexão com a internet
            } else if (sdkFailure instanceof ServerReason){
                // houve algum problema em alguma comunicação com os servidores da CAF, avise-nos!
            } else if (sdkFailure instanceof SecurityReason){
                // alguma razão de segurança no dispositivo do usuário impede a utilização do SDK
            } else if (sdkFailure instanceof StorageReason){
                // solicite a seu usuário para liberar espaço no armazenamento interno
            } else if (sdkFailure instanceof LibraryReason){
                // alguma biblioteca interna encontrou problemas para executar
            }
        } else {
            // o usuário fechou a activity
        }
    }
    super.onActivityResult(requestCode, resultCode, data);
}

Retornos de segurança

Estamos constantemente realizando ações para tornar o produto cada vez mais seguro, mitigando uma série de ataques observados aos processos de captura e, consequentemente, reduzindo o maior número de possíveis fraudes de identidade. Os erros aqui descritos são retornados no campo message da classe SecurityReason.

Erro 100

Representa o bloqueio de dispositivos emulados por parte do SDK.

A utilização de emuladores é muito comum por fraudadores atualmente, por conta da possibilidade ao acesso de qualquer dispositivo existente, abrindo um enorme leque de possibilidades para novas fraudes. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .setUseEmulator(bool use) no Builder do SDK.

Erro 200

Representa o bloqueio de dispositivos com privilégio root por parte do SDK.

A utilização de dispositivos com root é o principal meio de fraudes atualmente, por conta da possibilidade ao acesso de um dispositivo com privilégios extras, permitindo que o fraudador tenha acesso a propriedades ocultas, além da possibilidade de modificar e burlar todo o sistema de segurança por trás dos SDK's. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .setUseRoot(bool use) no Builder do SDK.

Erro 300

Representa o bloqueio de dispositivos com modo desenvolvedor ativo.

A utilização de dispositivos com modo desenvolvedor ativo permite que um usuário tenha acesso a configurações exclusivas de desenvolvimento como, por exemplo, a possibilidade de depuração dos aplicativos com a utilização de cabos USB. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .setUseDeveloperMode(bool use) no Builder do SDK.

Erro 400

Representa o bloqueio de dispositivos com Android Debug Bridge ativado.

O comando ADB facilita uma variedade de ações do dispositivo, como instalar e depurar apps, e fornece acesso a um shell Unix. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .setUseAdb(bool use) no Builder do SDK.

Erro 500

Representa o bloqueio de dispositivos com do modo debug ativado.

A utilização de dispositivos com modo debug ativo permite que um usuário tenha a possibilidade de depuração dos aplicativos com a utilização de cabos USB, permitindo entender e testar diferentes formas de burlar o fluxo do SDK. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .setUseDebug(bool use) no Builder do SDK.

Erro 600 (em breve)

Representa o bloqueio de dispositivos com assinatura do app fraudulenta.

Verificação da assinatura bloqueia ataques de engenharia reversa e todos outros ataques maliciosos que podem ser feitos após esse processo no qual o aplicativo tem sua assinatura original alterada. Por conta disso, por padrão os SDK's realizam esse bloqueio.

Caso deseje desabilitar essa validação, utilize o método .checkAppSignature(bool use) no Builder do SDK.