Resposta dos SDKs
Esta página explica os motivos pelos quais um SDK é encerrado. Para isso, verifique o tipo de falha da classe do objeto presente no objeto de resultado.
InvalidTokenReason
O token informado não é válido para o produto correspondente
Parametrize "test123" como token no builder do SDK
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
PermissionReason
Falta alguma permissão obrigatória para executar o SDK
Iniciar o DocumentDetector sem 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 armazenamento interno do dispositivo está cheio ao instalar o app, e o template de detecção facial não pode ser instalado junto
PassiveFaceLiveness
FaceAuthenticator
NetworkReason
Falha na conexão com a internet
O usuário estava sem internet durante o facematch no FaceAuthenticator
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
AddressCheck
ServerReason
Quando uma requisição do SDK recebe um código de status de falha
Em teoria, isso não deveria acontecer. Se você vir algo assim, nos avise!
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
AddressCheck
SecurityReason
Quando o SDK não pode ser iniciado por um motivo de segurança
Quando Provedor de Segurança do Google 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 ao capturar a foto do documento
DocumentDetector
PassiveFaceLiveness
FaceAuthenticator
LibraryReason
Quando uma biblioteca interna do SDK não pode ser iniciada
Esquecer de definir oCompress configuração levará a essa falha no DocumentDetector
DocumentDetector
InvalidFaceReason
Não há registro facial para o peopleId informado
Quando o usuário se autentica com um peopleId que não possui registro facial
FaceAuthenticator
A Segurança retorna
Estamos constantemente tomando ações para tornar o produto cada vez mais seguro, mitigando muitos ataques observados nos processos de captura e, consequentemente, reduzindo o máximo possível as fraudes de identidade. Os erros descritos aqui são retornados em message campo da SecurityReason classe.
Error 100
Representa o bloqueio de dispositivos emulados pelo SDK.
O uso de emuladores é muito comum atualmente por fraudadores, devido à possibilidade de acessar qualquer dispositivo existente, abrindo um enorme leque de possibilidades para novas fraudes. Por isso, por padrão, os SDKs realizam esse bloqueio.
Se você quiser desativar essa validação, use o emulatorSettings parâmetro no SDK Builder.
Error 200
Representa o bloqueio de dispositivos com privilégios de root pelo SDK.
O uso de dispositivos com root é hoje o principal meio de fraude, devido à possibilidade de acessar um dispositivo com privilégios extras, permitindo que o fraudador acesse propriedades ocultas, além da possibilidade de modificar e contornar todo o sistema de segurança por trás dos SDKs. Por isso, por padrão, os SDKs realizam esse bloqueio.
Se você quiser desativar essa validação, use o rootSettings parâmetro no SDK Builder.
Error 300
Representa o bloqueio de dispositivos com o modo de desenvolvedor ativo.
Usar dispositivos com o modo de desenvolvedor ativo permite que o usuário acesse configurações exclusivas de desenvolvimento, como a capacidade de depurar aplicativos usando cabos USB. Por isso, por padrão, os SDKs realizam esse bloqueio.
Se você quiser desativar essa validação, use o useDeveloperMode parâmetro no SDK Builder.
Error 400
Representa o bloqueio de dispositivos com o Android Debug Bridge ativado.
O comando ADB facilita uma variedade de ações no dispositivo, como instalar e depurar apps, e fornece acesso a um shell Unix. Por isso, por padrão, os SDKs realizam esse bloqueio.
Se você quiser desativar essa validação, use o useAdb parâmetro no SDK Builder.
Error 500
Representa o bloqueio de dispositivos com o modo de depuração ativado.
Usar dispositivos com o modo de depuração ativado permite que o usuário depure aplicativos usando cabos USB, permitindo que ele entenda e teste diferentes maneiras de contornar o fluxo do SDK. Por isso, por padrão, os SDKs realizam esse bloqueio.
Se você quiser desativar essa validação, use o useDebug parâmetro no SDK Builder.
Atualizado