總覽
使用者只要看著裝置正面，即可透過臉部驗證解鎖裝置。Android 10 新增了臉部辨識堆疊的支援功能，可安全處理攝影機影格，在支援的硬體上進行臉部辨識時，確保安全性和隱私權。Android 10 也為符合安全性規範的實作方式提供簡單方法，可啟用應用程式整合功能，用於處理交易，例如線上銀行或其他服務。
Android 臉部驗證堆疊是 Android 10 中的新實作項目。新的實作會導入 IBiometricsFace.hal、IBiometricsFaceClientCallback.hal 和 types.hal 介面。
建築
BiometricPrompt API 包含所有生物特徵辨識驗證，包括臉部、手指和鳶尾花。Face HAL 會與下列元件互動。
圖 1. 生物特徵辨識堆疊。
FaceManager
FaceManager 是私人介面，用來維持與 FaceService 的連線。Keyguard 會使用這個類別，透過自訂 UI 存取臉部驗證功能。應用程式無法存取 FaceManager，因此必須改用 BiometricPrompt。
FaceService
這種架構實作方式可管理臉孔驗證硬體存取權。其中包含基本的註冊和驗證狀態機器，以及各種其他輔助程式 (例如列舉)。基於穩定性和安全性考量，這個程序不允許執行任何供應商程式碼。所有供應商程式碼皆可透過 Face 1.0 HIDL 介面存取。
面臨
這是 Linux 可執行檔，可實作 FaceService 使用的 Face 1.0 HIDL 介面。將其註冊為 IBiometricsFace@1.0，以便 FaceService 找到。
實作
臉部 HIDL
如要實作 Face HIDL，您必須在供應商專屬程式庫中實作 IBiometricsFace.hal 的所有方法。
錯誤訊息
錯誤訊息會透過回呼傳送，並在傳送後將狀態機器傳回至「idle」狀態。大多數訊息都有對應的使用者端字串，可向使用者說明錯誤，但並非所有錯誤都有這個使用者端字串。如要進一步瞭解錯誤訊息，請參閱 types.hal。所有錯誤訊息都代表終端狀態，也就是說，架構會假設 HAL 在傳送錯誤訊息後會返回空閒狀態。
獲客訊息
獲取訊息會在註冊或驗證期間傳送，目的是引導使用者成功註冊或驗證。每個序數都有來自 FaceAuthenticationManager.java 檔案的相關訊息。只要提供對應的說明字串，即可新增特定供應商的訊息。獲取訊息本身並非終端機狀態，因此 HAL 預計會視需要傳送這類訊息來完成目前的註冊或驗證作業。如果擷取訊息導致無法取得任何進展的終端狀態，HAL 就應在擷取訊息後附上錯誤訊息，例如圖片太暗且持續處於太暗狀態，無法取得任何進展。在這種情況下，您可以在嘗試多次嘗試後傳送 UNABLE_TO_PROCESS，但無法進一步進度。
硬體
為符合 Android 10 的高強度生物特徵辨識規定，裝置必須具備安全的硬體，才能確保臉孔資料的完整性，以及最終的驗證比較結果。Android 相容性定義說明文件 (CDD) 概略說明所需的安全性級別，以及所需的假冒接受率 (SAR)。需要信任的執行環境 (TEE) 才能安全地進行處理及辨識作業。此外，您必須使用安全的相機硬體，才能防止臉部驗證遭到注入攻擊。舉例來說，圖片資料的相關記憶體頁面可設為特權，並標示為唯讀，這樣只有攝影機硬體才能更新這些頁面。理想情況下，除了 TEE 和硬體，其他程序都應無法存取。
由於臉孔驗證硬體的差異相當大，因此您必須根據特定裝置架構，開發硬體專屬的驅動程式，才能啟用臉孔驗證功能。因此 faced 沒有參照實作。
方法
下列方法皆為非同步，必須立即傳回至架構。否則系統會變慢，且可能會重設 Watchdog。建議您使用多個執行緒的訊息佇列，以免阻斷呼叫端。所有 GET 要求都應盡可能快取資訊，以便將呼叫端的封鎖時間降至最低。
| 方法 | 說明 |
|---|---|
setCallback() |
由 FaceService 呼叫，用於將所有訊息回傳至自身。 |
setActiveUser() |
設定有效使用者，並套用所有後續 HAL 作業。除非再次呼叫此方法，否則系統一律會對這位使用者進行驗證。 |
revokeChallenge() |
透過讓 generateChallenge() 產生的挑戰失效，完成安全交易。 |
enroll() |
註冊使用者的臉孔。 |
cancel() |
取消目前的作業 (例如註冊、驗證、移除或列舉)，並將 faced 傳回閒置狀態。 |
enumerate() |
列舉與活躍使用者相關聯的所有臉孔範本。 |
remove() |
移除與使用者相關聯的人臉模板或所有人臉模板。 |
authenticate() |
驗證活躍使用者。 |
userActivity() |
只有在 HAL 處於驗證或待機狀態時，才應使用此方法。如果 HAL 不在上述任一狀態，使用這個方法會傳回 OPERATION_NOT_SUPPORTED。如果在 HAL 已進行驗證時呼叫此方法，系統尋找臉孔的時間可能會延長。 |
resetLockout() |
如果錶面遭到拒絕的次數過多，faced 就必須進入鎖定狀態 (LOCKOUT 或 LOCKOUT_PERMANENT)。在這種情況下，faced 必須將剩餘時間傳送至架構，以便向使用者顯示。與 setFeature() 一樣，這個方法需要有效的硬體驗證權杖 (HAT)，才能安全地重設內部狀態。「僅」為目前的使用者重設鎖定功能。 |
剩下的三種方法都是同步的，應只阻斷最少的時間，以免延遲架構。
| 方法 | 說明 |
|---|---|
generateChallenge() |
產生不重複的加密編譯隨機權杖，用來表示安全交易的啟動。 |
setFeature() |
為目前使用者啟用或停用功能。為了安全起見，這需要 HAT 根據上述驗證問題檢查使用者的 PIN 碼/解鎖圖案/密碼 |
getFeature() |
擷取功能目前的啟用狀態 (由預設或上述 setFeature() 呼叫)。如果 Face ID 無效，實作項目必須傳回 ILLEGAL_ARGUMENT |
getAuthenticatorId() |
傳回與目前臉孔集相關聯的 ID。 每當新增臉孔時，這個 ID 必須變更 |
狀態圖表
架構預期 faced 會遵循下方的狀態圖表。
圖 2. 臉孔驗證狀態流程。