单编system/core/mkbootimg模块，在out/host/linux-x86/bin/目录会生成mkbootimg和unpack_bootimg可执行文件。
其中mkbootimg可将kernel/dtb/ramdisk打包成boot.img，unpack_bootimg可以将boot.img解包。
1 | # 单编生成mkbootimg和unpack_bootimg |
也可以直接使用system/core/mkbootimg目录的mkbootimg.py和unpack_bootimg.py脚本来完成打包、解包工作。
(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库用于在设备端执行所有验证，在代码中的路径是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是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升级失败时，用户可能会注意到设备会重启多次。
动态分区（Dynamic Partition）是Android的用户空间分区系统。使用此分区系统，可以在OTA升级期间创建、调整分区大小或删除分区。使用动态分区，厂商不需要再担心分区的单个大小，如system，vendor和product。相反，设备会被分配一个super分区，并且可以在其中动态调整子分区的大小。各个分区映像不再需要为将来的OTA升级预留空间。相反，super中的剩余可用空间可用于所有动态分区。
