我来帮你梳理一下关于AVB（Android Verified Boot）异常检测的相关问题，结合官方文档的内容给你清晰的解答：

一、开机阶段怎么检测AVB异常并通知系统？ #

AVB的核心验证逻辑是在bootloader阶段跑的——它会挨个验证boot、recovery、system这些关键分区的签名和完整性。

• 如果检测到异常（比如分区被篡改、签名无效），它会根据设备的锁状态（已上锁/解锁）触发不同行为：
  • 已上锁的设备：通常直接拒绝启动，停在bootloader界面并显示明确的错误提示；
  • 解锁的设备：可能允许启动，但会把异常状态标记下来。
• 怎么把状态传给系统？AVB会通过bootloader传递的启动参数（比如avb_slot_verify_result）把验证结果给到内核和init进程。init进程拿到后，会把状态写入系统属性，比如ro.boot.avb.verify_result，后续系统服务就能通过读取这些属性来判断AVB是不是正常启动了。

二、应用程序能检测AVB的运行状态吗？ #

这得分情况看：

• 普通第三方应用：受Android权限模型限制，根本碰不到AVB相关的敏感系统属性——要读这些属性需要READ_PRIVILEGED_PHONE_STATE权限，这个权限只有系统应用或者经过特殊签名的特权应用才能拿到，所以普通APP没办法直接检测AVB状态。
• 系统/特权应用：如果是拥有足够权限的系统应用，就可以通过读取系统属性来获取AVB的验证结果，比如读ro.boot.avb.verify_result或者ro.boot.avb.has_verity这些属性值，以此判断AVB有没有正常执行。

三、具体该在哪些位置检测AVB是否正常？ #

主要有四个关键阶段：

1. Bootloader阶段：这是AVB做验证的核心阵地，所有分区的完整性、签名验证都在这里完成，异常会直接在这里触发（比如启动失败、弹出错误提示）。
2. 内核/init进程阶段：init进程会读取bootloader传过来的AVB结果，写入系统属性，还能根据结果调整系统初始化逻辑（比如验证失败就限制某些敏感功能）。
3. 系统服务阶段：像SystemServer这类系统服务，可以读取系统属性里的AVB状态，用来执行后续的安全策略，比如禁止高风险操作。
4. 特权应用阶段：有权限的系统应用可以在运行时读取相关属性，要么把状态展示给用户，要么用在自身的安全逻辑里。

根据AVB官方文档说明，AVB的验证结果会通过bootloader启动参数传递到用户空间，系统通过属性系统暴露这些信息，供特权组件使用。

内容的提问来源于stack exchange，提问作者Shadow