TG咨询选择安卓运行镜像，先要分清两件事：系统启动时有没有验证镜像，以及运行后能不能向外部证明设备状态。安卓运行镜像可信启动与系统完整性证明机制不是单一开关；硬件、启动链、镜像签名和验证方的要求都影响结果。
先看验证链：启动通过不等于远程可证明
常见基础是 Android Verified Boot（AVB）：设备从受信任的硬件根开始，逐级校验引导程序和系统分区签名，并可用回滚索引阻止降级到已知有风险的旧版本。锁定引导程序、使用受信任签名密钥，是这条链成立的重要条件。
dm-verity则在运行中校验受保护分区的数据块，检测到异常时，设备可能拒绝读取、报错或按配置处理。它能补足启动后的分区完整性检查，但不能单独证明镜像由谁签发，也不能替代完整启动链。若需对外举证，还要看设备是否提供硬件支持的证明，以及服务端如何验证结果。
五种方案：信任从哪里来
| 方案 | 可信基础与证明能力 | 适用条件及限制 |
|---|---|---|
| 原厂量产镜像 | 通常由厂商配置锁定引导程序与AVB；部分设备可提供硬件支持的启动状态。 | 适合直接使用受支持设备的场景。依赖厂商密钥和更新流程，使用者通常不能自行替换系统而仍保持原信任链。 |
| 自建签名镜像 | 组织自行管理签名密钥，可为兼容设备配置AVB及回滚保护。 | 适合有构建、密钥保管和更新能力的团队。密钥泄露、设备未锁定或验证配置错误都会削弱证明力。 |
| GSI通用系统镜像 | 便于在支持Project Treble的设备上验证系统兼容性；可信程度取决于具体镜像签名和设备启动配置。 | 适合开发与兼容性测试。不能仅凭“GSI”名称认定镜像经过某一厂商签名或达到量产设备的证明要求。 |
| Android Emulator系统镜像 | 适合在Android Studio虚拟设备中固定镜像版本、校验下载来源并管理构建产物。 | 适合自动化测试和开发。虚拟设备的信任依赖宿主机及虚拟化环境，不能直接等同于手机SoC硬件根的证明。 |
| 容器化安卓环境 | 以Linux宿主机和容器隔离为主要信任边界；如Waydroid这类方案，验证重点还包括宿主机、容器配置和镜像来源。 | 适合桌面上的安卓应用运行或测试。它不天然具备手机引导程序的AVB链，远程证明需另行设计。 |
按用途选择，按步骤验收
- 先定义证明对象。只需防止分区被静默改写，重点检查AVB和dm-verity；要让远端判断设备状态，则确认是否支持Key Attestation或Play Integrity等接口，并核实服务端实际检查的字段与策略。
- 确认信任根和锁定状态。查设备文档、引导程序状态及镜像签名来源。自建方案还要记录密钥保管、轮换和撤销流程。
- 核对镜像与版本。保存构建版本、签名信息和发布校验值；检查更新是否启用回滚保护。测试镜像不应未经评估直接作为生产信任依据。
- 实际验证失败行为。在专用测试设备或测试环境中按厂商支持的方法检查解锁、签名不匹配和更新后的状态；不要在重要设备上随意刷写或解锁。
对于普通手机应用，优先选择引导程序保持锁定、厂商持续维护且能满足服务端验证要求的量产设备。需要自主管理系统时，选自建签名镜像，并把密钥运维纳入方案；模拟器和容器更适合测试，不宜把它们的隔离能力误当作硬件可信启动。安卓运行镜像可信启动与系统完整性证明机制的选择，最终取决于谁需要验证、验证什么，以及信任根由谁控制。
常见问题
解锁引导程序后，AVB还有效吗？
设备仍可能执行部分校验，但解锁会改变信任状态；是否能满足特定证明要求，须以设备实现和验证方策略为准。
有dm-verity就能证明系统安全无篡改吗？
不能。它主要检查受保护分区的数据完整性，不能独立证明签名身份、设备状态或所有运行时行为。
Play Integrity等于镜像签名证明吗？
不等于。它提供供应用或服务端评估的设备与应用完整性信号，具体结论取决于设备支持和服务端策略。
开发测试选哪一种更方便？
应用开发通常先用Android Emulator；设备兼容性测试可用符合条件的GSI。若要验证硬件启动链，应使用目标实体设备。