A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Em dispositivos com sensor de impressão digital, os usuários podem registrar uma ou mais impressões digitais e usá-las para desbloquear o dispositivo e realizar outras tarefas. O Android usa a linguagem de definição de interface de hardware de impressão digital
(HIDL) para se conectar a uma biblioteca específica do fornecedor e ao hardware de impressão digital (por
exemplo, um sensor de impressão digital).
Para implementar o HIDL de impressão digital, é necessário implementar IBiometricsFingerprint.hal
em uma biblioteca específica do fornecedor.
Correspondência de impressões digitais
O sensor de impressão digital de um dispositivo geralmente fica inativo. No entanto, em resposta a uma chamada para authenticate ou enroll, o sensor de impressão digital aguarda um toque. A tela também pode ser ativada quando um usuário toca no sensor. O fluxo de alto nível da correspondência de impressões digitais inclui as seguintes etapas:
O usuário coloca um dedo no sensor de impressão digital.
A biblioteca específica do fornecedor determina se há uma correspondência de impressão digital no conjunto atual de modelos de impressão digital registrados.
Os resultados correspondentes são transmitidos para FingerprintService.
Este fluxo pressupõe que uma impressão digital já foi registrada no dispositivo, ou seja,
a biblioteca específica do fornecedor registrou um modelo para a impressão digital. Para mais detalhes, consulte Autenticação.
Arquitetura
O HAL de impressão digital interage com os seguintes componentes.
O BiometricManager interage diretamente com um app em um processo de app.
Cada app tem uma instância de IBiometricsFingerprint.hal.
O FingerprintService opera no
processo do sistema, que lida com a comunicação com a HAL de impressão digital.
O Fingerprint HAL é uma implementação em C/C++ da
interface IBiometricsFingerprint HIDL. Ela contém a biblioteca específica do fornecedor
que se comunica com o hardware específico do dispositivo.
Os componentes API Keystore e KeyMint (antes Keymaster) oferecem
criptografia com suporte de hardware para armazenamento seguro de chaves em um ambiente seguro,
como o ambiente de execução confiável (TEE).
Figura 1. Fluxo de dados de alto nível para autenticação
por impressão digital
Uma implementação de HAL específica do fornecedor precisa usar o protocolo de comunicação
exigido por um TEE. Imagens brutas e recursos de impressão digital processados não podem ser transmitidos em memória não confiável. Todos esses dados biométricos precisam ser armazenados
em hardware seguro, como o TEE. O acesso root não pode comprometer dados biométricos.
FingerprintService e fingerprintd fazem chamadas pela HAL de impressão digital para
a biblioteca específica do fornecedor para registrar impressões digitais e realizar outras
operações.
Figura 2. Interação do daemon de impressão digital
com a biblioteca específica do fornecedor de impressão digital
Diretrizes de implementação
As diretrizes a seguir do HAL de impressão digital foram criadas para garantir que
os dados de impressão digital não sejam vazados e sejam removidos
quando um usuário é removido de um dispositivo:
Os dados brutos de impressão digital ou derivados (por exemplo, modelos) nunca
podem ser acessados de fora do driver do sensor ou do TEE. Se o hardware for compatível com um TEE, o acesso a ele deve ser limitado e protegido por uma política do SELinux. O canal da interface periférica serial (SPI, na sigla em inglês) precisa estar acessível apenas ao TEE, e é necessário haver uma política explícita do SELinux em todos os arquivos do dispositivo.
A aquisição, o registro e o reconhecimento de impressões digitais precisam ocorrer dentro do TEE.
Somente a forma criptografada dos dados de impressão digital pode ser armazenada no sistema de arquivos, mesmo que ele seja criptografado.
Os modelos de impressão digital precisam ser assinados com uma chave privada específica do dispositivo.
Para o Padrão de criptografia avançada (AES), no mínimo, um modelo precisa ser assinado com o caminho absoluto do sistema de arquivos, o grupo e o ID da impressão digital para que os arquivos de modelo não funcionem em outro dispositivo ou para qualquer pessoa que não seja o usuário que os registrou no mesmo dispositivo. Por exemplo, a cópia dos dados de impressão digital de um
usuário diferente no mesmo dispositivo ou em outro não deve funcionar.
As implementações precisam usar o caminho do sistema de arquivos fornecido pela função
setActiveGroup() ou oferecer uma maneira de apagar todos os dados de
modelos do usuário quando ele for removido. Recomendamos que
os arquivos de modelo de impressão digital sejam armazenados criptografados no caminho fornecido. Se isso
for inviável devido aos requisitos de armazenamento do TEE, o implementador precisará adicionar hooks para
garantir a remoção dos dados quando o usuário for removido.
Métodos de impressão digital
A interface HIDL de impressão digital contém os seguintes métodos principais em
IBiometricsFingerprint.hal.
Método
Descrição
enroll()
Muda a máquina de estado da HAL para iniciar a
coleta e o armazenamento de um modelo de impressão digital. Quando a inscrição é concluída ou após um tempo limite, a máquina de estado HAL retorna ao estado inativo.
preEnroll()
Gera um token exclusivo para indicar o início de um
registro de impressão digital. Fornece um token à função enroll para garantir que houve autenticação anterior, por exemplo, usando uma senha. Para evitar
adulterações, o token é encapsulado depois que a credencial
do dispositivo é confirmada. O token precisa ser verificado durante o registro para confirmar
se ele ainda é válido.
getAuthenticatorId()
Retorna um token associado ao
conjunto de impressões digitais atual.
cancel()
Cancela as operações pendentes de inscrição ou autenticação. A máquina de estado da HAL volta ao estado inativo.
enumerate()
Chamada síncrona para enumerar todos os modelos de impressões digitais conhecidos.
remove()
Exclui um modelo de impressão digital.
setActiveGroup()
Restringe uma operação de HAL a um conjunto de
impressões digitais que pertencem a um grupo especificado, identificado por um identificador de grupo
(GID).
authenticate()
Autentica uma operação relacionada a impressões digitais
(identificada por um ID de operação).
setNotify()
Registra uma função de usuário que recebe
notificações da HAL. Se a máquina de estado HAL estiver ocupada, a função será bloqueada até que o HAL saia desse estado.
postEnroll()
Conclui a operação de inscrição e invalida o
desafio gerado preEnroll(). Isso precisa ser chamado no final de uma
sessão de registro de vários dedos para indicar que não é possível adicionar mais dedos.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# Fingerprint HIDL\n\nOn devices with a fingerprint sensor, users can enroll one or more\nfingerprints and use those fingerprints to unlock the device and perform other\ntasks. Android uses the Fingerprint Hardware Interface Definition Language\n(HIDL) to connect to a vendor-specific library and fingerprint hardware (for\nexample, a fingerprint sensor).\n\nTo implement the Fingerprint HIDL, you must implement [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)\nin a vendor-specific library.\n\nFingerprint matching\n--------------------\n\nThe fingerprint sensor of a device is generally idle. However, in response to\na call to `authenticate` or `enroll`, the\nfingerprint sensor listens for a touch (the screen might also wake when a user\ntouches the fingerprint sensor). The high-level flow of fingerprint matching\nincludes the following steps:\n\n1. User places a finger on the fingerprint sensor.\n2. The vendor-specific library determines if there is a fingerprint match in the current set of enrolled fingerprint templates.\n3. Matching results are passed to `FingerprintService`.\n\nThis flow assumes that a fingerprint has already been enrolled on the device, that is,\nthe vendor-specific library has enrolled a template for the fingerprint. For more\ndetails, see [Authentication](/docs/security/features/authentication).\n| **Note:** The more fingerprint templates stored on a device, the more time required for fingerprint matching.\n\nArchitecture\n------------\n\nThe Fingerprint HAL interacts with the following components.\n\n- `BiometricManager` interacts directly with an app in an app process. Each app has an instance of `IBiometricsFingerprint.hal`\n- `FingerprintService` operates in the system process, which handles communication with fingerprint HAL.\n- **Fingerprint HAL** is a C/C++ implementation of the IBiometricsFingerprint HIDL interface. This contains the vendor-specific library that communicates with the device-specific hardware.\n- **Keystore API and KeyMint (previously Keymaster)** components provide hardware-backed cryptography for secure key storage in a secure environment, such as the Trusted Execution Environment (TEE).\n\n**Figure 1.** High-level data flow for fingerprint authentication\n\nA vendor-specific HAL implementation must use the communication protocol\nrequired by a TEE. Raw images and processed fingerprint features must not\nbe passed in untrusted memory. All such biometric data needs to be stored\nin the secure hardware such as the TEE. Rooting **must not**\nbe able to compromise biometric data.\n\n`FingerprintService` and `fingerprintd` make calls through the Fingerprint HAL to\nthe vendor-specific library to enroll fingerprints and perform other\noperations.\n**Figure 2.** Interaction of the fingerprint daemon with the fingerprint vendor-specific library\n\nImplementation guidelines\n-------------------------\n\nThe following Fingerprint HAL guidelines are designed to ensure that\nfingerprint data is **not leaked** and is **removed**\nwhen a user is removed from a device:\n\n- Raw fingerprint data or derivatives (for example, templates) must never be accessible from outside the sensor driver or TEE. If the hardware supports a TEE, hardware access must be limited to the TEE and protected by an SELinux policy. The Serial Peripheral Interface (SPI) channel must be accessible only to the TEE and there must be an explicit SELinux policy on all device files.\n- Fingerprint acquisition, enrollment, and recognition must occur inside the TEE.\n- Only the encrypted form of the fingerprint data can be stored on the file system, even if the file system itself is encrypted.\n- Fingerprint templates must be signed with a private, device-specific key. For Advanced Encryption Standard (AES), at a minimum a template must be signed with the absolute file-system path, group, and finger ID such that template files are inoperable on another device or for anyone other than the user that enrolled them on the same device. For example, copying fingerprint data from a different user on the same device or from another device must not work.\n- Implementations must either use the file-system path provided by the `setActiveGroup()` function or provide a way to erase all user template data when the user is removed. It's strongly recommended that fingerprint template files be stored as encrypted and stored in the path provided. If this is infeasible due to TEE storage requirements, the implementer must add hooks to ensure removal of the data when the user is removed.\n\nFingerprint methods\n-------------------\n\nThe Fingerprint HIDL interface contains the following major methods in\n[`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal).\n\n| Method | Description |\n|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `enroll()` | Switches the HAL state machine to start the collection and storage of a fingerprint template. When enrollment is complete, or after a timeout, the HAL state machine returns to the idle state. |\n| `preEnroll()` | Generates a unique token to indicate the start of a fingerprint enrollment. Provides a token to the `enroll` function to ensure there was prior authentication, for example, using a password. To prevent tampering, the token is wrapped after the device credential is confirmed. The token must be checked during enrollment to verify that it's still valid. |\n| `getAuthenticatorId()` | Returns a token associated with the current fingerprint set. |\n| `cancel()` | Cancels pending enroll or authenticate operations. The HAL state machine is returned to the idle state. |\n| `enumerate()` | Synchronous call for enumerating all known fingerprint templates. |\n| `remove()` | Deletes a fingerprint template. |\n| `setActiveGroup()` | Restricts a HAL operation to a set of fingerprints that belong to a specified group, identified by a group identifier (GID). |\n| `authenticate()` | Authenticates a fingerprint-related operation (identified by an operation ID). |\n| `setNotify()` | Registers a user function that receives notifications from the HAL. If the HAL state machine is in a busy state, the function is blocked until the HAL leaves the busy state. |\n| `postEnroll()` | Finishes the enroll operation and invalidates the `preEnroll()` generated challenge. This must be called at the end of a multifinger enrollment session to indicate that no more fingers may be added. |\n\nFor more details on these, refer to the comments in [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)."]]