Generic Boot Partition

In Android 12, the generic boot image contains the generic boot ramdisk and generic kernel image (GKI). 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 boot 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.

Launch or upgrade to Android 12, no dedicated recovery

Launch/upgrade device, GKI, no dedicated recovery

Figure 1. 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 2a. Devices launching or upgrading to Android 12, with GKI, dedicated and A/B recovery

Refer to this figure if recovery is A/B; that is, 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 2b. Devices launching or upgrading to Android 12, with GKI, dedicated and non-A/B recovery

Refer to this figure if recovery is not A/B; that is, 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 3. 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 4. Devices upgrading to Android 12, no GKI, dedicated recovery

Boot images contents

In Android 12, boot images contain the following.

  • Generic boot image
    • Header version V3 or V4
      • A boot_signature for GKI boot.img certification (v4 only)
      • Generic cmdline (GENERIC_KERNEL_CMDLINE)
      • Generic kernel image
    • Generic boot ramdisk image
  • 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 is not concatenated to boot and vendor_boot cmdline.
      • Header specifies recovery DTBO, if necessary.
      • For A/B recovery partition, contents may be concatenated or inferred from boot and vendor_boot. For example:
      • cmdline is concatenated to boot and vendor_boot cmdline.
      • DTBO may 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 boot and vendor_boot ramdisk, hence it doesn't need to be standalone. For example:
      • lib/modules may contain only additional kernel modules required to boot recovery mode besides kernel modules in vendor_boot ramdisk.
      • The symlink at /init may exist, but it is overshadowed by the the first-stage /init binary in boot image.

Generic boot ramdisk image contents

In Android 12, the generic boot ramdisk contains the following components.

  • init
  • Added 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/

Board configurations

Build flags control how 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).

  • BOARD_USES_RECOVERY_AS_BOOT. This variable indicates whether the device uses the recovery image as the boot image. When using the 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 and generic boot image. This variable doesn't affect sysprops or PRODUCT_PACKAGES.

    This is the board-level GKI switch; all variables listed below 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.

Allowed combinations

Component or variable Updating device without recovery partition Updating 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 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_RESOURCE_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 image. Specify the following:

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

For an example, refer to this change.

System-as-root

System-as-root isn't supported for devices that use GKI and the generic boot image, regardless of whether the device supports the updatable GKI module. On such devices, BOARD_BUILD_SYSTEM_ROOT_IMAGE must be empty. System-as-root also isn't supported for devices that use dynamic partitions, which is a requirement for the using the updatable GKI module.

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).

Setting up devices

Setup instructions differ between devices updating to Android 12 and launching with Android 12.

  • Devices updating 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 the GKI and generic boot image (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.

Setting 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

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 boot 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 + boot ramdisks are as follows:

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

Moving fstab files

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

Installing modules

If desired, 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 \
    resizefs.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 boot ramdisk to vendor_boot ramdisk, the result of concatenating boot to vendor_boot ramdisk doesn't change.

Making 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.

Setting 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

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 + boot 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 + boot ramdisks are as follows:

  • /init (from ramdisk, built from init_first_stage)

Moving fstab files

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

Installing modules

If desired, 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

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/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resizefs.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 + boot 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 + boot 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.

  1. Bootloader starts, then does the following:

    1. Pushes recovery + vendor_boot + boot 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.
  2. Kernel mounts ramdisk to / then executes /init from the boot ramdisk.

  3. 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.

Making 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 is not 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, etc.
  • etc.

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

Setting 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

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 + boot ramdisks are as follows:

  • /init (from ramdisk, built from init_first_stage)

Moving fstab files

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

Installing modules

If desired, 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

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/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resizefs.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 Android, the boot process doesn't change. The vendor_boot + boot 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 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.

  1. Bootloader starts, then does the following:

    1. Pushes recovery ramdisk to /.
    2. Runs the kernel from the recovery partition.
  2. Kernel mounts ramdisk to / then executes /init, which is a symlink to /system/bin/init from the recovery ramdisk.

  3. 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 boot image 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.