为实现无线下载 (OTA) 更新，引导加载程序必须能够在启动期间访问恢复 RAM 磁盘。如果设备使用未经修改的 AOSP 恢复映像，引导加载程序会读取 misc 分区的前 32 个字节；如果数据与 boot-recovery 匹配，引导加载程序会启动到 recovery 映像。此方法可让所有待处理的恢复工作（例如，应用 OTA 或移除数据）继续完成。
如需详细了解恢复进程与引导加载程序进行通信时所使用的闪存块中的具体信息，请参阅 bootable/recovery/bootloader_message/bootloader_message.h。
使用 A/B 更新的设备
如需在使用 A/B 更新的设备上支持 OTA 更新，请确保设备引导加载程序符合以下条件。
一般条件
通过 OTA 更新的所有分区都应可以在主系统启动时更新（而不是在恢复期间更新）。
为启动
system分区，引导加载程序会在内核命令行中传递以下值：ro root=/dev/[node] rootwait init=/init。Android 框架负责从 HAL 调用
markBootSuccessful。引导加载程序绝不应将分区标记为已成功启动。
对启动控件 HAL 的支持
引导加载程序必须支持 hardware/libhardware/include/hardware/boot_control.h 中定义的 boot_control HAL。更新程序会查询启动控件 HAL，更新未使用的启动槽位，使用 HAL 更改活动槽位，并重新启动进入更新后的操作系统。如需了解详情，请参阅实现启动控件 HAL。
对槽位的支持
引导加载程序必须支持与分区和槽位相关的功能，包括：
分区名称必须包含一个后缀，用于标识哪些分区属于引导加载程序中的特定槽位。对于每个这样的分区，都有一个相应的变量
has-slot:partition base name，其值为yes。槽位按字母顺序命名为 a、b、c 等，与后缀为_a、_b、_c的分区相对应。引导加载程序应通知操作系统使用命令行属性androidboot.slot_suffix启动的槽位。对于发布时搭载 Android 12 或更高版本的设备，此属性通过 bootconfig 进行设置。slot-retry-count值将由启动控件 HAL 通过setActiveBootSlot回调或通过fastboot set_active命令重置为正值（通常为3）。修改属于某个槽位的分区时，引导加载程序会清除“已成功启动”的分区并重置槽位的重试次数。
引导加载程序还应确定要加载的槽位。下图显示的是一个决策过程示例。
确定要尝试加载的槽位。不要尝试加载标记为
slot-unbootable的槽位。此槽位应与 fastboot 返回的值一致，称为当前槽位。如果当前槽位未标记为
slot-successful且具有slot-retry-count = 0，请将当前槽位标记为slot-unbootable。然后选择一个未标记为unbootable而是标记为slot-successful的其他槽位；此槽位现在是选定的槽位。如果没有当前槽位可用，系统会启动到恢复模式或向用户显示一条有意义的错误消息。选择相应的
boot.img，并在内核命令行上添加正确系统分区的路径。填充内核命令行
slot_suffix参数。启动。如果未标记为
slot-successful，请减少slot-retry-count。
fastboot 实用程序确定在运行任何 flash 命令时要刷写的分区。例如，运行 fastboot flash system system.img 命令会首先查询 current-slot 变量，然后将结果连接到系统，以生成应刷写的分区的名称（system_a 和 system_b 等）。
使用 fastboot set_active 命令或启动控件 HAL setActiveBootSlot 命令设置当前槽位时，引导加载程序应更新当前槽位，清除 slot-unbootable 和 slot-successful，并重置重试计数（这是清除 slot-unbootable 的唯一方法）。
不使用 A/B 更新的设备
如需在不使用 A/B 更新的设备上支持 OTA 更新（请参阅非 A/B 更新设备），请确保设备引导加载程序符合以下条件。
recovery分区应包含能够从某些受支持的分区（cache和userdata）读取系统映像并将其写入system分区的映像。引导加载程序应支持直接启动进入恢复模式。
如果支持无线装置映像更新，
recovery分区还应能够刷写无线装置。这可通过以下两种方式之一来完成：引导加载程序刷写无线装置。在这种情况下，应该可以从恢复分区重新启动回引导加载程序以完成更新。
恢复映像刷写无线装置。此功能可以作为二进制库或实用程序提供。