LivenessFacetecSDK e o fluxo completo de uma verificação de vivacidade.
API pública
A fachada do SDK fica emcom.vcc.vendor.facetec.sdk.LivenessFacetecSDK e tem apenas três funções:
inité idempotente — Chamadas subsequentes não reinicializam o FaceTec, mas sempre coletam o fingerprint novamente.startLivenessCheckrequer umaActivitychamadora porque o FaceTec abre sua própria UI a partir dela.stoppara a execução do SDK e libera recursos do sistema.
Configuração
| Parâmetro | Tipo | Obrigatório | Descrição |
|---|---|---|---|
customization | LivenessFacetecSDKCustomization? | Não | Personalização da UI do FaceTec. Veja Customização |
Campos de LivenessFacetecSDKInitData
init() retorna Result<LivenessFacetecSDKInitData> com os dados de device fingerprint coletados pelo FingerprintJS Pro:
| Campo | Tipo | Descrição |
|---|---|---|
visitorId | String? | Visitor ID gerado pelo FingerprintJS Pro. Encaminhe ao backend para criar a sessão. |
requestId | String? | Request ID da coleta do FingerprintJS Pro. Encaminhe ao backend junto com visitorId. |
Criação de sessão — responsabilidade do consumer app
O SDK não cria sessões nem se comunica diretamente com o backend de autenticação. Apósinit(), o consumer app deve:
- Encaminhar
visitorIderequestIdretornados porinit()ao seu backend. - O backend cria a sessão e devolve
sessionId,sessionTokenefacetecSessionToken. - Passar os três tokens para
startLivenessCheck().
O SDK não tem acesso às credenciais do backend do consumer nem conhece o contexto de negócio necessário para criar uma sessão válida. Manter a criação de sessão no consumer app garante flexibilidade (autenticação, multi-tenant) sem acoplar o SDK a uma topologia específica de backend.
Estados do Flow
startLivenessCheck retorna um Flow<LivenessFacetecSDKLivenessState> que emite um único caminho Loading → Success ou Loading → Error antes de completar:
O SDK suporta retry controlado pelo backend. Quando o backend retorna
canRetry: true na resposta de uma captura, o SDK mantém a UI do FaceTec aberta e realiza uma nova tentativa automaticamente — sem nenhuma ação do consumer. O Flow não emite estados intermediários durante as tentativas; Success ou Error são emitidos apenas ao final da última tentativa. O número de tentativas é definido exclusivamente pelo backend.Fluxo de uso
Inicializar o SDK
Chame
LivenessFacetecSDK.init uma única vez (preferencialmente em uma Application ou na tela inicial):init() é idempotente — Chamadas subsequentes não reinicializam o FaceTec, mas sempre coletam o fingerprint novamente. É seguro chamá-lo em múltiplas Activities ou no onCreate() da Application.Criar sessão no backend
Com
visitorId e requestId em mãos, chame seu backend para obter os três tokens necessários para a captura:Tratar o resultado
No caso de sucesso, use
sessionId e captureId para reconciliar a captura no backend. Verifique livenessCheck == true para confirmar aprovação biométrica. No caso de erro, mapeie cada subclasse de LivenessFacetecSDKError para uma mensagem ou ação adequada — veja Solução de problemas.Campos de LivenessFacetecSDKResultData
Quando a verificação termina com sucesso, o SDK emite Success(data: LivenessFacetecSDKResultData):
| Campo | Tipo | Descrição |
|---|---|---|
sessionId | String | ID da sessão criada no backend da Plataforma ID |
captureId | String | ID único da captura submetida |
status | String | Status final da captura |
processedAt | String | Timestamp ISO-8601 do processamento |
result | String? | Resultado do Liveness |
scanResultBlob | String? | Blob bruto retornado pelo FaceTec |
transactionId | String? | ID da transação no provedor |
retryScreen | Int? | Indicador interno de retry |
replayCheck | Boolean | Resultado da verificação anti-replay |
sessionTokenCheck | Boolean | Validação do token de sessão |
auditTrailCheck | Boolean | Validação da trilha de auditoria |
livenessCheck | Boolean | Resultado da verificação de vivacidade |
Os quatro campos
*Check são as garantias de segurança consolidadas pelo backend. Em uma captura legítima, todos devem ser true.Exemplos de retorno
Sucesso — liveness aprovado
O fluxo terminou e a verificação biométrica passou.status vem "completed", result é "live" e todos os *Check são true.
Sucesso — liveness reprovado
O fluxo terminou tecnicamente, mas o resultado biométrico foi negativo.status vem "failed", result é "not_live" e livenessCheck é false. O backend pode também marcar auditTrailCheck como false quando a trilha de auditoria não atende aos requisitos.
Esse caso não é erro técnico — o SDK funcionou corretamente, mas a prova de vida foi reprovada. Trate como negativa de verificação no seu app (mostrar mensagem ao usuário e permitir nova tentativa), sem reportar como falha do SDK.
Erro do fluxo
Quando algo no fluxo técnico falha, o SDK emiteError(error: LivenessFacetecSDKError). As subclasses possíveis cobrem rede, captura, submissão, cancelamento e exceções não mapeadas:
Exemplo completo
Esse exemplo é uma adaptação do app de demonstração que acompanha o SDK:Parando o SDK
LivenessFacetecSDK.stop() libera os recursos internos do SDK e reseta seu estado. Uma chamada subsequente a init() se comporta como primeiro uso.
| Situação | Ação |
|---|---|
Teardown da Activity (onDestroy) | Chame stop() para liberar recursos |
| Entre capturas | Opcional — init() é idempotente |
Se
stop() for chamado durante uma captura em andamento, ela é cancelada imediatamente e o Flow emite Error(Cancelled). Chamadas antes de init() ou duas vezes seguidas não causam crash.Próximos passos
Customização
Personalize cores, textos e animações da UI do FaceTec
Solução de problemas
Hierarquia de erros e dicas de diagnóstico