Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Di perangkat dengan sensor sidik jari, pengguna dapat mendaftarkan satu atau beberapa sidik jari dan menggunakan sidik jari tersebut untuk membuka kunci perangkat dan melakukan tugas lainnya. Android menggunakan Fingerprint Hardware Interface Definition Language
(HIDL) untuk terhubung ke library khusus vendor dan hardware sidik jari (misalnya, sensor sidik jari).
Untuk menerapkan Fingerprint HIDL, Anda harus menerapkan IBiometricsFingerprint.hal
di library khusus vendor.
Pencocokan sidik jari
Sensor sidik jari perangkat umumnya dalam kondisi tidak aktif. Namun, sebagai respons terhadap
panggilan ke authenticate atau enroll, sensor sidik jari akan memproses sentuhan (layar juga dapat aktif saat pengguna menyentuh sensor sidik jari). Alur pencocokan sidik jari tingkat tinggi mencakup langkah-langkah berikut:
Pengguna menempelkan jari pada sensor sidik jari.
Library khusus vendor menentukan apakah ada kecocokan sidik jari dalam
kumpulan template sidik jari terdaftar saat ini.
Hasil yang cocok diteruskan ke FingerprintService.
Alur ini mengasumsikan bahwa sidik jari telah didaftarkan di perangkat, yaitu,
library khusus vendor telah mendaftarkan template untuk sidik jari. Untuk mengetahui detail selengkapnya, lihat Autentikasi.
Arsitektur
HAL Sidik Jari berinteraksi dengan komponen berikut.
BiometricManager berinteraksi langsung dengan aplikasi dalam proses aplikasi.
Setiap aplikasi memiliki instance IBiometricsFingerprint.hal
FingerprintService beroperasi di
proses sistem, yang menangani komunikasi dengan HAL sidik jari.
Fingerprint HAL adalah implementasi C/C++ dari
antarmuka IBiometricsFingerprint HIDL. Ini berisi library khusus vendor
yang berkomunikasi dengan hardware khusus perangkat.
Komponen Keystore API dan KeyMint (sebelumnya Keymaster) menyediakan
kriptografi yang didukung hardware untuk penyimpanan kunci yang aman di lingkungan yang aman,
seperti Trusted Execution Environment (TEE).
Gambar 1. Aliran data tingkat tinggi untuk autentikasi sidik jari
Implementasi HAL khusus vendor harus menggunakan protokol komunikasi
yang diperlukan oleh TEE. Gambar mentah dan fitur sidik jari yang diproses tidak boleh diteruskan dalam memori yang tidak tepercaya. Semua data biometrik tersebut harus disimpan
di hardware yang aman seperti TEE. Rooting tidak boleh
membahayakan data biometrik.
FingerprintService dan fingerprintd melakukan panggilan melalui Fingerprint HAL ke
library khusus vendor untuk mendaftarkan sidik jari dan melakukan
operasi lainnya.
Gambar 2. Interaksi daemon sidik jari
dengan library spesifik vendor sidik jari
Panduan penerapan
Panduan Fingerprint HAL berikut dirancang untuk memastikan bahwa data sidik jari tidak bocor dan dihapus saat pengguna dihapus dari perangkat:
Data sidik jari mentah atau turunannya (misalnya, template) tidak boleh
dapat diakses dari luar driver sensor atau TEE. Jika hardware mendukung
TEE, akses hardware harus dibatasi ke TEE dan dilindungi oleh kebijakan
SELinux. Saluran Serial Peripheral Interface (SPI) hanya boleh diakses oleh
TEE dan harus ada kebijakan SELinux eksplisit pada semua file perangkat.
Akuisisi, pendaftaran, dan pengenalan sidik jari harus dilakukan di dalam TEE.
Hanya data sidik jari dalam bentuk terenkripsi yang dapat disimpan di sistem file, meskipun sistem file itu sendiri dienkripsi.
Template sidik jari harus ditandatangani dengan kunci pribadi khusus perangkat.
Untuk Advanced Encryption Standard (AES), minimal template harus ditandatangani
dengan jalur sistem file absolut, grup, dan ID jari sehingga file template
tidak dapat dioperasikan di perangkat lain atau oleh siapa pun selain pengguna yang
mendaftarkannya di perangkat yang sama. Misalnya, menyalin data sidik jari dari pengguna yang berbeda di perangkat yang sama atau dari perangkat lain tidak boleh berfungsi.
Implementasi harus menggunakan jalur sistem file yang disediakan oleh fungsi setActiveGroup() atau menyediakan cara untuk menghapus semua data template pengguna saat pengguna dihapus. Sangat direkomendasikan agar
file template sidik jari disimpan sebagai file terenkripsi dan disimpan di jalur yang diberikan. Jika hal ini tidak dapat dilakukan karena persyaratan penyimpanan TEE, pelaksana harus menambahkan hook untuk memastikan penghapusan data saat pengguna dihapus.
Mengalihkan mesin status HAL untuk memulai
pengumpulan dan penyimpanan template sidik jari. Setelah pendaftaran selesai,
atau setelah waktu tunggu habis, mesin status HAL akan kembali ke status tidak ada aktivitas.
preEnroll()
Membuat token unik untuk menunjukkan awal pendaftaran sidik jari. Memberikan token ke fungsi enroll untuk
memastikan ada autentikasi sebelumnya, misalnya, menggunakan sandi. Untuk mencegah
pemalsuan, token di-wrap setelah kredensial
perangkat dikonfirmasi. Token harus diperiksa selama pendaftaran untuk memverifikasi
bahwa token tersebut masih valid.
getAuthenticatorId()
Menampilkan token yang terkait dengan
kumpulan sidik jari saat ini.
cancel()
Membatalkan operasi pendaftaran atau autentikasi yang tertunda. Mesin status HAL
dikembalikan ke status tidak ada aktivitas.
enumerate()
Panggilan sinkron untuk menghitung semua template sidik jari yang diketahui.
remove()
Menghapus template sidik jari.
setActiveGroup()
Membatasi operasi HAL ke sekumpulan
sidik jari yang termasuk dalam grup tertentu, yang diidentifikasi oleh ID grup
(GID).
authenticate()
Mengautentikasi operasi terkait sidik jari
(diidentifikasi oleh ID operasi).
setNotify()
Mendaftarkan fungsi pengguna yang menerima
notifikasi dari HAL. Jika mesin status HAL dalam keadaan sibuk, fungsi akan diblokir hingga HAL keluar dari keadaan sibuk.
postEnroll()
Menyelesaikan operasi pendaftaran dan membatalkan validasi
tantangan yang dihasilkan preEnroll(). Metode ini harus dipanggil di akhir
sesi pendaftaran multi-jari untuk menunjukkan bahwa tidak ada lagi jari yang dapat ditambahkan.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
