深入理解gatekeeperd 与 android.hardware.gatekeeper@1.0-service调用规则

gatekeeperd 与 android.hardware.gatekeeper@1.0-service 的协同工作流程可以概括为：锁屏应用请求 -> 系统服务分发 -> gatekeeperd 协议处理 -> HAL 服务中转 -> TEE 安全执行。

整个调用流程在下图中有完整的呈现，你可以先通过它建立整体认识：
渲染错误: Mermaid 渲染失败: Parse error on line 2: ... subgraph A 普通世界 (Android 系统) -----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

🔍 流程详解与关键代码

上图的每一步都对应着具体的代码模块：

• 流程1与2：从应用到 gatekeeperd

  当你在锁屏界面输入密码或进行相关设置时，请求会通过 LockSettingsService 这个系统服务，经由 Binder IPC 传递给 gatekeeperd 守护进程。

  • LockSettingsService 代码位于：frameworks/base/services/core/java/com/android/server/locksettings/
  • gatekeeperd 的主要实现在：system/core/gatekeeperd/gatekeeperd.cpp。它在这里接收 Binder 请求，并准备调用 HAL。

• 流程3：gatekeeperd 调用 HAL 服务
  gatekeeperd 通过 HIDL （旧版本）或 AIDL （新版本）接口，调用到 android.hardware.gatekeeper@1.0-service 这个 HAL 服务实现。

  • HAL 接口定义是标准化的，关键函数是 enroll（注册密码） 和 verify（验证密码） 。gatekeeperd 会调用它们。
  • HAL 服务的代码由芯片厂商或设备制造商提供，通常在 vendor/ 目录下。

• 流程4：HAL 服务与 TEE 通信

  HAL 服务作为"信使"，其核心职责是将验证请求通过 安全的 IPC 机制 （例如 Trusty IPC）传递到 TEE 安全世界中。

  • 它通过 tipc_connect 等函数连接到 TEE 中的特定端口（如 "com.android.trusty.gatekeeper"），建立安全通道。
  • 然后，将密码的哈希值等数据发送到 TEE。

• TEE 内部与返回流程

  TEE 内部有一个安全的 Gatekeeper 应用（如 Trusty Gatekeeper），它使用硬件保护的密钥进行真正的密码验证计算。验证完成后：

  1. TEE 生成一个经过签名的 身份验证令牌 ，并沿原路（HAL服务 -> gatekeeperd）返回。
  2. gatekeeperd 将这个令牌转发给 Keystore 服务，后者会用它来授权释放那些受用户身份认证保护的加密密钥。

💡 进阶调试与学习

• 定位代码 ：你可以在 AOSP 源码中，通过 find . -name "*gatekeeper*" -type f 命令快速搜索相关文件。
• 动态调试 ：在已取得 Root 权限的调试设备上，你可以使用 logcat | grep -i gatekeeper 过滤日志，观察实时的调用过程。也可以使用 ps -A | grep gatekeeper 来确认这两个进程是否在运行。
• 架构演进 ：在 Android 13 (T) 及之后版本，Google 正推动 HAL 模块从 HIDL 全面转向 AIDL 。因此，在新代码中你可能会看到 android.hardware.gatekeeper.IGatekeeper 这样的 AIDL 接口名称，但组件间的分层架构和调用逻辑基本不变。