Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Trên các thiết bị có cảm biến vân tay, người dùng có thể đăng ký một hoặc nhiều vân tay và dùng những vân tay đó để mở khoá thiết bị cũng như thực hiện các tác vụ khác. Android sử dụng Ngôn ngữ định nghĩa giao diện phần cứng vân tay (HIDL) để kết nối với một thư viện dành riêng cho nhà cung cấp và phần cứng vân tay (ví dụ: cảm biến vân tay).
Để triển khai Fingerprint HIDL, bạn phải triển khai IBiometricsFingerprint.hal trong một thư viện dành riêng cho nhà cung cấp.
So khớp vân tay
Cảm biến vân tay của thiết bị thường ở trạng thái rảnh. Tuy nhiên, để phản hồi một lệnh gọi đến authenticate hoặc enroll, cảm biến vân tay sẽ lắng nghe một thao tác chạm (màn hình cũng có thể thức khi người dùng chạm vào cảm biến vân tay). Quy trình khớp vân tay ở cấp độ cao bao gồm các bước sau:
Người dùng đặt ngón tay lên cảm biến vân tay.
Thư viện dành riêng cho nhà cung cấp sẽ xác định xem có dấu vân tay nào khớp trong nhóm mẫu dấu vân tay đã đăng ký hiện tại hay không.
Kết quả trùng khớp sẽ được chuyển đến FingerprintService.
Quy trình này giả định rằng vân tay đã được đăng ký trên thiết bị, tức là thư viện dành riêng cho nhà cung cấp đã đăng ký một mẫu vân tay. Để biết thêm thông tin, hãy xem phần Xác thực.
Kiến trúc
HAL vân tay tương tác với các thành phần sau.
BiometricManager tương tác trực tiếp với một ứng dụng trong quy trình ứng dụng.
Mỗi ứng dụng đều có một thực thể IBiometricsFingerprint.hal
FingerprintService hoạt động trong quy trình hệ thống, xử lý hoạt động giao tiếp với HAL vân tay.
HAL vân tay là một phương thức triển khai C/C++ của giao diện IBiometricsFingerprint HIDL. Thư viện này chứa thư viện dành riêng cho nhà cung cấp, giao tiếp với phần cứng dành riêng cho thiết bị.
Các thành phần API Kho khoá và KeyMint (trước đây là Keymaster) cung cấp hoạt động mã hoá dựa trên phần cứng để lưu trữ khoá an toàn trong một môi trường bảo mật, chẳng hạn như Môi trường thực thi đáng tin cậy (TEE).
Hình 1. Luồng dữ liệu cấp cao để xác thực bằng vân tay
Quá trình triển khai HAL dành riêng cho nhà cung cấp phải sử dụng giao thức truyền thông mà TEE yêu cầu. Hình ảnh thô và các đặc điểm vân tay đã xử lý không được truyền trong bộ nhớ không đáng tin cậy. Tất cả dữ liệu sinh trắc học như vậy cần được lưu trữ trong phần cứng bảo mật, chẳng hạn như TEE. Quá trình can thiệp vào hệ thống không được gây tổn hại đến dữ liệu sinh trắc học.
FingerprintService và fingerprintd thực hiện các lệnh gọi thông qua Fingerprint HAL đến thư viện dành riêng cho nhà cung cấp để đăng ký dấu vân tay và thực hiện các thao tác khác.
Hình 2. Tương tác của trình nền vân tay với thư viện dành riêng cho nhà cung cấp vân tay
Nguyên tắc triển khai
Các nguyên tắc sau đây về HAL vân tay được thiết kế để đảm bảo rằng dữ liệu vân tay không bị rò rỉ và sẽ bị xoá khi người dùng bị xoá khỏi thiết bị:
Dữ liệu vân tay thô hoặc dữ liệu phái sinh (ví dụ: mẫu) không bao giờ được truy cập từ bên ngoài trình điều khiển cảm biến hoặc TEE. Nếu phần cứng hỗ trợ TEE, thì quyền truy cập phần cứng phải được giới hạn trong TEE và được bảo vệ bằng một chính sách SELinux. Chỉ TEE mới có quyền truy cập vào kênh Giao diện ngoại vi nối tiếp (SPI) và phải có một chính sách SELinux rõ ràng trên tất cả các tệp thiết bị.
Việc thu thập, đăng ký và nhận dạng vân tay phải diễn ra trong TEE.
Chỉ có thể lưu trữ dạng mã hoá của dữ liệu vân tay trên hệ thống tệp, ngay cả khi chính hệ thống tệp đã được mã hoá.
Mẫu vân tay phải được ký bằng một khoá riêng tư dành riêng cho thiết bị.
Đối với Tiêu chuẩn mã hoá nâng cao (AES), tối thiểu, một mẫu phải được ký bằng đường dẫn tuyệt đối của hệ thống tệp, nhóm và mã nhận dạng vân tay để các tệp mẫu không hoạt động trên một thiết bị khác hoặc đối với bất kỳ ai khác ngoài người dùng đã đăng ký các tệp đó trên cùng một thiết bị. Ví dụ: không thể sao chép được dữ liệu vân tay từ người dùng khác trên cùng thiết bị hoặc từ một thiết bị khác.
Các hoạt động triển khai phải sử dụng đường dẫn hệ thống tệp do hàm setActiveGroup() cung cấp hoặc cung cấp cách xoá tất cả dữ liệu mẫu người dùng khi người dùng bị xoá. Bạn nên lưu trữ các tệp mẫu vân tay dưới dạng được mã hoá và lưu trữ trong đường dẫn được cung cấp. Nếu không thể thực hiện được việc này do yêu cầu về bộ nhớ TEE, thì người triển khai phải thêm các hook để đảm bảo xoá dữ liệu khi người dùng bị xoá.
Chuyển máy trạng thái HAL để bắt đầu thu thập và lưu trữ mẫu vân tay. Khi quá trình đăng ký hoàn tất hoặc sau khi hết thời gian chờ, máy trạng thái HAL sẽ trở về trạng thái rảnh.
preEnroll()
Tạo một mã thông báo duy nhất để cho biết thời điểm bắt đầu đăng ký vân tay. Cung cấp mã thông báo cho hàm enroll để đảm bảo đã có phương thức xác thực trước đó, ví dụ: sử dụng mật khẩu. Để ngăn chặn hành vi giả mạo, mã thông báo sẽ được bao bọc sau khi thông tin đăng nhập thiết bị được xác nhận. Bạn phải kiểm tra mã thông báo trong quá trình đăng ký để xác minh rằng mã thông báo vẫn còn hiệu lực.
getAuthenticatorId()
Trả về mã thông báo được liên kết với bộ dấu vân tay hiện tại.
cancel()
Huỷ các thao tác đăng ký hoặc xác thực đang chờ xử lý. Máy trạng thái HAL được đưa về trạng thái rảnh.
enumerate()
Lệnh gọi đồng bộ để liệt kê tất cả các mẫu vân tay đã biết.
remove()
Xoá một mẫu vân tay.
setActiveGroup()
Hạn chế một thao tác HAL đối với một nhóm dấu vân tay thuộc một nhóm cụ thể, được xác định bằng giá trị nhận dạng nhóm (GID).
authenticate()
Xác thực một thao tác liên quan đến dấu vân tay (được xác định bằng mã thao tác).
setNotify()
Đăng ký một hàm người dùng nhận thông báo từ HAL. Nếu máy trạng thái HAL đang ở trạng thái bận, thì hàm sẽ bị chặn cho đến khi HAL rời khỏi trạng thái bận.
postEnroll()
Hoàn tất thao tác đăng ký và vô hiệu hoá thử thách preEnroll() đã tạo. Bạn phải gọi phương thức này ở cuối phiên đăng ký nhiều ngón tay để cho biết rằng bạn không thể thêm ngón tay nữa.
Để biết thêm thông tin chi tiết về các thông báo này, hãy tham khảo phần bình luận trong IBiometricsFingerprint.hal.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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)."]]
