汎用ブートパーティション

Android 12 では、汎用bootイメージに汎用boot RAM ディスクと汎用カーネル イメージ (GKI)が含まれています。汎用 ramdisk を構築するには、ベンダー固有のリソースを ramdisk から移動して、汎用 ramdisk に最初の段階のinitとタイムスタンプ情報を含むプロパティ ファイルのみが含まれるようにします。

次のデバイスで:

  • 専用のrecoveryパーティションを使用しないでください。すべてのリカバリ ビットは、ブート RAM ディスクからvendor_boot RAM ディスクに移動します。

  • 専用のrecoveryパーティションを使用してください。 recovery recoveryディスクを変更する必要はありません。

建築

次の図は、Android 12 を実行するデバイスのアーキテクチャを示しています。

Android 12 の起動またはアップグレード、専用のリカバリなし

デバイスの起動/アップグレード、GKI、専用のリカバリなし

図 1. Android 12 を起動またはアップグレードするデバイス、GKI を使用、専用のリカバリなし

Android 12 の起動またはアップグレード、専用および A/B リカバリ (専用 RAM ディスク)

デバイス、GKI、専用および A/B リカバリの起動/アップグレード

図 2a。 GKI、専用および A/B リカバリを使用して、Android 12 を起動またはアップグレードするデバイス

recoveryが A/B の場合は、この図を参照してください。つまり、デバイスにはrecovery_aおよびrecovery_bパーティションがあります。

Android 12 の起動またはアップグレード、専用および非 A/B リカバリ (専用 RAM ディスク)

デバイス、GKI、専用および非 A/B リカバリの起動/アップグレード

図 2b。 GKI、専用および非 A/B リカバリを使用して、Android 12 を起動またはアップグレードするデバイス

recoveryが A/B でない場合は、この図を参照してください。つまり、デバイスには、スロット サフィックスのないrecoveryという名前のパーティションがあります。

Android 12 へのアップグレード、recovery-as-boot (recovery-as-ramdisk)

デバイスの起動/アップグレード、GKI なし、起動時のリカバリ

図 3. Android 12 にアップグレードするデバイス、GKI なし、recovery-as-boot

Android 12 へのアップグレード、専用リカバリ (専用 RAM ディスク)

デバイスの起動/アップグレード、GKI なし、専用リカバリ

図 4. Android 12 にアップグレードするデバイス、GKI なし、専用リカバリ

ブート イメージの内容

Android 12 では、ブート イメージには次のものが含まれます。

  • 汎用bootイメージ
    • ヘッダー バージョンV3またはV4
      • boot_signature boot.img 証明書の boot_signature (v4 のみ)。認定された GKI のboot.imgは、検証済みの起動用に署名されていません。 OEM は、デバイス固有のAVBキーを使用して、ビルド済みのboot.imgに署名する必要があります。
      • 汎用cmdline ( GENERIC_KERNEL_CMDLINE )
      • 汎用カーネル イメージ
    • 汎用boot RAM ディスク イメージ
  • vendor_bootイメージ (詳細については、「ベンダー ブート パーティション」を参照してください)
    • vendor_bootヘッダー
      • デバイス固有のBOARD_KERNEL_CMDLINE cmdline
    • vendor_boot ramdisk イメージ
      • lib/modules
      • 回復リソース (専用の回復がない場合)
    • dtb画像
  • recoveryイメージ
    • ヘッダー バージョン V2
      • 必要に応じて、リカバリ用のデバイス固有のcmdline
      • 非 A/B リカバリ パーティションの場合、ヘッダーの内容はスタンドアロンである必要があります。リカバリ イメージを参照してください。例えば：
      • cmdlineはbootおよびvendor_boot cmdlineに連結されません。
      • ヘッダーは、必要に応じて回復 DTBO を指定します。
      • A/B リカバリ パーティションの場合、内容はbootおよびvendor_bootから連結または推測される場合があります。例えば：
      • cmdlineはbootおよびvendor_boot cmdlineに連結されます。
      • DTBO はvendor_bootヘッダーから推測される場合があります。
    • recovery RAM ディスク イメージ
      • 回復資源
      • 非 A/B リカバリ パーティションの場合、RAM ディスクの内容はスタンドアロンである必要があります。リカバリ イメージを参照してください。例えば：
      • lib/modulesには、回復モードで起動するために必要なすべてのカーネル モジュールが含まれている必要があります
      • リカバリ RAM ディスクにはinitが含まれている必要があります。
      • A/B リカバリ パーティションの場合、リカバリ ramdisk はbootおよびvendor_boot ramdisk の先頭に追加されるため、スタンドアロンである必要はありません。例えば：
      • lib/modulesには、 vendor_boot ramdisk 内のカーネル モジュール以外に、回復モードを起動するために必要な追加のカーネル モジュールのみが含まれる場合があります。
      • /initのシンボリック リンクは存在する可能性がありますが、ブート イメージの第 1 段階の/initバイナリによって影が薄くなります。

汎用ブート RAM ディスク イメージの内容

Android 12 では、汎用boot RAM ディスクに次のコンポーネントが含まれています。

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

ブート イメージの統合

ビルド フラグは、 boot 、 recovery 、およびvendor_bootイメージのビルド方法を制御します。ブール ボード変数の値は、文字列trueまたは空 (デフォルト) である必要があります。

  • TARGET_NO_KERNEL 。この変数は、ビルドがビルド済みのブート イメージを使用するかどうかを示します。この変数が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 と汎用bootイメージを使用することを示します。この変数は、sysprops または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に設定する必要があります。

    • 他のデバイスは、この変数を空のままにしておく必要があります。

許可された組み合わせ

コンポーネントまたは変数recoveryパーティションなしでデバイスを更新するrecoveryパーティションでデバイスを更新していますrecoveryパーティションなしでデバイスを起動するA/B recoveryパーティションを使用してデバイスを起動する非 A/B recoveryパーティションでデバイスを起動するaosp_arm64
bootを含むはいはいはいはいはいはい
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_RESOURCE_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 を有効にする

チェーンされた vbmeta は、 bootイメージに対して有効にする必要があります。以下を指定します。

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

例については、この変更を参照してください。

ルートとしてのシステム

System-as-root は、デバイスが更新可能な GKI モジュールをサポートしているかどうかに関係なく、GKI と汎用ブート イメージを使用するデバイスではサポートされていません。このようなデバイスでは、 BOARD_BUILD_SYSTEM_ROOT_IMAGEを空にする必要があります。 System-as-root は、動的パーティションを使用するデバイスでもサポートされていません。これは、更新可能な GKI モジュールを使用するための要件です。

製品構成

汎用 RAM ディスクを使用するデバイスは、RAM ディスクへのインストールが許可されているファイルのリストをインストールする必要があります。これを行うには、 device.mkで次のように指定します。

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

また、 generic_ramdisk.mkファイルは、他の makefile が誤って他のファイルを ramdisk にインストールするのを防ぎます (そのようなファイルをvendor_ramdiskに移動してください)。

デバイスのセットアップ

Android 12 にアップデートするデバイスと 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 と汎用bootイメージのみをビルドするため ( vendor_bootやリカバリはビルドしない)、完全なターゲットではありません。 aosp_arm64ビルド構成については、 generic_arm64を参照してください。

オプション 1: 専用の回復パーティションなし

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を含めることができます。ただし、 boot ramdisk はvendor_boot ramdisk の後に連結されるため、 /initシンボリック リンクは上書きされます。デバイスが回復モードで起動するとき、第 2 段階の初期化をサポートするために/system/bin/initバイナリが必要です。 vendor_boot + boot ramdisks の内容は次のとおりです。

  • /init (ramdisk から、 init_first_stageからビルド)
  • /system/bin/init ( vendor_ramdisk から、 vendor_ramdiskからinit_second_stage.recovery )

fstab ファイルの移動

boot RAM ディスクにインストールされたfstabファイルをvendor_ramdiskに移動します。例については、この変更を参照してください。

モジュールのインストール

必要に応じて、デバイス固有のモジュールをvendor_ramdiskにインストールできます (インストールするデバイス固有のモジュールがない場合は、この手順をスキップしてください)。

  • モジュールを/first_stage_ramdiskにインストールするときに、モジュールのvendor_ramdiskバリアントを使用します。このモジュールは、 initが root を/first_stage_ramdiskに切り替えた後、 initが root を / /systemに切り替える前に使用できるはずです。例については、メタデータ チェックサムと仮想 A/B 圧縮を参照してください。

  • モジュールを/にインストールする場合は、モジュールのrecoveryバリアントを使用します。このモジュールは、 initがルートを/first_stage_ramdiskに切り替える前に使用可能にする必要があります。モジュールを/にインストールする方法の詳細については、 First stage consoleを参照してください。

初段コンソール

initが root を/first_stage_ramdiskに切り替える前に第 1 ステージのコンソールが起動するため、モジュールの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にインストールされます。

第 1 段階のコンソール (adbd など) に必要なモジュールを追加するには、次を使用します。

PRODUCT_PACKAGES += adbd.recovery

これにより、指定されたモジュールが確実に$ANDROID_PRODUCT_OUT/recovery/root/system/binにインストールされ、それがvendor_ramdiskの下の/system/binにインストールされます。

メタデータ チェックサム

第 1 段階のマウント中にメタデータ チェックサムをサポートするために、GKI をサポートしていないデバイスは、次のモジュールの ramdisk バリアントをインストールします。 GKI のサポートを追加するには、モジュールを$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/binに移動します。

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

例については、この changelistを参照してください。

仮想 A/B 圧縮

仮想 A/B 圧縮をサポートするには、 snapuserdをvendor_ramdiskにインストールする必要があります。デバイスは、 virtual_ab_ota/compression.mkから継承する必要があります。これにより、 snapuserdのvendor_ramdiskバリアントがインストールされます。

起動プロセスの変更

次の例外を除いて、リカバリまたは Android を起動するプロセスは変わりません。

  • Ramdisk build.propは/second_stage_resourcesに移動して、第 2 段階のinitがブートのビルド タイムスタンプを読み取れるようにします。

リソースはboot ramdisk からvendor_boot ramdisk に移動するため、 bootをvendor_boot ramdisk に連結した結果は変わりません。

e2fsck を利用可能にする

デバイスのメイクファイルは、次のものから継承できます。

  • virtual_ab_ota/launch_with_vendor_ramdisk.mkデバイスが仮想 A/B をサポートするが圧縮をサポートしない場合。

  • デバイスが仮想 A/B 圧縮をサポートしている場合は、 virtual_ab_ota/compression.mk compression.mk。

製品の makefile $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsckインストールします。実行時に、最初のステージのinitはルートを/first_stage_ramdiskに切り替え、次に/system/bin/e2fsckを実行します。

オプション 2a: 専用の A/B リカバリ パーティション

このオプションは、A/B recoveryパーティションを持つデバイスに使用します。つまり、デバイスにはrecovery_aおよびrecovery_b partitionがあります。このようなデバイスには、リカバリ パーティションが更新可能な A/B デバイスと仮想 A/B デバイスが含まれます。次の構成があります。

AB_OTA_PARTITIONS += recovery

vendor_boot ramdisk には、次のような ramdisk およびベンダー カーネル モジュールのベンダー ビットが含まれています。

  • デバイス固有のfstabファイル

  • lib/modules (ベンダーのカーネル モジュールを含む)

recovery RAM ディスクには、すべてのリカバリ リソースが含まれています。このようなデバイスでは、製品構成は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 RAM ディスクには、 /init -> /system/bin/initシンボリック リンク、および/system/bin/initのinit_second_stage.recoveryを含めることができます。ただし、 recovery RAM ディスクの後にブート RAM ディスクが連結されるため、 /initシンボリック リンクが上書きされます。デバイスがリカバリ モードで起動すると、第 2 段階の init をサポートするために/system/bin/initバイナリが必要になります。

デバイスがrecoveryで起動すると、 recovery + vendor_boot + boot ramdisks の内容は次のようになります。

  • /init (ramdisk から、 init_first_stageからビルド)
  • /system/bin/init ( recovery ramdisk から、 init_second_stage.recoveryからビルドし、 /initから実行)

デバイスが Android で起動すると、 vendor_boot + boot RAM ディスクの内容は次のようになります。

  • /init (ramdisk から、 init_first_stageからビルド)

fstab ファイルの移動

boot RAM ディスクにインストールされたfstabファイルをvendor_ramdiskに移動します。例については、この変更を参照してください。

モジュールのインストール

必要に応じて、デバイス固有のモジュールをvendor_ramdiskにインストールできます (インストールするデバイス固有のモジュールがない場合は、この手順をスキップしてください)。 Initはルートを切り替えません。モジュールのvendor_ramdiskバリアントは、 vendor_ramdiskのルートにインストールされます。 vendor_ramdiskにモジュールをインストールする例については、「第 1 段階のコンソール」、「メタデータ チェックサム」、および「仮想 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にインストールされます。

第 1 ステージのコンソール (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もインストールできます。

メタデータ チェックサム

第 1 段階のマウント中にメタデータ チェックサムをサポートするために、GKI をサポートしていないデバイスは、次のモジュールの ramdisk バリアントをインストールします。 GKI のサポートを追加するには、モジュールを$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/binに移動します。

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

例については、この changelistを参照してください。

仮想 A/B 圧縮

仮想 A/B 圧縮をサポートするには、 snapuserdをvendor_ramdiskにインストールする必要があります。デバイスは、 virtual_ab_ota/compression.mkから継承する必要があります。これにより、 snapuserdのvendor_ramdiskバリアントがインストールされます。

起動プロセスの変更

Android を起動する場合、起動プロセスは変わりません。 vendor_boot + boot ramdisk は、 fstabがvendor_bootから読み込まれることを除いて、既存のブート プロセスと似ています。 system/bin/recoveryが存在しないため、 first_stage_initは通常のブートとして処理します。

リカバリ モードで起動すると、起動プロセスが変わります。リカバリ + vendor_boot + boot RAM ディスクは、既存のリカバリ プロセスと似ていますが、カーネルはrecoveryイメージからではなく、 bootイメージからロードされます。リカバリ モードの起動プロセスは次のとおりです。

  1. ブートローダーが起動し、次のことを行います。

    1. recovery + vendor_boot + boot ramdisk を/にプッシュします。 (OEM がカーネル モジュールをBOARD_RECOVERY_KERNEL_MODULESに追加してリカバリ ramdisk に複製する場合)、 vendor_bootはオプションです。)
    2. bootパーティションからカーネルを実行します。

  2. カーネルは RAM ディスクを/にマウントし、 boot RAM ディスクから/initを実行します。

  3. 第 1 段階の init が開始され、次に次の処理が行われます。

    1. IsRecoveryMode() == trueおよびForceNormalBoot() == falseを設定します。
    2. /lib/modules modules からベンダー カーネル モジュールをロードします。
    3. DoFirstStageMount()を呼び出しますが、 IsRecoveryMode() == trueであるため、マウントをスキップします。 (デバイスは ramdisk を解放しません ( /は同じままであるため) が、 SetInitAvbVersionInRecovery()を呼び出します。)
    4. recovery RAM ディスクの/system/bin/initから第 2 段階の init を開始します。

e2fsck を利用可能にする

デバイスのメイクファイルは、次のものから継承できます。

  • virtual_ab_ota/launch_with_vendor_ramdisk.mkデバイスが仮想 A/B をサポートするが圧縮をサポートしない場合。

  • デバイスが仮想 A/B 圧縮をサポートしている場合は、 virtual_ab_ota/compression.mk compression.mk。

製品の makefile $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsckインストールします。実行時に、最初の段階のinitが/system/bin/e2fsckを実行します。

オプション 2b: 専用の非 A/B リカバリ パーティション

このオプションは、非 A/B recoveryパーティションを持つデバイスに使用します。つまり、デバイスには、スロット サフィックスのないrecoveryという名前のパーティションがあります。このようなデバイスには次のものがあります。

  • 非 A/B デバイス。
  • A/B および仮想 A/B デバイス。回復パーティションは更新できません。 (これは異常です。)

vendor_boot ramdisk には、次のような ramdisk およびベンダー カーネル モジュールのベンダー ビットが含まれています。

  • デバイス固有のfstabファイル
  • lib/modules (ベンダーのカーネル モジュールを含む)

recoveryイメージは自己完結型である必要があります。回復モードを起動するために必要なすべてのリソースが含まれている必要があります。

  • カーネル イメージ
  • DTBO イメージ
  • lib/modules内のカーネル モジュール
  • シンボリックリンクとしての第 1 段階の init /init -> /system/bin/init
  • 第 2 段階の 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が含まれている必要があります。デバイスがリカバリ モードで起動するとき、第 1 段階と第 2 段階の両方の init をサポートするために、 /system/bin/initバイナリが必要です。

デバイスがrecoveryで起動すると、 recovery RAM ディスクの内容は次のようになります。

  • /init -> /system/bin/init ( recovery RAM ディスクから)
  • /system/bin/init ( recovery ramdisk から、 init_second_stage.recoveryからビルドし、 /initから実行)

デバイスが Android で起動すると、 vendor_boot + boot RAM ディスクの内容は次のようになります。

  • /init (ramdisk から、 init_first_stageからビルド)

fstab ファイルの移動

boot ramdisk にインストールされたfstabファイルをvendor_ramdiskおよびrecovery ramdisk に移動します。例については、この変更を参照してください。

モジュールのインストール

必要に応じて、デバイス固有のモジュールをvendor_ramdiskおよびrecovery ramdisk にインストールできます (インストールするデバイス固有のモジュールがない場合は、この手順をスキップしてください)。 initはルートを切り替えません。モジュールのvendor_ramdiskバリアントは、 vendor_ramdiskのルートにインストールされます。モジュールのrecoveryバリアントは、 recovery RAM ディスクのルートにインストールされます。 vendor_ramdiskおよびrecovery ramdisk へのモジュールのインストールの例については、 First stage console and Metadata checksumsを参照してください。

初段コンソール

モジュールの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にインストールされます。

第 1 ステージのコンソール (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 \

メタデータ チェックサム

第 1 段階のマウント中にメタデータ チェックサムをサポートするために、GKI をサポートしていないデバイスは、次のモジュールの ramdisk バリアントをインストールします。 GKI のサポートを追加するには、モジュールを$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/binに移動します。

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

リカバリの第 1 段階のマウント中にメタデータ チェックサムをサポートするには、これらのモジュールのリカバリ バリアントを有効にして、それらもインストールします。

起動プロセスの変更

Android を起動する場合、起動プロセスは変わりません。 vendor_boot + boot ramdisk は、 fstabがvendor_bootから読み込まれることを除いて、既存のブート プロセスと似ています。 system/bin/recoveryが存在しないため、 first_stage_initは通常のブートとして処理します。

リカバリ モードで起動しても、起動プロセスは変わりません。リカバリ RAM ディスクは、既存のリカバリ プロセスと同じ方法でロードされます。カーネルはrecoveryイメージからロードされます。リカバリ モードの起動プロセスは次のとおりです。

  1. ブートローダーが起動し、次のことを行います。

    1. リカバリ ramdisk を/にプッシュします。
    2. recoveryパーティションからカーネルを実行します。

  2. カーネルは ramdisk を/にマウントし、 recovery ramdisk から/system/bin/initへのシンボリック リンクである/initを実行します。

  3. 第 1 段階の init が開始され、次に次の処理が行われます。

    1. IsRecoveryMode() == trueおよびForceNormalBoot() == falseを設定します。
    2. /lib/modules modules からベンダー カーネル モジュールをロードします。
    3. DoFirstStageMount()を呼び出しますが、 IsRecoveryMode() == trueであるため、マウントをスキップします。 (デバイスは ramdisk を解放しません ( /は同じままであるため) が、 SetInitAvbVersionInRecovery()を呼び出します。)
    4. recovery RAM ディスクの/system/bin/initから第 2 段階の 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ファイルが汎用bootイメージ RAM ディスクに追加されます。このファイルには、ビルドのタイムスタンプ情報が含まれています。

  • 実行時に、第 1 段階のinitは、ramdisk を解放する前にファイルを ramdisk からtmpfsにコピーします。これにより、第 2 段階のinitがこのファイルを読み取って、 bootイメージのタイムスタンプ プロパティを設定できます。