从Android 9开始，boot映象的header包含一个字段用于标识header版本号。引导加载程序必须检查header版本号字段，并相应地解析header。通过对boot映象header进行版本编号，可在将来对header进行修改，保持向后兼容性。

旧版本中的unused字段在Android 9之后会转换为header_version字段，Android 9之间版本的boot映象的header版本会被视为0。所有新发布的Android 9设备必须使用v1版本的boot header。所有新发布的Android 10设备必须使用v2版本的boot header。

Android 9在创建boot映象的mkbootimg工具添加了header_version、recovery_dtbo参数用于设置boot映象header版本和recovery dtbo映象的路径。可在BoardConfig.mk中使用BOARD_MKBOOTIMG_ARGS配置这些参数，如：

1

BOARD_MKBOOTIMG_ARGS := --ramdisk_offset $(BOARD_RAMDISK_OFFSET) --tags_offset $(BOARD_KERNEL_TAGS_OFFSET) --header_version $(BOARD_BOOTIMG_HEADER_VERSION)

一、img文件解包

1.1 boot image解包

1.1.1 准备boot解包工具

单编system/core/mkbootimg模块，在out/host/linux-x86/bin/目录会生成mkbootimg和unpack_bootimg可执行文件。
其中mkbootimg可将kernel/dtb/ramdisk打包成boot.img，unpack_bootimg可以将boot.img解包。

1
2

# 单编生成mkbootimg和unpack_bootimg
$ mmm system/core/mkbootimg

也可以直接使用system/core/mkbootimg目录的mkbootimg.py和unpack_bootimg.py脚本来完成打包、解包工作。

一、问题处理思路

1.1 dm-verity问题处理流程

(1)回读整个system分区并与正确的分区进行比较。确认system.img中的数据是否已损坏？若是，则执行步骤2或步骤3。若不是，则执行步骤4。

(2)将mmc / ufs寄给供应商，以检查物理块是否损坏。

(3)擦除分区并下载软件。

(4)做更多的压力测试以验证system.img。如将数据从system复制到userdata分区以加快复制速度。若可以复现该问题，则删除损坏的物理块，请转到步骤3。若不能复现问题，则重复步骤4，或继续观察设备。如果复现问题并重复执行步骤3和步骤4超过 3次，且物理块始终相同，请返回到步骤2。如果物理块并不总是相同，则转到步骤5。

(5)检查dmesg日志，看是否有任何mmc驱动程序/UFS驱动程序故障。如果有，则向mmc/ufs team提交case协助分析。否则执行步骤6。

(6)mmc/ufs硬件/驱动程序基本被排除嫌疑，此时可以从DDR角度进行检查。在此设备上进行Qblizzard压力测试。如果测试结果良好，则执行步骤7。如果测试fail，则向DDR team提交case协助分析。

一、libavb库

1.1 目录结构

libavb库用于在设备端执行所有验证，在代码中的路径是external/avb。其目录结构如下：

(1)libavb：image验证的实现。具有高度可移植性。此代码会兼容C99的C编译器。其中avb_rsa.c/avb_rsa.h和avb_sha.c/avb_sha.h用于内部实现，不应在外部被使用。avb_sysdeps.h用于定义由平台提供的系统依赖项。如果平台提供了标准的C runtime，则可以使用avb_sysdeps_posix.c。

(2)libavb_atx：用于验证public key metadata的Android Things扩展。

(3)libavb_user：用于Android用户空间的AvbOps实现。在boot_control.avb和avbctl中被使用。

(4)libavb_ab：用于bootloader和适用于A/B系统的AVB实现(已于2018年6月1日弃用，必须定义AVB_AB_I_UNDERSTAND_LIBAVB_AB_IS_DEPRECATED才能使用它）。

(5)boot_control：使用libavb_ab 堆栈与bootloader一起使用的Android boot_control HAL的实现（已于2018年6月1日弃用）。

一、使能Verified Boot 1.0

1.1 使能配置

(1)在kernel/msm-4.4/arch/arm64/configs/$project_defconfig中打开dm-verity功能：

1
2

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

一、VBMeta结构

AVB中使用的核心数据结构是VBMeta结构。该数据结构包含许多描述符和元数据，并且所有这些数据都会经过密钥签名。描述符用于映像哈希（image hash）、映像哈希树元数据（image hashtree metadata）和所谓的链接分区（chain partitions）。下图是一个简单的VBMeta结构：

一、Verified Boot简介

Verified Boot是Google为Android启动定义的一种安全机制。它建立了一条从受硬件保护的Root of trust到booloader，再到boot和其它验证分区（包括system、vendor、product、odm等）的完整信任链。在设备启动的过程中，无论处于哪个阶段，都会在进入下一个阶段前先验证下一个阶段的完整性和真实性。除了确保设备运行的是安全的Android系统以外，verified boot还支持回滚保护（anti-roll back），它可以保证设备只会更新到更高版本，以避免可能的漏洞持续存在。另外，verified boot还允许设备将其完整性传到给终端用户。

要想使能verified boot，需要在编译系统中启用dm-verity功能。Android 4.4就增加了对验证启动和 dm-verity 内核功能的支持。以前的Android版本会在发现设备损坏时向用户发出警告，但仍允许他们启动设备。从Android 7.0 开始，系统会严格强制执行verified boot，从而使得遭到入侵的设备无法启动，与此同时还增加了对向前纠错功能的支持，能更可靠地防范非恶意数据损坏。Android 8.0及更高版本包含了 Android Verified Boot (AVB)功能。其实AVB就是验证启动的一个参考实现，可与 Project Treble 配合使用。除此之外，AVB 还对分区脚本格式进行了标准化处理，并增添了回滚保护功能。为了便于区分，我们一般将此之前的verified boot称为1.0版，而AVB专指verified boot 2.0版。

一、概述

Android 10引入了UDC（user data checkpoint）功能，该功能允许Android在OTA升级失败时回滚到之前的状态。虽然A/B updater能解决早期启动失败回滚问题，但在userdata分区（/data）发生变化的情况下，仍无法支持回滚。有了UDC，即使userdata分区发生了变化，设备仍能将其还原。UDC功能通过文件系统的checkpoint功能来实现这一点。当文件系统不支持checkpoint时，UDC可作为替代实现方式，与bootloader的A/B机制集成，同时还支持Non-A/B升级以及key版本绑定和密钥防回滚。

UDC功能还可以提升用户的OTA升级体验，因为当OTA升级失败时，丢失数据的用户数量减少了。这可以减少用户因升级过程遇到问题而拨打售后支持电话的次数。但是，当OTA升级失败时，用户可能会注意到设备会重启多次。

一、DSU概述

动态系统升级（Dynamic System Updates）允许制作Android系统映像，用户可以从互联网上下载并试用，而不会有损坏当前系统映像的风险。DSU依赖于dm-verity来验证系统映像，所以必须打开kernel config中以下两个Config：

1
2

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

一、概述

Android 10通过将fastboot从bootloader转移到用户空间，增加了对可调整大小分区的支持。此重定位使得可以将代码移动和烧录到可维护且可测试的公共位置，其中仅由HAL实现fastboot的vendor专属部分。