總覽
使用者只要看著裝置正面，即可透過臉部驗證解鎖裝置。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 找到它。
實作
Face 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)。在這種情況下，系統必須將剩餘時間傳送至架構，以便向使用者顯示。與 setFeature() 一樣，這個方法需要有效的硬體驗證權杖 (HAT)，才能安全地重設內部狀態。只會為目前使用者重設鎖定狀態。 |
剩下的三種方法都是同步的，應只阻斷最少的時間，以免使架構停滯。
| 方法 | 說明 |
|---|---|
generateChallenge() |
產生專屬且安全的隨機權杖，用於表示安全交易的開始。 |
setFeature() |
為目前使用者啟用或停用功能。基於安全考量，HAT 必須根據上述驗證碼，檢查使用者的 PIN 碼/解鎖圖案/密碼 |
getFeature() |
擷取功能目前的啟用狀態，這取決於預設值或上述對 setFeature() 的呼叫。如果 Face ID 無效，實作項目必須傳回 ILLEGAL_ARGUMENT |
getAuthenticatorId() |
傳回與目前面孔組合相關聯的 ID。每當新增臉孔時，這個 ID 必須變更 |
狀態圖表
架構預期 faced 會遵循下方的狀態圖表。
圖 2. 臉部驗證狀態流程。