通用 boot 分区

在 Android 12 中，通用 boot 映像（称为通用内核映像 (GKI)）包含通用的 ramdisk 和 GKI 内核。

对于发布时搭载 Android 13 的设备，通用 ramdisk 将从 boot 映像中移除，并放置在单独的 init_boot 映像中。此更改会使 boot 映像仅保留 GKI 内核。

对于继续使用 Android 12 或更低版本内核的升级设备，通用 ramdisk 将保留在原位置，不需要新的 init_boot 映像。

如需构建通用 ramdisk，请将特定于供应商的资源移出 ramdisk，以使通用 ramdisk 仅包含第一阶段 init 以及一个带时间戳信息的属性文件。

不同设备上的处理方式：

  • 在未使用专用 recovery 分区的设备上，请将所有恢复位从通用 ramdisk 移至 vendor_boot ramdisk。

  • 在使用了专用 recovery 分区的设备上，由于 recovery ramdisk 是独立的，因此无需对 recovery ramdisk 进行任何更改。

架构

下图说明了搭载 Android 12 及更高版本的设备的架构。发布时搭载 Android 13 的设备有一个包含通用 ramdisk 的新 init_boot 映像。从 Android 12 升级到 Android 13 的设备使用与 Android 12 相同的架构。

发布时搭载 Android 13 且没有专用 recovery 分区的设备

发布时搭载/升级的设备，具备 GKI，没有专用 recovery 分区

图 1. 发布时搭载或升级到 Android 13、具备 GKI 且没有专用 recovery 分区的设备

发布时搭载 Android 13 且带有专用 A/B recovery 分区（专用 ramdisk）的设备

发布时搭载/升级的设备，具备 GKI，带有专用 A/B recovery 分区

图 2. 发布时搭载或升级到 Android 13、具备 GKI 且带有专用 A/B recovery 分区的设备

如果设备有 recovery_a 和 recovery_b 分区，请参考此图。

发布时搭载 Android 13 且带有专用非 A/B recovery 分区（专用 ramdisk）的设备

发布时搭载/升级的设备，具备 GKI，带有专用非 A/B recovery 分区

图 3. 发布时搭载或升级到 Android 13、具备 GKI 且带有专用非 A/B recovery 分区的设备

如果设备有一个名为 recovery（没有插槽后缀）的分区，请参考此图。

发布时搭载或升级到 Android 12 且没有专用 recovery 分区的设备

发布时搭载/升级的设备，具备 GKI，没有专用 recovery 分区

图 4. 发布时搭载或升级到 Android 12、具备 GKI 且没有专用 recovery 分区的设备

发布时搭载或升级到 Android 12 且带有专用 A/B recovery 分区（专用 ramdisk）的设备

发布时搭载/升级的设备，具备 GKI，带有专用 A/B recovery 分区

图 5. 发布时搭载或升级到 Android 12、具备 GKI 且带有专用 A/B recovery 分区的设备

如果设备有 recovery_a 和 recovery_b 分区，请参考此图。

发布时搭载或升级到 Android 12 且带有专用非 A/B recovery 分区（专用 ramdisk）的设备

发布时搭载/升级的设备，具备 GKI，带有专用非 A/B recovery 分区

图 6. 发布时搭载或升级到 Android 12、具备 GKI 且带有专用非 A/B recovery 分区的设备

如果设备有一个名为 recovery（没有插槽后缀）的分区，请参考此图。

升级到 Android 12 且将 recovery 分区用作 boot 分区 (recovery-as-ramdisk) 的设备

发布时搭载/升级的设备，没有 GKI，将 recovery 分区用作 boot 分区

图 7. 升级到 Android 12、没有 GKI 且将 recovery 分区用作 boot 分区的设备

升级到 Android 12 且带有专用 recovery 分区（专用 ramdisk）的设备

发布时搭载/升级的设备，没有 GKI，带有专用 recovery 分区

图 8. 升级到 Android 12、没有 GKI 且带有专用 recovery 分区的设备

启动映像内容

Android 启动映像包含以下内容。

  • 针对发布时搭载 Android 13 的设备添加了 init_boot 映像

    • 头文件版本 V4
    • 通用 ramdisk 映像

  • 通用 boot 映像

    • 头文件版本 V3 或 V4
      • boot_signature：用于 GKI boot.img 认证（仅限 v4）。经过认证的 GKI boot.img 没有为启动时验证签名。OEM 仍必须使用设备专用的 AVB 密钥为预构建的 boot.img 签名。
      • 通用 cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI 内核
    • 通用 ramdisk 映像
      • 仅包含在 Android 12 及更低版本的 boot 映像中

  • vendor_boot 映像（如需了解详情，请参阅供应商启动分区）

    • vendor_boot 头文件
      • 设备专用 cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot ramdisk 映像
      • lib/modules
      • 恢复资源（如果没有专用 recovery 分区）
    • dtb 映像

  • recovery 映像

    • 头文件版本 V2
      • 在必要时用于恢复的设备专用 cmdline
      • 对于非 A/B recovery 分区，头文件的内容必须保持独立；请参阅恢复映像。例如：
      • cmdline 未串联到 boot 和 vendor_boot cmdline。
      • 如有必要，头文件会指定恢复 DTBO。
      • 对于 A/B recovery 分区，内容可以从 boot 和 vendor_boot 串联或推断出来。例如：
      • cmdline 已串联到 boot 和 vendor_boot cmdline。
      • DTBO 可以通过 vendor_boot 头文件推断出来。
    • recovery ramdisk 映像
      • 恢复资源
      • 对于非 A/B recovery 分区，ramdisk 的内容必须保持独立；请参阅恢复映像。例如：
      • lib/modules 必须包含启动恢复模式 (Recovery mode) 所需的所有内核模块
      • recovery ramdisk 必须包含 init。
      • 对于 A/B recovery 分区，recovery ramdisk 会附加到通用和 vendor_boot ramdisk 的前面，因此不需要保持独立。例如：
      • 除了 vendor_boot ramdisk 中的内核模块之外，lib/modules 可以仅包含启动恢复模式所需的额外内核模块。
      • /init 中的符号链接可能存在，但被启动映像中的第一阶段 /init 二进制文件覆盖了。

通用 ramdisk 映像内容

通用 ramdisk 包含以下组件。

  • init
  • 添加了 system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build 属性
  • 装载点的空目录：debug_ramdisk/、mnt/、dev/、sys/、proc/、metadata/
  • first_stage_ramdisk/
    • 重复的装载点空目录：debug_ramdisk/、mnt/、dev/、sys/、proc/、metadata/

启动映像集成

build 标志用于控制 init_boot、boot、recovery 和 vendor_boot 映像的构建方式。布尔值板级变量的值必须是字符串 true 或为空（后者是默认值）。

  • TARGET_NO_KERNEL：此变量用于指示 build 是否使用预构建的启动映像。如果此变量设为 true，则应将 BOARD_PREBUILT_BOOTIMAGE 设为预构建启动映像的位置 (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img)

  • BOARD_USES_RECOVERY_AS_BOOT：此变量用于指示设备是否将 recovery 映像用作 boot 映像。使用 GKI 时，此变量为空，恢复资源应移至 vendor_boot。

  • BOARD_USES_GENERIC_KERNEL_IMAGE：此变量用于指示该板使用 GKI。它不会影响 sysprop 或 PRODUCT_PACKAGES。

    这是板级 GKI 开关；下面列出的所有变量都受此变量限制。

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT：此变量用于控制 ramdisk 恢复资源是否构建到 vendor_boot。

    • 设置为 true 时，恢复资源仅构建到 vendor-ramdisk/，而不会构建到 recovery/root/。

    • 如果为空，恢复资源仅构建到 recovery/root/，而不会构建到 vendor-ramdisk/。

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT：此变量用于控制 GSI AVB 密钥是否构建到 vendor_boot。

    • 设置为 true 时，如果 BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT：

      • 已设置，GSI AVB 密钥将构建到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb。

      • 未设置，GSI AVB 密钥将构建到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb。

    • 为空时，如果 BOARD_RECOVERY_AS_ROOT：

      • 已设置，GSI AVB 密钥将构建到 $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb。

      • 未设置，GSI AVB 密钥将构建到 $ANDROID_PRODUCT_OUT/ramdisk/avb。

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE：此变量用于控制 recovery 映像是否包含内核。发布时搭载 Android 12 且使用 A/B recovery 分区的设备必须将此变量设置为 true。发布时搭载 Android 12 且使用非 A/B 的设备必须将此变量设置为 false，以使恢复映像保持独立。

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES：此变量用于控制是否将 $OUT/boot*.img 复制到目标文件下的 IMAGES/。

    • aosp_arm64 必须将此变量设置为 true。

    • 其他设备必须将此变量留空。

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE：此变量用于控制是否生成 init_boot.img 以及进行大小设置。设置后，通用 ramdisk 会添加到 init_boot.img（而非 boot.img）中，并会要求为链式 vbmeta 设置 BOARD_AVB_INIT_BOOT* 变量

允许的组合

组件或变量 没有 recovery 分区的升级设备 带有 recovery 分区的升级设备 没有 recovery 分区的发布时搭载设备 带有 A/B recovery 分区的发布时搭载设备 带有非 A/B recovery 分区的发布时搭载设备 aosp_arm64
包含 boot 是 是 是 是 是 是
包含 init_boot (Android 13) 否 否 是 是 是 是
包含 vendor_boot 可选 可选 是 是 是 否
包含 recovery 否 是 否 是 是 否
BOARD_USES_RECOVERY_AS_BOOT true 空 空 空 空 空
BOARD_USES_GENERIC_KERNEL_IMAGE 空 空 true true true true
PRODUCT_BUILD_RECOVERY_IMAGE 空 true，也可为空。 空 true，也可为空。 true，也可为空。 空
BOARD_RECOVERYIMAGE_PARTITION_SIZE 空 > 0 空 > 0 > 0 空
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT 空 空 true 空 空 空
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT 空 空 true true true 空
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE 空 空 空 true 空 空
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES 空 空 空 空 空 true

具有专用 recovery 分区的设备可以将 PRODUCT_BUILD_RECOVERY_IMAGE 设置为 true，也可以设置为空。对于这些设备，如果已设置 BOARD_RECOVERYIMAGE_PARTITION_SIZE，则会构建 recovery 映像。

为启动映像启用链式 vbmeta

必须为 boot 和 init_boot 映像启用链式 vbmeta。指定下列内容：

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

如需查看示例，请参阅此变更。

system-as-root

使用 GKI 的设备不支持 system-as-root。在此类设备上，BOARD_BUILD_SYSTEM_ROOT_IMAGE 必须为空。使用动态分区的设备也不支持 system-as-root。

产品配置

使用通用 ramdisk 的设备必须安装一系列已获准安装到 ramdisk 的文件。为此，请在 device.mk 中指定以下内容：

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

generic_ramdisk.mk 文件还会防止其他 makefile 意外将其他文件安装到 ramdisk（将此类文件移至 vendor_ramdisk）。

设置设备

在发布时搭载 Android 13 的设备、升级到 Android 12 的设备以及发布时搭载 Android 12 的设备上，设置说明有所不同。Android 13 的设置与 Android 12 的设置类似

  • 升级到 Android 12 的设备：

    • 可以保留 BOARD_USES_RECOVERY_AS_BOOT 的值。这样一来，它们将使用旧配置，新的构建变量必须为空。如果此类设备：

      • 将 BOARD_USES_RECOVERY_AS_BOOT 设置为 true，架构将如图 3 所示。

      • 将 BOARD_USES_RECOVERY_AS_BOOT 设置为空，架构将如图 4 所示。

    • 可以将 BOARD_USES_RECOVERY_AS_BOOT 设置为空。这样一来，它们将使用新配置。如果此类设备：

      • 未使用专用 recovery 分区，架构将如图 1 所示，且设备设置选项为选项 1。

      • 使用了专用 recovery 分区，架构将如图 2a 或图 2b 所示，并且设备设置选项为选项 2a 或选项 2b。

  • 发布时搭载 Android 12 的设备必须将 BOARD_USES_RECOVERY_AS_BOOT 设置为空，并使用新配置。如果此类设备：

    • 未使用专用 recovery 分区，架构将如图 1 所示，且设备设置选项为选项 1。

    • 使用了专用 recovery 分区，架构将如图 2a 或图 2b 所示，并且设备设置选项为选项 2a 或选项 2b。

由于 aosp_arm64 仅构建 GKI（而不构建 vendor_boot 或恢复映像），因此它不是一个完整的目标。如需了解 aosp_arm64 build 配置，请参阅 generic_arm64。

选项 1：没有专用 recovery 分区

没有 recovery 分区的设备会在 boot 分区中包含通用 boot 映像。vendor_boot ramdisk 包含所有恢复资源，包括 lib/modules（内有供应商内核模块）。在此类设备上，产品配置继承自 generic_ramdisk.mk。

设置 BOARD 值

设置以下值：

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

vendor_boot ramdisk 可以包含从 /init 到 /system/bin/init 的符号链接，以及位于 /system/bin/init 的 init_second_stage.recovery。不过，由于通用 ramdisk 会在 vendor_boot ramdisk 后串联，因此 /init 符号链接会被覆盖。当设备启动进入恢复模式后，需要使用 /system/bin/init 二进制文件来支持第二阶段 init。vendor_boot + 通用 ramdisk 的内容如下：

  • /init（来自通用 ramdisk，基于 init_first_stage 构建）
  • /system/bin/init（来自 vendor_ramdisk，基于 init_second_stage.recovery 构建）

移动 fstab 文件

将所有已安装到通用 ramdisk 的 fstab 文件移动到 vendor_ramdisk。如需查看示例，请参阅此变更。

安装模块

如果需要，您可以将设备专属模块安装到 vendor_ramdisk（如果您没有任何设备专属模块，请跳过此步骤）。

  • 在模块安装到 /first_stage_ramdisk 后，请使用模块的 vendor_ramdisk 变体。在 init 将根切换到 /first_stage_ramdisk 之后，但在 init 将根切换到 /system 之前，此模块应该可供使用。如需查看示例，请参阅元数据校验和和虚拟 A/B 压缩。

  • 在模块安装到 / 后，请使用模块的 recovery 变体。在 init 将根切换到 /first_stage_ramdisk 之前，此模块应该可供使用。如需详细了解如何将模块安装到 /，请参阅第一阶段控制台。

第一阶段控制台

由于第一阶段控制台在 init 将根切换为 /first_stage_ramdisk 之前启动，因此您需要安装模块的 recovery 变体。默认情况下，两个模块变体都会安装到 build/make/target/product/base_vendor.mk，因此，如果设备 makefile 继承自该文件，您就无需显式安装 recovery 变体。

如需显式安装恢复模块，请使用以下命令。

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

这样可确保 linker、sh 和 toybox 安装到 $ANDROID_PRODUCT_OUT/recovery/root/system/bin，随后安装到 vendor_ramdisk 下的 /system/bin。

如需添加第一阶段控制台所需的模块（例如 adbd），请使用以下命令。

PRODUCT_PACKAGES += adbd.recovery

这样可确保指定的模块安装到 $ANDROID_PRODUCT_OUT/recovery/root/system/bin，随后安装到 vendor_ramdisk 下的 /system/bin。

元数据校验和

为了在第一阶段装载期间支持元数据校验和，不支持 GKI 的设备将安装以下模块的 ramdisk 变体。如需添加对 GKI 的支持，请将模块移至 $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin：

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

如需查看示例，请参阅此变更列表。

虚拟 A/B 压缩

如需支持虚拟 A/B 压缩，必须将 snapuserd 安装到 vendor_ramdisk。设备应继承自 virtual_ab_ota/compression.mk，后者会安装 snapuserd 的 vendor_ramdisk 变体。

启动流程变更

启动进入恢复模式或 Android 的流程不会改变，但以下情况下除外：

  • ramdisk build.prop 移入 /second_stage_resources，以便第二阶段 init 可以读取启动映像的 build 时间戳。

由于资源从通用 ramdisk 移到了 vendor_boot ramdisk，因此将通用 ramdisk 串联到 vendor_boot ramdisk 的结果不会改变。

使 e2fsck 可用

设备 makefile 可以继承自以下各项：

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk（前提是设备支持虚拟 A/B，但不支持压缩）。

  • virtual_ab_ota/compression.mk（前提是设备支持虚拟 A/B 压缩）。

产品 makefile 会安装 $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck。在运行时，第一阶段 init 会将根切换到 /first_stage_ramdisk，然后执行 /system/bin/e2fsck。

选项 2a：专用 A/B recovery 分区

此选项适用于带有 A/B recovery 分区的设备；也就是说，设备带有 recovery_a 和 recovery_b partition。此类设备包括 recovery 分区可更新且具有以下配置的 A/B 设备和虚拟 A/B 设备：

AB_OTA_PARTITIONS += recovery

vendor_boot ramdisk 包含 ramdisk 和供应商内核模块的供应商位，其中包括：

  • 设备专用 fstab 文件

  • lib/modules（包括供应商内核模块）

recovery ramdisk 包含所有恢复资源。在此类设备上，产品配置继承自 generic_ramdisk.mk。

设置 BOARD 值

为带有 A/B recovery 分区的设备设置以下值：

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk 可以包含 /init -> /system/bin/init 符号链接，以及位于 /system/bin/init 的 init_second_stage.recovery。不过，由于 boot ramdisk 会在 recovery ramdisk 后串联，因此 /init 符号链接会被覆盖。当设备启动进入恢复模式后，需要使用 /system/bin/init 二进制文件来支持第二阶段 init。

当设备启动进入 recovery 后，recovery + vendor_boot + 通用 ramdisk 的内容将如下所示：

  • /init（来自 ramdisk，基于 init_first_stage 构建）
  • /system/bin/init（来自 recovery ramdisk，基于 init_second_stage.recovery 构建，并通过 /init 执行）

当设备启动进入 Android 后，vendor_boot + 通用 ramdisk 的内容将如下所示：

  • /init（来自通用 ramdisk，基于 init_first_stage 构建）

移动 fstab 文件

将所有已安装到通用 ramdisk 的 fstab 文件移动到 vendor_ramdisk。如需查看示例，请参阅此变更。

安装模块

如果需要，您可以将设备专属模块安装到 vendor_ramdisk（如果您没有任何设备专属模块，请跳过此步骤）。Init 不会切换根。模块的 vendor_ramdisk 变体将安装到 vendor_ramdisk 的根目录中。如需查看将模块安装到 vendor_ramdisk 的示例，请参阅第一阶段控制台、元数据校验和和虚拟 A/B 压缩。

第一阶段控制台

如需安装模块的 vendor_ramdisk 变体，请使用以下命令：

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

这样可确保 linker、sh 和 toybox 安装到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin，随后安装到 vendor_ramdisk 下的 /system/bin。

如需添加第一阶段控制台所需的模块（例如 adbd），请通过将相关补丁上传到 AOSP 来启用这些模块的 vendor_ramdisk 变体，然后使用以下命令：

PRODUCT_PACKAGES += adbd.vendor_ramdisk

这样可确保指定的模块安装到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin。如果在恢复模式下加载 vendor_boot ramdisk，recovery 中也会提供该模块。如果未在恢复模式下加载 vendor_boot ramdisk，设备还可以选择性地安装 adbd.recovery。

元数据校验和

为了在第一阶段装载期间支持元数据校验和，不支持 GKI 的设备将安装以下模块的 ramdisk 变体。如需添加对 GKI 的支持，请将模块移至 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin：

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

如需查看示例，请参阅此变更列表。

虚拟 A/B 压缩

如需支持虚拟 A/B 压缩，必须将 snapuserd 安装到 vendor_ramdisk。设备应继承自 virtual_ab_ota/compression.mk，后者会安装 snapuserd 的 vendor_ramdisk 变体。

启动流程变更

启动进入 Android 时，启动流程不会更改。vendor_boot + 通用 ramdisk 与现有启动流程类似，不同之处在于 fstab 是从 vendor_boot 加载的。由于 system/bin/recovery 不存在，因此 first_stage_init 会将其作为正常启动进行处理。

启动进入恢复模式时，启动流程会发生变化。recovery + vendor_boot + 通用 ramdisk 与现有恢复流程类似，但内核是从 boot 映像（而不是 recovery 映像）加载的。恢复模式的启动流程如下所述。

  1. 引导加载程序启动，然后执行以下操作：

    1. 将 recovery + vendor_boot + 通用 ramdisk 推送到 /。（如果 OEM 通过将 recovery ramdisk 中的内核模块添加到 BOARD_RECOVERY_KERNEL_MODULES 来复制它们，那么 vendor_boot 是可选的。）
    2. 从 boot 分区运行内核。

  2. 内核将 ramdisk 装载到 /，然后从通用 ramdisk 执行 /init。

  3. 第一阶段 init 启动，然后执行以下操作：

    1. 设置 IsRecoveryMode() == true 和 ForceNormalBoot() == false。
    2. 从 /lib/modules 加载供应商内核模块。
    3. 调用 DoFirstStageMount()，但跳过装载，因为 IsRecoveryMode() == true。（设备不会释放 ramdisk [因为 / 仍然相同]，但会调用 SetInitAvbVersionInRecovery()。）
    4. 从 recovery ramdisk 中的 /system/bin/init 启动第二阶段 init。

使 e2fsck 可用

设备 makefile 可以继承自以下各项：

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk（前提是设备支持虚拟 A/B，但不支持压缩）。

  • virtual_ab_ota/compression.mk（前提是设备支持虚拟 A/B 压缩）。

产品 makefile 会安装 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck。在运行时，第一阶段 init 将执行 /system/bin/e2fsck。

选项 2b：专用非 A/B recovery 分区

此选项适用于带有非 A/B recovery 分区的设备；也就是说，设备有一个名为 recovery（没有插槽后缀）的分区。此类设备包括：

  • 非 A/B 设备；
  • recovery 分区不可更新的 A/B 设备和虚拟 A/B 设备。（这种情况不常见。）

vendor_boot ramdisk 包含 ramdisk 和供应商内核模块的供应商位，其中包括：

  • 设备专用 fstab 文件
  • lib/modules（包括供应商内核模块）

recovery 映像必须保持独立。它必须包含启动恢复模式所需的所有必需资源，包括：

  • 内核映像
  • DTBO 映像
  • lib/modules 中的内核模块
  • 作为符号链接 /init -> /system/bin/init 的第一阶段 init
  • 第二阶段 init 二进制文件 /system/bin/init
  • 设备专用 fstab 文件
  • 其他所有恢复资源，包括 recovery 二进制文件等
  • 等等

在此类设备上，产品配置继承自 generic_ramdisk.mk。

设置 BOARD 值

为非 A/B 设备设置以下值：

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk 必须包含 /init -> /system/bin/init 符号链接，以及位于 /system/bin/init 的 init_second_stage.recovery。当设备启动进入恢复模式后，需要使用 /system/bin/init 二进制文件来支持第一阶段和第二阶段 init。

当设备启动进入 recovery 模式后，recovery ramdisk 的内容将如下所示：

  • /init -> /system/bin/init（来自 recovery ramdisk）
  • /system/bin/init（来自 recovery ramdisk，基于 init_second_stage.recovery 构建，并通过 /init 执行）

当设备启动进入 Android 后，vendor_boot + 通用 ramdisk 的内容将如下所示：

  • /init（来自 ramdisk，基于 init_first_stage 构建）

移动 fstab 文件

将所有已安装到通用 ramdisk 的 fstab 文件移动到 vendor_ramdisk 和 recovery ramdisk。如需查看示例，请参阅此变更。

安装模块

如果需要，您可以将设备专属模块安装到 vendor_ramdisk 和 recovery ramdisk（如果您没有任何设备专属模块，请跳过此步骤）。init 不会切换根。模块的 vendor_ramdisk 变体将安装到 vendor_ramdisk 的根目录中。模块的 recovery 变体将安装到 recovery ramdisk 的根目录中。如需查看将模块安装到 vendor_ramdisk 和 recovery ramdisk 的示例，请参阅第一阶段控制台和元数据校验和。

第一阶段控制台

如需安装模块的 vendor_ramdisk 变体，请使用以下命令：

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

这样可确保 linker、sh 和 toybox 安装到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin，随后安装到 vendor_ramdisk 下的 /system/bin。

如需添加第一阶段控制台所需的模块（例如 adbd），请通过将相关补丁上传到 AOSP 来启用这些模块的 vendor_ramdisk 变体，然后使用以下命令：

PRODUCT_PACKAGES += adbd.vendor_ramdisk

这样可确保指定的模块安装到 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin。

如需安装模块的 recovery 变体，请将 vendor_ramdisk 替换为 recovery：

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

元数据校验和

为了在第一阶段装载期间支持元数据校验和，不支持 GKI 的设备将安装以下模块的 ramdisk 变体。如需添加对 GKI 的支持，请将模块移至 $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin：

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

如需在恢复模式下的第一阶段装载期间支持元数据校验和，请启用这些模块的恢复变体并一并安装。

启动流程变更

启动进入 Android 时，启动流程不会更改。vendor_boot + 通用 ramdisk 与现有启动流程类似，不同之处在于 fstab 是从 vendor_boot 加载的。由于 system/bin/recovery 不存在，因此 first_stage_init 会将其作为正常启动进行处理。

启动进入恢复模式时，启动流程不会更改。recovery ramdisk 的加载方式与现有的恢复流程相同。内核从 recovery 映像加载。恢复模式的启动流程如下所述。

  1. 引导加载程序启动，然后执行以下操作：

    1. 将 recovery ramdisk 推送到 /。
    2. 从 recovery 分区运行内核。

  2. 内核将 ramdisk 装载到 /，然后执行 /init，后者是从 recovery ramdisk 到 /system/bin/init 的符号链接。

  3. 第一阶段 init 启动，然后执行以下操作：

    1. 设置 IsRecoveryMode() == true 和 ForceNormalBoot() == false。
    2. 从 /lib/modules 加载供应商内核模块。
    3. 调用 DoFirstStageMount()，但跳过装载，因为 IsRecoveryMode() == true。（设备不会释放 ramdisk [因为 / 仍然相同]，但会调用 SetInitAvbVersionInRecovery()。）
    4. 从 recovery ramdisk 中的 /system/bin/init 启动第二阶段 init。

启动映像时间戳

以下代码是一个示例 boot 映像时间戳文件。

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • 在构建时，system/etc/ramdisk/build.prop 文件会添加到通用 ramdisk。此文件包含相应 build 的时间戳信息。

  • 在运行时，第一阶段 init 会将文件从 ramdisk 复制到 tmpfs，然后再释放 ramdisk，使第二阶段 init 能够读取此文件，进而设置 boot 映像时间戳属性。