Generic boot partition

In Android 12, the generic boot image, referred to as Generic Kernel Image (GKI), contains the generic ramdisk and the GKI kernel.

For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel.

For upgrading devices that continue to use Android 12 or older kernel versions, the generic ramdisk remains where it was with no requirement for a new init_boot image.

To build a generic ramdisk, move vendor-specific resources out of the ramdisk such that the generic ramdisk contains only first stage init and a property file that contains timestamp information.

On devices that:

Don't use a dedicated recovery partition, all recovery bits move from the generic ramdisk to vendor_boot ramdisk.
Do use a dedicated recovery partition, no change in the recovery ramdisk is needed because the recovery ramdisk is self-contained.

Architecture

The following diagrams illustrate the architecture for devices running Android 12 and higher. Device launching with Android 13 have a new init_boot image containing the generic ramdisk. Devices upgrading from Android 12 to Android 13 use the same architecture as they did with Android 12.

Launch with Android 13, no dedicated recovery

Launch/upgrade device, GKI, no dedicated recovery

Figure 1. Devices launching or upgrading to Android 13, with GKI, no dedicated recovery.

Launch with Android 13, dedicated and A/B recovery (dedicated ramdisk)

Launch/upgrade device, GKI, dedicated and A/B recovery

Figure 2. Devices launching or upgrading to Android 13, with GKI, dedicated and A/B recovery.

Refer to this figure if the device has recovery_a and recovery_b partitions.

Launch with Android 13, dedicated and non-A/B recovery (dedicated ramdisk)

Launch/upgrade device, GKI, dedicated and non-A/B recovery

Figure 3. Devices launching or upgrading to Android 13, with GKI, dedicated and non-A/B recovery.

Refer to this figure if the device has a partition named recovery without a slot suffix.

Launch or upgrade to Android 12, no dedicated recovery

Launch/upgrade device, GKI, no dedicated recovery

Figure 4. Devices launching or upgrading to Android 12, with GKI, no dedicated recovery.

Launch or upgrade to Android 12, dedicated and A/B recovery (dedicated ramdisk)

Launch/upgrade device, GKI, dedicated and A/B recovery

Figure 5. Devices launching or upgrading to Android 12, with GKI, dedicated and A/B recovery.

Refer to this figure if the device has recovery_a and recovery_b partitions.

Launch or upgrade to Android 12, dedicated and non-A/B recovery (dedicated ramdisk)

Launch/upgrade device, GKI, dedicated and non-A/B recovery

Figure 6. Devices launching or upgrading to Android 12, with GKI, dedicated and non-A/B recovery.

Refer to this figure if the device has a partition named recovery without a slot suffix.

Upgrade to Android 12, recovery-as-boot (recovery-as-ramdisk)

Launch/upgrade device, no GKI, recovery-as-boot

Figure 7. Devices upgrading to Android 12, no GKI, recovery-as-boot.

Upgrade to Android 12, dedicated recovery (dedicated ramdisk)

Launch/upgrade device, no GKI, dedicated recovery

Figure 8. Devices upgrading to Android 12, no GKI, dedicated recovery.

Boot images contents

The Android boot images contain the following.

init_boot image added for devices launching with Android 13
- Header version V4
- Generic ramdisk image
Generic boot image
- Header version V3 or V4
  - A boot_signature for GKI boot.img certification (v4 only). The certified GKI boot.img isn't signed for verified boot. OEMs must still sign the prebuilt boot.img with a device-specific AVB key.
  - Generic cmdline (GENERIC_KERNEL_CMDLINE)
  - GKI kernel
- Generic ramdisk image
  - Only included in boot images from Android 12 and earlier
vendor_boot image (for details, see Vendor Boot Partitions)
- vendor_boot header
  - Device-specific cmdline (BOARD_KERNEL_CMDLINE)
- vendor_boot ramdisk image
  - lib/modules
  - Recovery resources (if no dedicated recovery)
- dtb image
recovery image
- Header version V2
  - Device-specific cmdline for recovery, if necessary
  - For non-A/B recovery partition, contents of the header must be standalone; see Recovery Images. For example:
  - cmdline isn't concatenated to boot and vendor_boot cmdline.
  - Header specifies recovery DTBO, if necessary.
  - For A/B recovery partition, contents can be concatenated or inferred from boot and vendor_boot. For example:
  - cmdline is concatenated to boot and vendor_boot cmdline.
  - DTBO can be inferred from vendor_boot header.
- recovery ramdisk image
  - Recovery resources
  - For non-A/B recovery partition, contents of the ramdisk must be standalone; see Recovery Images. For example:
  - lib/modules must contain all kernel modules required to boot recovery mode
  - The recovery ramdisk must contain init.
  - For A/B recovery partition, the recovery ramdisk is prepended to the generic and vendor_boot ramdisk, hence it doesn't need to be standalone. For example:
  - lib/modules might contain only additional kernel modules required to boot recovery mode besides kernel modules in vendor_boot ramdisk.
  - The symlink at /init might exist, but it is overshadowed by the the first-stage /init binary in boot image.

Generic ramdisk image contents

The generic ramdisk contains the following components.

init
system/etc/ramdisk/build.prop
ro.PRODUCT.bootimg.* build props
Empty directories for mount points: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
first_stage_ramdisk/
- Duplicated empty directories for mount points: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Boot image integration

Build flags control how init_boot, boot, recovery, and vendor_boot images are built. The value of a boolean board variable must be the string true or be empty (which is the default).

TARGET_NO_KERNEL. This variable indicates if the build uses a prebuilt boot image. If this variable is set to true, then set BOARD_PREBUILT_BOOTIMAGE to the location of the prebuilt boot image (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img)
BOARD_USES_RECOVERY_AS_BOOT. This variable indicates whether the device uses the recovery image as the boot image. When using GKI, this variable is empty and recovery resources should be moved to vendor_boot.
BOARD_USES_GENERIC_KERNEL_IMAGE. This variable indicates that the board uses GKI. This variable doesn't affect sysprops or PRODUCT_PACKAGES.

This is the board-level GKI switch; all of the following variables are restricted by this variable.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. This variable controls whether ramdisk recovery resources are built to vendor_boot.
- When set to true, recovery resources are built to vendor-ramdisk/ only and aren't built to recovery/root/.
- When empty, recovery resources are built to recovery/root/ only and aren't built to vendor-ramdisk/.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. This variable controls whether GSI AVB keys are built to vendor_boot.
- When set to true, if BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:
  - Is set, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.
  - Is unset, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.
- When empty, if BOARD_RECOVERY_AS_ROOT:
  - Is set, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.
  - Is unset, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/ramdisk/avb.
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. This variable controls whether the recovery image contains a kernel or not. Devices launching with Android 12 and using A/B recovery partition must set this variable to true. Devices launching with Android 12 and using non-A/B must set this variable to false to keep the recovery image self-contained.
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. This variable controls whether $OUT/boot*.img is copied to IMAGES/ under target files.
- aosp_arm64 must set this variable to true.
- Other devices must leave this variable empty.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. This variable controls whether init_boot.img is generated and sets the size. When set, the generic ramdisk is added to the init_boot.img instead of boot.img and requires the BOARD_AVB_INIT_BOOT* variables to be set for chained vbmeta.

Allowed combinations

Component or variable	Upgrade device without recovery partition	Upgrade device with recovery partition	Launch device without recovery partition	Launch device with A/B recovery partition	Launch device with non-A/B recovery partition	aosp_arm64
Contains `boot`	yes	yes	yes	yes	yes	yes
Contains `init_boot` (Android 13)	no	no	yes	yes	yes	yes
Contains `vendor_boot`	optional	optional	yes	yes	yes	no
Contains `recovery`	no	yes	no	yes	yes	no
`BOARD_USES_RECOVERY_AS_BOOT`	`true`	empty	empty	empty	empty	empty
`BOARD_USES_GENERIC_KERNEL_IMAGE`	empty	empty	`true`	`true`	`true`	`true`
`PRODUCT_BUILD_RECOVERY_IMAGE`	empty	`true` or empty	empty	`true` or empty	`true` or empty	empty
`BOARD_RECOVERYIMAGE_PARTITION_SIZE`	empty	> 0	empty	> 0	> 0	empty
`BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT`	empty	empty	`true`	empty	empty	empty
`BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT`	empty	empty	`true`	`true`	`true`	empty
`BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE`	empty	empty	empty	`true`	empty	empty
`BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES`	empty	empty	empty	empty	empty	`true`

Devices with a dedicated recovery partition can set PRODUCT_BUILD_RECOVERY_IMAGE to true or empty. For these devices, if BOARD_RECOVERYIMAGE_PARTITION_SIZE is set, a recovery image is built.

Enable chained vbmeta for boot

Chained vbmeta must be enabled for the boot and init_boot images. Specify the following:

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

For an example, refer to this change.

System-as-root

System-as-root isn't supported for devices that use GKI. On such devices, BOARD_BUILD_SYSTEM_ROOT_IMAGE must be empty. System-as-root also isn't supported for devices that use dynamic partitions.

Product configurations

Devices that use the generic ramdisk must install a list of files that are allowed to be installed to the ramdisk. To do so, specify the following in device.mk:

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

The generic_ramdisk.mk file also prevents other makefiles from accidentally installing other files to the ramdisk (move such files to vendor_ramdisk instead).

Set up devices

Setup instructions differ between devices launching with Android 13, upgrading to Android 12, and launching with Android 12. Android 13, are setup similar to how they were with Android 12

Devices Upgrading to Android 12:
- Can preserve the value of BOARD_USES_RECOVERY_AS_BOOT. If they do so, they're using legacy configs and new build variables must be empty. If such devices:
  - Set BOARD_USES_RECOVERY_AS_BOOT to true, the architecture is as shown in Figure 3.
  - Set BOARD_USES_RECOVERY_AS_BOOT to empty, the architecture is as shown Figure 4.
- Can set BOARD_USES_RECOVERY_AS_BOOT to empty. If they do so, they're using new configurations. If such devices:
  - Don't use a dedicated recovery partition, the architecture is as shown in Figure 1 and the device setup option is Option 1.
  - Use a dedicated recovery partition, the architecture is as shown in Figure 2a or Figure 2b and the device setup option is Option 2a or Option 2b.
Devices launching with Android 12 must set BOARD_USES_RECOVERY_AS_BOOT to empty and use new configurations. If such devices:
- Don't use a dedicated recovery partition, the architecture is as shown in Figure 1 and the device setup option is Option 1.
- Use a dedicated recovery partition, the architecture is as shown in Figure 2a or Figure 2b and the device setup option is Option 2a or Option 2b.

Because aosp_arm64 builds only GKI (and not vendor_boot or recovery), it isn't a complete target. For aosp_arm64build configurations, refer to generic_arm64.

Option 1: No dedicated recovery partition

Devices without a recovery partition contain the generic boot image in the boot partition. The vendor_boot ramdisk contains all recovery resources, including lib/modules (with vendor kernel modules). On such devices, the product configuration inherits from generic_ramdisk.mk.

Set BOARD values

Set the following values:

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

Init binaries and symlinks

The vendor_boot ramdisk can contain an /init to /system/bin/init symlink, and init_second_stage.recovery at /system/bin/init. However, because the generic ramdisk is concatenated after the vendor_boot ramdisk, the /init symlink is overwritten. When the device boots into recovery, the /system/bin/init binary is needed to support second stage init. The contents of vendor_boot + generic ramdisks are as follows:

/init (from generic ramdisk, built from init_first_stage)
/system/bin/init (from vendor_ramdisk, built from init_second_stage.recovery)

Move fstab files

Move any fstab files that were installed to the generic ramdisk to vendor_ramdisk. For an example, refer to this change.

Install modules

You can install device-specific modules to vendor_ramdisk (skip this step if you don't have any device-specific modules to install).

Use the vendor_ramdisk variant of the module when the module installs to the /first_stage_ramdisk. This module should be available after init switches root into /first_stage_ramdisk but before init switches root into /system. For examples, see Metadata checksums and Virtual A/B compression.
Use the recovery variant of the module when the module installs to /. This module should be available before init switches root into /first_stage_ramdisk. For details on installing modules to /, see First stage console.

First stage console

Because the first stage console starts before init switches root into /first_stage_ramdisk, you need to install the recovery variant of modules. By default, both module variants are installed to build/make/target/product/base_vendor.mk, so if the device makefile inherits from that file you don't need to explicitly install the recovery variant.

To explicitly install the recovery modules, use the following.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

This ensures that the linker, sh, and toybox install to $ANDROID_PRODUCT_OUT/recovery/root/system/bin, which then installs to /system/bin under the vendor_ramdisk.

To add modules needed for the first stage console (for example, adbd), use the following.

PRODUCT_PACKAGES += adbd.recovery

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/recovery/root/system/bin, which then installs to /system/bin under the vendor_ramdisk.

Metadata checksums

To support metadata checksums during first stage mount, devices that don't support GKI install the ramdisk variant of the following modules. To add support for GKI, move the modules to $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

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

For an example, refer to this changelist.

Virtual A/B compression

To support virtual A/B compression, snapuserd must be installed to vendor_ramdisk. The device should inherit from virtual_ab_ota/compression.mk, which installs the vendor_ramdisk variant of snapuserd.

Changes to the boot process

The process of booting into recovery or into Android doesn't change, with the following exception:

Ramdisk build.prop moves into /second_stage_resources so that second stage init can read the build timestamp of boot.

Because resources move from generic ramdisk to vendor_boot ramdisk, the result of concatenating generic ramdisk to vendor_boot ramdisk doesn't change.

Make e2fsck available

The device makefiles can inherit from:

virtual_ab_ota/launch_with_vendor_ramdisk.mk if the device supports virtual A/B but not compression.
virtual_ab_ota/compression.mk if the device supports virtual A/B compression.

The product makefiles install $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. At runtime, the first stage init switches root into /first_stage_ramdisk then executes /system/bin/e2fsck.

Option 2a: Dedicated and A/B recovery partition

Use this option for devices with A/B recovery partitions; that is, the device has a recovery_a and recovery_b partition. Such devices include A/B and Virtual A/B devices of which the recovery partition is updateable, with the following configuration:

AB_OTA_PARTITIONS += recovery

The vendor_boot ramdisk contains the vendor bits of the ramdisk and vendor kernel modules, including the following:

Device-specific fstab files
lib/modules (includes vendor kernel modules)

The recovery ramdisk contains all recovery resources. On such devices, the product configuration inherits from generic_ramdisk.mk.

Set BOARD values

Set the following values for devices with A/B recovery partition:

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

Init binaries and symlinks

The recovery ramdisk can contain an /init -> /system/bin/init symlink, and init_second_stage.recovery at /system/bin/init. However, because the boot ramdisk is concatenated after the recovery ramdisk, the /init symlink is overwritten. When the device boots into recovery mode, the /system/bin/init binary is needed to support second stage init.

When the device boots into recovery, the contents of recovery + vendor_boot + generic ramdisks are as follows:

/init (from ramdisk, built from init_first_stage)
/system/bin/init (from recovery ramdisk, built from init_second_stage.recovery, and executed from /init)

When the device boots into Android, the contents of vendor_boot + generic ramdisks are as follows:

/init (from generic ramdisk, built from init_first_stage)

Move fstab files

Move any fstab files that were installed to the generic ramdisk to the vendor_ramdisk. For an example, refer to this change.

Install modules

Optionally, you can install device-specific modules to vendor_ramdisk (skip this step if you don't have any device-specific modules to install). Init doesn't switch root. The vendor_ramdisk variant of modules installs to the root of vendor_ramdisk. For examples on installing modules to vendor_ramdisk, see First stage console, Metadata checksums, and Virtual A/B compression.

First stage console

To install the vendor_ramdisk variant of the modules, use the following:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

This ensures that the linker, sh, and toybox install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, which then installs to /system/bin under the vendor_ramdisk.

To add modules needed for the first stage console (for example, adbd), enable the vendor_ramdisk variant of these modules by uploading relevant patches to AOSP, then use the following,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. If the vendor_boot ramdisk is loaded in recovery mode, the module is also available in recovery. If the vendor_boot ramdisk isn't loaded in recovery mode, the device can optionally install adbd.recovery as well.

Metadata checksums

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

For an example, refer to this changelist.

Virtual A/B compression

To support Virtual A/B compression, snapuserd must be installed to vendor_ramdisk. The device should inherit from virtual_ab_ota/compression.mk, which installs the vendor_ramdisk variant of snapuserd.

Changes to the boot process

When booting into Android, the boot process doesn't change. The vendor_boot + generic ramdisk is similar to the existing boot process, except that fstab loads from vendor_boot. Because system/bin/recovery doesn't exist, first_stage_init handles it as a normal boot.

When booting into recovery mode, the boot process changes. The recovery + vendor_boot + generic ramdisk is similar to the existing recovery process, but the kernel is loaded from the boot image instead of from the recovery image. The boot process for recovery mode is as follows.

Bootloader starts, then does the following:
1. Pushes recovery + vendor_boot + generic ramdisk to /. (If the OEM duplicates kernel modules in recovery ramdisk by adding them to BOARD_RECOVERY_KERNEL_MODULES), vendor_boot is optional.)
2. Runs the kernel from the boot partition.
Kernel mounts ramdisk to / then executes /init from the generic ramdisk.
First stage init starts, then does the following:
1. Sets IsRecoveryMode() == true and ForceNormalBoot() == false.
2. Loads vendor kernel modules from /lib/modules.
3. Calls DoFirstStageMount() but skips mounting because IsRecoveryMode() == true. (The device doesn't free ramdisk (because / is still the same) but does call SetInitAvbVersionInRecovery().)
4. Starts second stage init from /system/bin/init from recovery ramdisk.

Make e2fsck available

The device makefiles can inherit from:

virtual_ab_ota/launch_with_vendor_ramdisk.mk if the device supports virtual A/B but not compression.
virtual_ab_ota/compression.mk if the device supports virtual A/B compression.

The product makefiles install $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. At runtime, the first stage init executes /system/bin/e2fsck.

Option 2b: Dedicated and non-A/B recovery partition

Use this option for devices with a non-A/B recovery partition; that is, the device has a partition named recovery without a slot suffix. Such devices include:

non-A/B devices;
A/B and Virtual A/B devices, of which the recovery partition isn't updateable. (This is unusual.)

The vendor_boot ramdisk contains the vendor bits of the ramdisk and vendor kernel modules, including the following:

Device-specific fstab files
lib/modules (includes vendor kernel modules)

The recovery image must be self-contained. It must contain all required resources to boot the recovery mode, including:

The kernel image
The DTBO image
Kernel modules in lib/modules
First-stage init as a symlink /init -> /system/bin/init
Second-stage init binary /system/bin/init
Device-specific fstab files
All other recovery resources, including the recovery binary

On such devices, the product configuration inherits from generic_ramdisk.mk.

Set BOARD values

Set the following values for non-A/B devices:

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

Init binaries and symlinks

The recovery ramdisk must contain an /init -> /system/bin/init symlink, and init_second_stage.recovery at /system/bin/init. When the device boots into recovery mode, the /system/bin/init binary is needed to support both first stage and second stage init.

When the device boots into recovery, the contents of recovery ramdisks are as follows:

/init -> /system/bin/init (from recovery ramdisk)
/system/bin/init (from recovery ramdisk, built from init_second_stage.recovery, and executed from /init)

When the device boots into Android, the contents of vendor_boot + generic ramdisks are as follows:

/init (from ramdisk, built from init_first_stage)

Move fstab files

Move any fstab files that were installed to the generic ramdisk to the vendor_ramdisk and recovery ramdisk. For an example, refer to this change.

Install modules

You can install device-specific modules to vendor_ramdisk and recovery ramdisk (skip this step if you don't have any device-specific modules to install). init doesn't switch root. The vendor_ramdisk variant of modules installs to the root of vendor_ramdisk. The recovery variant of modules installs to the root of recovery ramdisk. For examples on installing modules to vendor_ramdisk and recovery ramdisk, se First stage console and Metadata checksums.

First stage console

To install the vendor_ramdisk variant of the modules, use the following:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

This ensures that the linker, sh, and toybox install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, which then installs to /system/bin under the vendor_ramdisk.

To add modules needed for the first stage console (for example, adbd), enable the vendor_ramdisk variant of these modules by uploading relevant patches to AOSP, then use the following,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

To install the recovery variant of the modules, replace vendor_ramdisk with recovery:

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

Metadata checksums

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

To support metadata checksums during first stage mount in recovery, enable the recovery variant of these modules and install them as well.

Changes to the boot process

When booting into recovery mode, the boot process doesn't change. The recovery ramdisk is loaded in the same way as the existing recovery process. The kernel is loaded from the recovery image. The boot process for recovery mode is as follows.

Bootloader starts, then does the following:
1. Pushes recovery ramdisk to /.
2. Runs the kernel from the recovery partition.
Kernel mounts ramdisk to / then executes /init, which is a symlink to /system/bin/init from the recovery ramdisk.
First stage init starts, then does the following:
1. Sets IsRecoveryMode() == true and ForceNormalBoot() == false.
2. Loads vendor kernel modules from /lib/modules.
3. Calls DoFirstStageMount() but skips mounting because IsRecoveryMode() == true. (The device doesn't free ramdisk (because / is still the same) but does call SetInitAvbVersionInRecovery().)
4. Starts second stage init from /system/bin/init from recovery ramdisk.

Boot image timestamps

The following code is an example boot image timestamp file:

####################################
# 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

At build time, a system/etc/ramdisk/build.prop file is added to the generic ramdisk. This file contains timestamp information of the build.
At runtime, first stage init copies files from the ramdisk to tmpfs before freeing the ramdisk so that second stage init can read this file to set boot image timestamp properties.