Android 12 では、汎用カーネル イメージ（GKI）という汎用の boot イメージに、汎用 RAM ディスクと GKI カーネルが含まれています。
Android 13 を搭載してリリースされるデバイスの場合、汎用 RAM ディスクが boot イメージから削除され、別の init_boot イメージに配置されています。この変更により、boot イメージには GKI カーネルのみが残ります。
Android 12 以前のカーネル バージョンを引き続き使用するデバイスをアップグレードする場合、汎用 RAM ディスクは、新しい init_boot イメージを必要としない状態が維持されます。
汎用 RAM ディスクをビルドするには、ベンダー固有のリソースを RAM ディスクから移動して、汎用 RAM ディスクに第 1 ステージの init と、タイムスタンプ情報を含むプロパティ ファイルのみが含まれるようにします。
デバイスに応じて以下のようにします。
専用の
recoveryパーティションを使用していないデバイスの場合、すべてのリカバリビットを汎用 RAM ディスクからvendor_bootRAM ディスクに移動します。専用の
recoveryパーティションを使用しているデバイスの場合、recoveryRAM ディスクは自己完結しているため、recoveryRAM ディスクの変更は必要ありません。
アーキテクチャ
次の図は、Android 12 以降を搭載したデバイスのアーキテクチャを示しています。Android 13 を搭載してリリースされるデバイスでは、汎用 RAM ディスクを含んでいる新しい init_boot イメージが追加されています。Android 12 から Android 13 にアップグレードするデバイスは、Android 12 と同じアーキテクチャを使用します。
Android 13 でリリース、専用のリカバリなし
図 1. Android 13 でリリースまたは Android 13 にアップグレードするデバイス、GKI あり、専用のリカバリなし
Android 13 でリリース、専用の A/B リカバリ（専用の RAM ディスク）あり
図 2. Android 13 でリリースまたは Android 13 にアップグレードするデバイス、GKI あり、専用の A/B リカバリあり
デバイスに recovery_a パーティションと recovery_b パーティションがある場合は、この図を参照してください。
Android 13 でリリース、専用の非 A/B リカバリ（専用の RAM ディスク）あり
図 3. Android 13 でリリースまたは Android 13 へのアップグレード、GKI あり、専用の非 A/B リカバリあり
スロット サフィックスのない recovery というパーティションがデバイスにある場合は、この図を参照してください。
Android 12 でリリースまたは Android 12 へのアップグレード、専用のリカバリなし
図 4. Android 12 でリリースまたは Android 12 にアップグレードするデバイス、GKI あり、専用のリカバリなし
Android 12 の起動または Android 12 へのアップグレード（専用の A/B リカバリ（専用の RAM ディスク）あり）
図 5. Android 12 でリリースまたは Android 12 にアップグレードするデバイス、GKI あり、専用の A/B リカバリあり
デバイスに recovery_a パーティションと recovery_b パーティションがある場合は、この図を参照してください。
Android 12 でリリースまたは Android 12 へのアップグレード、専用の非 A/B リカバリ（専用の RAM ディスク）あり
図 6. Android 12 でリリースまたは Android 12 へのアップグレード、GKI あり、専用の非 A/B リカバリあり
スロット サフィックスのない recovery というパーティションがデバイスにある場合は、この図を参照してください。
Android 12 へのアップグレード、リカバリをブートとして使用（リカバリを RAM ディスクとして使用）
図 7. Android 12 にアップグレードするデバイス、GKI なし、リカバリをブートとして使用
Android 12 へのアップグレード（専用のリカバリ（専用 RAM ディスク）あり）
図 8. Android 12 にアップグレードするデバイス、GKI なし、専用のリカバリあり
ブートイメージの内容
Android のブートイメージには次のものが含まれます。
Android 13 を搭載したデバイスに追加された
init_bootイメージ- ヘッダー バージョン V4
- 汎用 RAM ディスク イメージ
汎用
bootイメージvendor_bootイメージ（詳細については、ベンダー ブート パーティションをご覧ください）vendor_bootヘッダー- デバイス固有の
cmdline（BOARD_KERNEL_CMDLINE）
- デバイス固有の
vendor_bootRAM ディスク イメージ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ヘッダーから推測できます。
- デバイス固有のリカバリ用
recoveryRAM ディスク イメージ- リカバリ リソース
- 非 A/B リカバリ パーティションの場合、RAM ディスクのコンテンツはスタンドアロンにする必要があります。リカバリ イメージをご覧ください。 例:
lib/modulesには、リカバリモードの起動に必要なすべてのカーネル モジュールを含める必要があります。- リカバリ RAM ディスクには
initを含める必要があります。 - A/B リカバリ パーティションの場合、リカバリ RAM ディスクは汎用および
vendor_bootRAM ディスクの先頭に付加されるため、スタンドアロンにする必要はありません。例: lib/modulesには、vendor_bootRAM ディスクのカーネル モジュール以外に、リカバリモードの起動に必要な追加のカーネル モジュールのみを含めることができます。/initにシンボリック リンクが存在する可能性がありますが、ブートイメージに第 1 ステージの/initバイナリがあるため、重要性は低くなります。
- ヘッダー バージョン V2
汎用 RAM ディスク イメージの内容
汎用 RAM ディスクには、次のコンポーネントが含まれています。
init- 追加された
system/etc/ramdisk/build.prop ro.PRODUCT.bootimg.* build.prop- マウント ポイント用の空のディレクトリ:
debug_ramdisk/、mnt/、dev/、sys/、proc/、metadata/ first_stage_ramdisk/- マウント ポイント用の重複した空のディレクトリ:
debug_ramdisk/、mnt/、dev/、sys/、proc/、metadata/
- マウント ポイント用の重複した空のディレクトリ:
ブートイメージの統合
ビルドフラグは、init_boot、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 を使用することを示します。この変数は sysprop やPRODUCT_PACKAGESには影響しません。これはボードレベルの GKI スイッチであり、下記のすべての変数は、この変数により制限されます。
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT。この変数は、RAM ディスクのリカバリ リソースが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/Brecoveryパーティションを使用するデバイスでは、この変数を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が生成されるかどうかを制御し、そのサイズを設定します。設定すると、汎用 RAM ディスクがboot.imgではなくinit_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 は、動的パーティションを使用するデバイスでもサポートされていません。
プロダクトの構成
汎用 RAM ディスクを使用するデバイスには、RAM ディスクへのインストールが許可されているファイルのリストをインストールする必要があります。これを行うには、device.mk で次のように指定します。
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
また、generic_ramdisk.mk ファイルを使用することで、他の makefile が誤って他のファイルを RAM ディスクにインストールするのを防ぐことができます（そのようなファイルは vendor_ramdisk に移動されます）。
デバイスのセットアップ
セットアップ手順は、Android 13 を搭載したデバイス、Android 12 にアップグレードするデバイス、Android 12 を搭載したデバイスで異なります。Android 13 は、Android 12 と同様に手順でセットアップされます。
Android 12 にアップグレードするデバイス:
BOARD_USES_RECOVERY_AS_BOOTの値を保持できます。その場合、以前の構成が使用されているため、新しいビルド変数は空にする必要があります。これはデバイスによって次のように異なります。BOARD_USES_RECOVERY_AS_BOOTは空に設定できます。その場合、新しい構成が使用されます。これはデバイスによって次のように異なります。
Android 12 を搭載したデバイスでは、
BOARD_USES_RECOVERY_AS_BOOTを空にして新しい構成を使用する必要があります。これはデバイスによって次のように異なります。
aosp_arm64 は、GKI のみをビルドし、vendor_boot またはリカバリはビルドしないため、完全なターゲットではありません。aosp_arm64 のビルド構成については、generic_arm64 をご覧ください。
オプション 1: 専用のリカバリ パーティションなし
recovery パーティションのないデバイスでは、boot パーティションに汎用 boot イメージが含まれています。vendor_boot RAM ディスクには、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
init バイナリとシンボリック リンク
vendor_boot ramdisk には、/init から /system/bin/init へのシンボリック リンク、および /system/bin/init の init_second_stage.recovery を含めることができます。ただし、vendor_boot RAM ディスクの後に汎用 RAM ディスクが連結されるため、/init シンボリック リンクは上書きされます。デバイスがリカバリに起動する場合、第 2 ステージの init をサポートするには /system/bin/init バイナリが必要です。vendor_boot + 汎用 RAM ディスクのコンテンツは次のようになります。
/init（汎用 RAM ディスクのもの。init_first_stageからビルド）/system/bin/init（vendor_ramdiskのもの。init_second_stage.recoveryからビルド）
fstab ファイルの移動
汎用 RAM ディスクにインストールされているすべての fstab ファイルを vendor_ramdisk に移動します。具体的な例については、こちらの変更をご覧ください。
モジュールのインストール
必要に応じて、デバイス固有のモジュールを vendor_ramdisk にインストールできます（インストールするデバイス固有のモジュールがない場合は、このステップをスキップしてください）。
モジュールを
/first_stage_ramdiskにインストールするときに、モジュールのvendor_ramdiskバリアントを使用します。このモジュールは、initがルートを/first_stage_ramdiskに切り替えた後、かつinitがルートを/systemに切り替える前に使用可能にする必要があります。具体的な例については、メタデータ チェックサムと仮想 A/B 圧縮をご覧ください。モジュールを
/にインストールするときに、モジュールのrecoveryバリアントを使用します。 このモジュールは、initがルートを/first_stage_ramdiskに切り替える前に使用可能にする必要があります。/へのモジュールのインストールについて詳しくは、第 1 ステージのコンソールをご覧ください。
第 1 ステージのコンソール
第 1 ステージのコンソールは 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 にインストールされます。
第 1 ステージのコンソールに必要なモジュール（adbd など）を追加するには、次のように記述します。
PRODUCT_PACKAGES += adbd.recovery
これにより、指定したモジュールが $ANDROID_PRODUCT_OUT/recovery/root/system/bin にインストールされ、その後これが vendor_ramdisk の下の /system/bin にインストールされます。
メタデータ チェックサム
第 1 ステージのマウント時にメタデータ チェックサムをサポートするため、GKI をサポートしていないデバイスでは、次のモジュールの RAM ディスク バリアントがインストールされます。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 にインストールする必要があります。デバイスは、snapuserd の vendor_ramdisk バリアントがインストールされている virtual_ab_ota/compression.mk から継承する必要があります。
起動プロセスの変更
リカバリまたは Android での起動プロセスは変わりませんが、以下の例外があります。
- 第 2 ステージの
initがブートのビルド タイムスタンプを読み取れるように、RAM ディスクのbuild.propが/second_stage_resourcesに移動します。
リソースは汎用 RAM ディスクから vendor_boot RAM ディスクに移動するため、汎用 RAM ディスクを vendor_boot RAM ディスクに連結した際の結果は変わりません。
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 がインストールされます。実行時に、第 1 ステージの 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 RAM ディスクには、次のように RAM ディスクとベンダー カーネル モジュールのベンダービットが含まれています。
デバイス固有の
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
init バイナリとシンボリック リンク
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 + 汎用 RAM ディスクのコンテンツは次のようになります。
/init（RAM ディスクのもの。init_first_stageからビルド）/system/bin/init（recoveryRAM ディスクのもの。init_second_stage.recoveryからビルドし、/initから実行）
デバイスが Android で起動する場合、vendor_boot + 汎用 RAM ディスクのコンテンツは次のようになります。
/init（汎用 RAM ディスクのもの。init_first_stageからビルド）
fstab ファイルの移動
汎用 RAM ディスクにインストールされたすべての fstab ファイルを vendor_ramdisk に移動します。具体的な例については、こちらの変更をご覧ください。
モジュールのインストール
必要に応じて、デバイス固有のモジュールを vendor_ramdisk にインストールできます（インストールするデバイス固有のモジュールがない場合は、このステップをスキップしてください）。Init はルートを切り替えません。モジュールの vendor_ramdisk バリアントは、vendor_ramdisk のルートにインストールされます。vendor_ramdisk へのモジュールのインストール例については、第 1 ステージのコンソール、メタデータ チェックサム、仮想 A/B 圧縮をご覧ください。
第 1 ステージのコンソール
モジュールの 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 RAM ディスクがリカバリモードで読み込まれる場合、モジュールは recovery でも使用できます。vendor_boot RAM ディスクがリカバリモードで読み込まれない場合は、必要に応じて adbd.recovery もインストールできます。
メタデータ チェックサム
第 1 ステージのマウント時にメタデータ チェックサムをサポートするため、GKI をサポートしていないデバイスでは、次のモジュールの RAM ディスク バリアントがインストールされます。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 にインストールする必要があります。デバイスは、snapuserd の vendor_ramdisk バリアントがインストールされている virtual_ab_ota/compression.mk から継承する必要があります。
起動プロセスの変更
Android で起動する場合、起動プロセスは変更されません。vendor_boot + 汎用 RAM ディスクは、fstab が vendor_boot から読み込まれることを除けば、既存の起動プロセスと似ています。system/bin/recovery が存在しないため、first_stage_init はこれを通常のブートとして処理します。
リカバリモードで起動すると、起動プロセスが変更されます。recovery + vendor_boot + 汎用 RAM ディスクは既存のリカバリ プロセスと似ていますが、カーネルは recovery イメージではなく boot イメージから読み込まれます。リカバリモードの起動プロセスは次のとおりです。
ブートローダーが起動し、次の処理が行われます。
- recovery +
vendor_boot+ 汎用 RAM ディスクを/に push します（OEM が recovery RAM ディスクでカーネル モジュールをBOARD_RECOVERY_KERNEL_MODULESに追加して複製する場合、vendor_bootは省略可能です）。 bootパーティションからカーネルを実行します。
- recovery +
カーネルは RAM ディスクを
/にマウントし、汎用 RAM ディスクから/initを実行します。第 1 ステージの init が起動し、次の処理が行われます。
IsRecoveryMode() == trueとForceNormalBoot() == falseを設定します。- ベンダーのカーネル モジュールを
/lib/modulesから読み込みます。 DoFirstStageMount()を呼び出しますが、IsRecoveryMode() == trueのためマウントをスキップします。（/が同じであるため、デバイスは RAM ディスクを解放せずに、SetInitAvbVersionInRecovery()を呼び出します）。recoveryRAM ディスクの/system/bin/initから第 2 ステージの 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 がインストールされます。実行時に、第 1 ステージの init が /system/bin/e2fsck を実行します。
オプション 2b: 専用の非 A/B リカバリ パーティション
このオプションは、非 A/B recovery パーティションを備えたデバイス（スロット サフィックスのない、recovery という名前のパーティションがあるデバイス）に使用します。こうしたデバイスには次のようなものがあります。
- 非 A/B デバイス
- リカバリ パーティションの更新ができない A/B デバイスと仮想 A/B デバイス（これはめったにありません）。
vendor_boot RAM ディスクには、次のように RAM ディスクとベンダー カーネル モジュールのベンダービットが含まれています。
- デバイス固有の
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
init バイナリとシンボリック リンク
recovery RAM ディスクには、/init -> /system/bin/init のシンボリック リンク、および /system/bin/init の init_second_stage.recovery が含まれている必要がありますデバイスがリカバリモードで起動する際、第 1 ステージと第 2 ステージの init の両方をサポートするには /system/bin/init バイナリが必要です。
デバイスが recovery で起動する場合、recovery RAM ディスクのコンテンツは次のようになります。
/init -> /system/bin/init（recoveryRAM ディスクのもの）/system/bin/init（recoveryRAM ディスクのもの。init_second_stage.recoveryからビルドし、/initから実行）
デバイスが Android で起動する場合、vendor_boot + 汎用 RAM ディスクのコンテンツは次のようになります。
/init（RAM ディスクのもの。init_first_stageからビルド）
fstab ファイルの移動
汎用 RAM ディスクにインストールされたすべての fstab ファイルを、vendor_ramdisk と recovery RAM ディスクに移動します。具体的な例については、こちらの変更をご覧ください。
モジュールのインストール
必要に応じて、デバイス固有のモジュールを vendor_ramdisk と recovery RAM ディスクにインストールできます（インストールするデバイス固有のモジュールがない場合は、このステップをスキップしてください）。init はルートを切り替えません。モジュールの vendor_ramdisk バリアントは、vendor_ramdisk のルートにインストールされます。モジュールの recovery バリアントは、recovery RAM ディスクのルートにインストールされます。vendor_ramdisk と recovery RAM ディスクへのモジュールのインストール例については、第 1 ステージのコンソールとメタデータ チェックサムをご覧ください。
第 1 ステージのコンソール
モジュールの 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 をサポートしていないデバイスでは、次のモジュールの RAM ディスク バリアントがインストールされます。GKI のサポートを追加するには、モジュールを $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin に移動します。
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
リカバリの第 1 ステージのマウント時にメタデータ チェックサムをサポートするには、これらのモジュールのリカバリ バリアントを有効にしてからインストールします。
起動プロセスの変更
Android で起動する場合、起動プロセスは変更されません。vendor_boot + 汎用 RAM ディスクは、fstab が vendor_boot から読み込まれることを除けば、既存の起動プロセスと似ています。system/bin/recovery が存在しないため、first_stage_init はこれを通常のブートとして処理します。
リカバリモードで起動する場合、起動プロセスは変更されません。リカバリ用 RAM ディスクは、既存のリカバリ プロセスと同じ方法で読み込まれます。カーネルは recovery イメージから読み込まれます。リカバリモードの起動プロセスは次のとおりです。
ブートローダーが起動し、次の処理が行われます。
- リカバリ用 RAM ディスクを
/に push します。 recoveryパーティションからカーネルを実行します。
- リカバリ用 RAM ディスクを
カーネルは RAM ディスクを
/にマウントし、/initを実行します。これは、recoveryRAM ディスクから/system/bin/initへのシンボリック リンクです。第 1 ステージの init が起動し、次の処理が行われます。
IsRecoveryMode() == trueとForceNormalBoot() == falseを設定します。- ベンダーのカーネル モジュールを
/lib/modulesから読み込みます。 DoFirstStageMount()を呼び出しますが、IsRecoveryMode() == trueのためマウントをスキップします。（/が同じであるため、デバイスは RAM ディスクを解放せずに、SetInitAvbVersionInRecovery()を呼び出します）。recoveryRAM ディスクの/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