از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
در دستگاه‌های دارای حسگر اثر انگشت، کاربران می‌توانند یک یا چند اثر انگشت را ثبت کنند و از آن اثر انگشت برای باز کردن قفل دستگاه و انجام کارهای دیگر استفاده کنند. اندروید از زبان تعریف رابط سخت‌افزار اثر انگشت (HIDL) برای اتصال به کتابخانه خاص فروشنده و سخت‌افزار اثر انگشت (مثلاً حسگر اثر انگشت) استفاده می‌کند.
برای پیاده سازی Fingerprint HIDL، باید IBiometricsFingerprint.hal در یک کتابخانه خاص فروشنده پیاده سازی کنید.
تطبیق اثر انگشت
سنسور اثر انگشت یک دستگاه معمولاً بیکار است. با این حال، در پاسخ به تماس برای authenticate یا enroll ، حسگر اثر انگشت به لمس گوش می‌دهد (ممکن است وقتی کاربر حسگر اثر انگشت را لمس می‌کند، صفحه نمایش بیدار شود). جریان سطح بالا تطبیق اثر انگشت شامل مراحل زیر است:
کاربر انگشت خود را روی حسگر اثر انگشت قرار می دهد.
کتابخانه خاص فروشنده تعیین می کند که آیا در مجموعه فعلی الگوهای اثر انگشت ثبت شده، مطابقت اثر انگشت وجود دارد یا خیر.
نتایج مطابق به FingerprintService منتقل می شود.
این جریان فرض می‌کند که یک اثر انگشت قبلاً روی دستگاه ثبت شده است، یعنی کتابخانه خاص فروشنده یک الگو برای اثر انگشت ثبت کرده است. برای جزئیات بیشتر، احراز هویت را ببینید.
معماری
اثر انگشت HAL با اجزای زیر تعامل دارد.
BiometricManager به طور مستقیم با یک برنامه در فرآیند برنامه تعامل دارد. هر برنامه یک نمونه از IBiometricsFingerprint.hal دارد
FingerprintService در فرآیند سیستم عمل می کند که ارتباط با اثر انگشت HAL را مدیریت می کند.
Fingerprint HAL یک پیاده سازی C/C++ از رابط IBiometricsFingerprint HIDL است. این شامل کتابخانه خاص فروشنده است که با سخت افزار خاص دستگاه ارتباط برقرار می کند.
مؤلفه‌های Keystore API و KeyMint (که قبلاً Keymaster بود) رمزنگاری سخت‌افزاری را برای ذخیره‌سازی کلید امن در یک محیط امن، مانند Trusted Execution Environment (TEE) فراهم می‌کنند.
شکل 1. جریان داده در سطح بالا برای احراز هویت اثر انگشت
یک پیاده سازی HAL خاص فروشنده باید از پروتکل ارتباطی مورد نیاز یک TEE استفاده کند. تصاویر خام و ویژگی‌های اثر انگشت پردازش شده نباید در حافظه نامعتبر منتقل شوند. تمام این داده های بیومتریک باید در سخت افزار ایمن مانند TEE ذخیره شوند. ریشه یابی نباید بتواند داده های بیومتریک را به خطر بیندازد.
FingerprintService و fingerprintd از طریق Fingerprint HAL با کتابخانه خاص فروشنده تماس می گیرند تا اثر انگشت را ثبت کنند و سایر عملیات را انجام دهند.
شکل 2. تعامل دیمون اثر انگشت با کتابخانه خاص فروشنده اثر انگشت
دستورالعمل های اجرایی
دستورالعمل‌های HAL اثر انگشت زیر طراحی شده‌اند تا اطمینان حاصل شود که داده‌های اثر انگشت درز نمی‌کند و زمانی که کاربر از دستگاه حذف می‌شود حذف می‌شود:
داده های اثر انگشت خام یا مشتقات (مثلاً الگوها) هرگز نباید از خارج از درایور حسگر یا TEE قابل دسترسی باشند. اگر سخت افزار از TEE پشتیبانی می کند، دسترسی سخت افزار باید به TEE محدود شود و توسط یک خط مشی SELinux محافظت شود. کانال رابط محیطی سریال (SPI) باید فقط برای TEE قابل دسترسی باشد و باید یک خط مشی صریح SELinux در همه فایل های دستگاه وجود داشته باشد.
دریافت اثر انگشت، ثبت نام و شناسایی باید در داخل TEE انجام شود.
فقط فرم رمزگذاری شده داده های اثر انگشت را می توان در سیستم فایل ذخیره کرد، حتی اگر خود سیستم فایل رمزگذاری شده باشد.
الگوهای اثر انگشت باید با یک کلید خصوصی و مخصوص دستگاه امضا شوند. برای استاندارد رمزگذاری پیشرفته (AES)، حداقل یک الگو باید با مسیر سیستم فایل مطلق، گروه و شناسه انگشت امضا شود به طوری که فایل‌های الگو در دستگاه دیگری یا برای هر شخصی غیر از کاربری که آنها را در همان دستگاه ثبت کرده است غیرقابل اجرا باشد. به عنوان مثال، کپی کردن داده های اثر انگشت از یک کاربر دیگر در همان دستگاه یا از دستگاه دیگری نباید کار کند.
پیاده سازی ها باید یا از مسیر فایل-سیستم ارائه شده توسط تابع setActiveGroup() استفاده کنند یا راهی برای پاک کردن تمام داده های الگوی کاربر هنگام حذف کاربر ارائه دهند. اکیداً توصیه می شود که فایل های الگوی اثر انگشت به صورت رمزگذاری شده و در مسیر ارائه شده ذخیره شوند. اگر این به دلیل نیازهای ذخیره سازی TEE غیرممکن است، پیاده‌کننده باید قلاب‌هایی اضافه کند تا هنگام حذف کاربر از حذف داده‌ها اطمینان حاصل کند.
دستگاه حالت HAL را برای شروع جمع‌آوری و ذخیره‌سازی الگوی اثر انگشت تغییر می‌دهد. هنگامی که ثبت نام کامل شد، یا پس از یک بازه زمانی، دستگاه حالت HAL به حالت بیکار باز می گردد.
preEnroll()
یک نشانه منحصر به فرد برای نشان دادن شروع ثبت نام اثر انگشت ایجاد می کند. برای اطمینان از احراز هویت قبلی، به عنوان مثال، با استفاده از رمز عبور، یک نشانه برای تابع enroll ارائه می دهد. برای جلوگیری از دستکاری، پس از تأیید اعتبار دستگاه، توکن بسته می شود. رمز باید در حین ثبت نام بررسی شود تا تأیید شود که هنوز معتبر است.
getAuthenticatorId()
یک نشانه مرتبط با مجموعه اثر انگشت فعلی را برمی‌گرداند.
cancel()
عملیات در انتظار ثبت نام یا احراز هویت را لغو می کند. ماشین حالت HAL به حالت بیکار باز می گردد.
enumerate()
تماس همزمان برای شمارش تمام الگوهای اثر انگشت شناخته شده.
remove()
یک الگوی اثر انگشت را حذف می کند.
setActiveGroup()
یک عملیات HAL را به مجموعه‌ای از اثرانگشت که به یک گروه مشخص تعلق دارند، محدود می‌کند که توسط یک شناسه گروه (GID) شناسایی می‌شود.
authenticate()
یک عملیات مربوط به اثر انگشت را تأیید می کند (که با شناسه عملیات شناسایی می شود).
setNotify()
یک تابع کاربری را ثبت می کند که اعلان ها را از HAL دریافت می کند. اگر ماشین حالت HAL در حالت مشغول باشد، تا زمانی که HAL از حالت مشغول خارج شود، عملکرد مسدود می شود.
postEnroll()
عملیات ثبت نام را به پایان می رساند و چالش ایجاد شده preEnroll() باطل می کند. این باید در پایان یک جلسه ثبت نام چند انگشتی فراخوانی شود تا نشان دهد که انگشت دیگری نمی تواند اضافه شود.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
