Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

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

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

次のようなデバイスの場合:

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

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

建築

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

Android12を起動またはアップグレードします。専用のリカバリはありません

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

1.Android12を起動またはアップグレードするデバイス、GKIあり、専用リカバリなし

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

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

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

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

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

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

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

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

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

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

3.Android12にアップグレードするデバイス、GKIなし、起動時のリカバリ

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

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

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

ブートイメージの内容

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

  • 一般的なbootイメージ
    • ヘッダーバージョンV3またはV4
      • boot_signature boot.img認定のboot_signature(v4のみ)。認定されたboot.imgは、検証済みのブート用に署名されていません。 OEMは、デバイス固有のAVBキーを使用してビルド済みのboot.imgに署名する必要があります。
      • 汎用cmdlineGENERIC_KERNEL_CMDLINE
      • 一般的なカーネルイメージ
    • 汎用boot RAMディスクイメージ
  • vendor_bootイメージ(詳細については、ベンダーブートパーティションを参照してください)
    • vendor_bootヘッダー
      • デバイス固有のBOARD_KERNEL_CMDLINE cmdline
    • vendor_bootイメージ
      • 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リカバリパーティションの場合、リカバリRAMディスクは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/

ボード構成

ビルドフラグは、 bootrecovery 、および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 。この変数は、GSIAVBキーがvendor_bootに組み込まれるかどうかを制御します。

    • trueに設定されている場合、 BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOTの場合:

      • 設定されると、GSIAVBキーは$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avbされます。

      • 設定されていない場合、GSIAVBキーは$ANDROID_PRODUCT_OUT/vendor-ramdisk/avbされます。

    • 空の場合、 BOARD_RECOVERY_AS_ROOTの場合:

      • 設定されると、GSIAVBキーは$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avbにビルドされます。

      • 設定されていない場合、GSIAVBキーは$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_IMAGEtrueまたは空に設定できます。これらのデバイスの場合、 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に移動します)。

デバイスのセットアップ

セットアップ手順は、Android12にアップデートするデバイスとAndroid12で起動するデバイスで異なります。

  • Android 12にアップデートするデバイス:

    • BOARD_USES_RECOVERY_AS_BOOTの値を保持できます。その場合、レガシー構成を使用しており、新しいビルド変数は空である必要があります。そのようなデバイスの場合:

      • BOARD_USES_RECOVERY_AS_BOOTtrueに設定すると、アーキテクチャは図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段階のinitをサポートするために/system/bin/initバイナリが必要です。 vendor_boot + bootの内容は次のとおりです。

  • /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がrootを/first_stage_ramdiskに切り替える前に使用可能である必要があります。 /へのモジュールのインストールの詳細については、第1段階のコンソールを参照してください。

ファーストステージコンソール

initがrootを/first_stage_ramdiskに切り替える前に、第1ステージのコンソールが起動するため、モジュールのrecoveryバリアントをインストールする必要があります。デフォルトでは、両方のモジュールバリアントがbuild/make/target/product/base_vendor.mkにインストールされるため、デバイスのmakefileがそのファイルから継承する場合は、 recoveryバリアントを明示的にインストールする必要はありません。

リカバリモジュールを明示的にインストールするには、以下を使用します。

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

これにより、 linkersh 、および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 \

例については、このチェンジリストを参照してください。

仮想A/B圧縮

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

起動プロセスの変更

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

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

リソースはbootramdiskからvendor_bootに移動boot boot vendor_bootに連結した結果は変わりません。

e2fsckを利用可能にする

デバイスのmakefileは、以下から継承できます。

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

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

製品のmakefileは、 $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsckインストールします。実行時に、最初のステージのinitはrootを/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- /init -> /system/bin/initシンボリックリンク、および/system/bin/initにあるinit_second_stage.recoveryを含めることができます。ただし、ブートRAMディスクはrecovery RAMディスクの後に連結されるため、 /initシンボリックリンクは上書きされます。デバイスがリカバリモードで起動する場合、第2段階のinitをサポートするために/system/bin/initバイナリが必要です。

デバイスがrecoveryで起動する場合、 recovery + vendor_boot + bootの内容は次のとおりです。

  • /init (ramdiskから、 init_first_stageからビルド)
  • /system/bin/initrecovery RAMディスクから、 init_second_stage.recoveryから構築され、 /initから実行されます)

デバイスがAndroidで起動する場合、 vendor_boot + bootの内容は次のとおりです。

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

これにより、 linkersh 、および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 \

例については、このチェンジリストを参照してください。

仮想A/B圧縮

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

起動プロセスの変更

Androidで起動する場合、起動プロセスは変更されません。 vendor_boot + boot ramdiskは、 fstabvendor_bootからロードされることを除いて、既存のブートプロセスに似ています。 system/bin/recovery restoreyが存在しないため、 first_stage_initはそれを通常のブートとして処理します。

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

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

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

  3. 最初のステージの初期化が開始され、次に次のことが行われます。

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

e2fsckを利用可能にする

デバイスのmakefileは、以下から継承できます。

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

  • デバイスが仮想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段階の初期化バイナリ/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 RAMディスクには、/ init- /init -> /system/bin/initシンボリックリンク、および/system/bin/initにあるinit_second_stage.recoveryが含まれている必要があります。デバイスがリカバリモードで起動する場合、第1ステージと第2ステージの両方のinitをサポートするために/system/bin/initバイナリが必要です。

デバイスがrecoveryで起動するとき、 recovery ramdiskの内容は次のとおりです。

  • /init -> /system/bin/initrecovery RAMディスクから)
  • /system/bin/initrecovery RAMディスクから、 init_second_stage.recoveryから構築され、 /initから実行されます)

デバイスがAndroidで起動する場合、 vendor_boot + bootの内容は次のとおりです。

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

fstabファイルの移動

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

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

必要に応じて、デバイス固有のモジュールをvendor_ramdiskおよびrecovery ramdiskにインストールできます(インストールするデバイス固有のモジュールがない場合は、この手順をスキップしてください)。 initはルートを切り替えません。モジュールのvendor_ramdiskバリアントは、 vendor_ramdiskのルートにインストールされます。モジュールのrecoveryバリアントは、 recovery RAMディスクのルートにインストールされます。モジュールをvendor_ramdiskrecovery ramdiskにインストールする例については、第1段階のコンソールメタデータのチェックサムを参照してください。

ファーストステージコンソール

モジュールのvendor_ramdiskバリアントをインストールするには、以下を使用します。

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

これにより、 linkersh 、および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_ramdiskrecoveryに置き換えます。

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は、 fstabvendor_bootからロードされることを除いて、既存のブートプロセスに似ています。 system/bin/recovery restoreyが存在しないため、 first_stage_initはそれを通常のブートとして処理します。

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

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

    1. リカバリRAMディスクを/にプッシュします。
    2. recoveryパーティションからカーネルを実行します。
  2. カーネルはramdiskを/にマウントしてから/initを実行します。これは、 recovery ramdiskから/system/bin/initへのシンボリックリンクです。

  3. 最初のステージの初期化が開始され、次に次のことが行われます。

    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イメージramdiskに追加されます。このファイルには、ビルドのタイムスタンプ情報が含まれています。

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