2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
カーネル モジュールのサポート
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
汎用カーネル イメージ（GKI）には、デバイスでパーティションをマウントするために必要なドライバ サポートが含まれていない場合があります。デバイスがパーティションをマウントして起動を継続できるように、第 1 ステージの init が改良されて、RAM ディスクに存在するカーネル モジュールを読み込むようになりました。RAM ディスクは、汎用の RAM ディスクと、ベンダー RAM ディスクに分割されています。ベンダー カーネル モジュールは、ベンダー RAM ディスクに格納されます。カーネル モジュールを読み込む順序は設定可能です。
モジュールの場所
RAM ディスクは、第 1 ステージの init, と、A/B デバイスおよび仮想 A/B デバイスのリカバリ イメージまたは fastbootd イメージ用のファイル システムです。これは、ブートローダーによって連結される 2 つの cpio アーカイブからなる initramfs です。ベンダーブート パーティションにベンダー RAM ディスクとして格納される最初の cpio アーカイブには、次のコンポーネントが含まれています。
/lib/modules/ にある第 1 ステージの init ベンダー カーネル モジュール。/lib/modules/ にある modprobe 構成ファイル modules.dep、modules.softdep、modules.alias、modules.options。- 第 1 ステージの init で読み込むモジュールとその順序を示す
modules.load ファイル（/lib/modules/ 内）。
- A/B デバイスと仮想 A/B デバイスのベンダー リカバリ カーネル モジュール（
/lib/modules/ 内）。
- A/B デバイスと仮想 A/B デバイス用に読み込むモジュールとその順序を示す
modules.load.recovery（/lib/modules 内）。
2 番目の cpio アーカイブは、boot.img の RAM ディスクとして GKI で提供され、最初のアーカイブの先頭に適用されます。first_stage_init と、依存するライブラリが含まれます。
第 1 ステージの init でのモジュールの読み込み
第 1 ステージの init は、RAM ディスク上の /lib/modules/ から modprobe 構成ファイルを読み込むことから始まります。次に、/lib/modules/modules.load（リカバリの場合は /lib/modules/modules.load.recovery）で指定されたモジュールのリストを読み取り、前に読み込んだファイルで指定された構成に従って各モジュールを順に読み込もうとします。ハード依存関係またはソフト依存関係を満たすために、リクエストされた順序どおりにはならないことがあります。
ビルドサポート、第 1 ステージの init
ベンダー RAM ディスク cpio にコピーするカーネル モジュールを指定するには、BOARD_VENDOR_RAMDISK_KERNEL_MODULES にリストします。ビルドはこれらのモジュールに対して depmod を実行し、結果の modprobe 構成ファイルをベンダー RAM ディスク cpio に配置します。
また、ビルドによって modules.load ファイルも作成され、ベンダー RAM ディスク cpio に保存されます。デフォルトでは、BOARD_VENDOR_RAMDISK_KERNEL_MODULES にリストされているすべてのモジュールが含まれています。ファイルの内容をオーバーライドするには、次の例のように BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD を使用します。
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
device/vendor/mydevice-kernel/first.ko \
device/vendor/mydevice-kernel/second.ko \
device/vendor/mydevice-kernel/third.ko
ビルドサポート、フル Android
Android 10 以前のリリースと同様に、BOARD_VENDOR_KERNEL_MODULES にリストされているカーネル モジュールは、Android プラットフォーム ビルドによって /vendor/lib/modules のベンダー パーティションにコピーされます。プラットフォーム ビルドは、これらのモジュールに対して depmod を実行し、depmod 出力ファイルを同じ場所にあるベンダー パーティションにコピーします。/vendor からカーネル モジュールを読み込むメカニズムは、以前の Android リリースの場合と同様です。モジュールを読み込む方法とタイミングは自由に決められますが、通常は init.rc スクリプトを使用します。
ワイルドカードと統合カーネルビルド
デバイス カーネルビルドと Android プラットフォーム ビルドを組み合わせるベンダーは、上記の BOARD マクロを使用してデバイスにコピーするカーネル モジュールを指定すると、問題が発生することがあります。デバイスのプラットフォーム ビルドファイルにカーネル モジュールをリストしない場合、ベンダーはワイルドカード（$(wildcard device/vendor/mydevice/*.ko）を使用できます。なお、統合カーネルビルドの場合、ワイルドカードは機能しません。これは、make が呼び出され、マクロが makefile で展開されると、カーネル モジュールがビルドされず、マクロが空になるためです。
この問題を回避するために、ベンダーはカーネルビルドで、各パーティションにコピーされるカーネル モジュールを含む zip アーカイブを作成していることがあります。BOARD_*_KERNEL_MODULES_ARCHIVE で zip アーカイブのパスを設定します。ここで * は、パーティションの名前です（例: BOARD_VENDOR_KERNEL_MODULES_ARCHIVE）。Android プラットフォーム ビルドは、この zip アーカイブを適切な場所に解凍し、モジュールに対して depmod を実行します。
カーネル モジュールの zip アーカイブには、必要に応じてプラットフォーム ビルドがアーカイブを生成できるようにする make ルールが必要です。
リカバリ
以前の Android リリースでは、リカバリに必要なカーネル モジュールが BOARD_RECOVERY_KERNEL_MODULES で指定されていました。Android 12 でも、このマクロを使用してリカバリに必要なカーネル モジュールを指定します。ただし、リカバリ カーネル モジュールは、汎用の RAM ディスク cpio ではなく、ベンダー RAM ディスク cpio にコピーされます。デフォルトでは、BOARD_RECOVERY_KERNEL_MODULES にリストされているすべてのカーネル モジュールは、第 1 ステージの init で読み込まれます。これらのモジュールのサブセットのみを読み込む場合は、BOARD_RECOVERY_KERNEL_MODULES_LOAD でサブセットの内容を指定します。
ベンダー ブート パーティション（このページで述べたベンダー RAM ディスクを含む）の作成方法については、ブート パーティションをご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Kernel module support\n\nA generic kernel image (GKI) may not contain the required driver support to\nenable a device to mount partitions. To enable a device to mount partitions and\nto continue booting, first-stage `init` is enhanced to load the\nkernel modules present on a ramdisk. The ramdisk is split into generic and\nvendor ramdisks. Vendor kernel modules are stored in the vendor ramdisk. The\norder in which kernel modules are loaded is configurable.\n\nModule location\n---------------\n\nThe ramdisk is the filesystem for first-stage `init,` and for the\nrecovery/fastbootd image on A/B and virtual A/B devices. It's an\n`initramfs` composed of two cpio archives that get concatenated by\nthe bootloader. The first cpio archive, which is stored as the vendor ramdisk\nin the vendor-boot partition, contains these components:\n\n- First-stage `init` vendor kernel modules, located in `/lib/modules/`.\n- `modprobe` config files, located in `/lib/modules/`: `modules.dep`, `modules.softdep`, `modules.alias`, `modules.options`.\n- A `modules.load` file that indicates which modules to load during first stage init, and in which order, in `/lib/modules/`.\n- Vendor recovery-kernel modules, for A/B and Virtual A/B devices, in `/lib/modules/`\n- `modules.load.recovery` which indicates the modules to load, and in which order, for A/B and Virtual A/B devices, in `/lib/modules`.\n\n\nThe second cpio archive, which is supplied with the GKI\nas the ramdisk of the boot.img and applied on top of the\nfirst, contains `first_stage_init` and the libraries on which it depends.\n\nModule loading in first-stage init\n----------------------------------\n\nFirst-stage `init` begins by reading the modprobe configuration\nfiles from `/lib/modules/` on the ramdisk. Next, it reads the list\nof modules specified in `/lib/modules/modules.load` (or in the case\nof recovery, `/lib/modules/modules.load.recovery`) and attempts to\nload each of those modules in order, following the configuration specified in\nthe previously loaded files. The requested order may be deviated from to\nsatisfy hard or soft dependencies.\n\nBuild support, first-stage init\n-------------------------------\n\nTo specify kernel modules to be copied into the vendor ramdisk cpio, list\nthem in `BOARD_VENDOR_RAMDISK_KERNEL_MODULES`. The build runs\n`depmod` on these modules and puts the resulting modprobe configuration\nfiles in the vendor ramdisk cpio.\n\nThe build also creates a `modules.load` file and stores it in the\nvendor ramdisk cpio. By default it contains all of the modules listed in\n`BOARD_VENDOR_RAMDISK_KERNEL_MODULES`. To override the contents of\nthat file, use `BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD`, as shown\nin this example: \n\n```maple\nBOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \\\n device/vendor/mydevice-kernel/first.ko \\\n device/vendor/mydevice-kernel/second.ko \\\n device/vendor/mydevice-kernel/third.ko\n```\n\nBuild support, full Android\n---------------------------\n\nAs is the case in Android 10 and lower releases, kernel modules listed in\n`BOARD_VENDOR_KERNEL_MODULES` are copied by the Android platform\nbuild into the vendor partition at `/vendor/lib/modules`. The\nplatform build runs `depmod` on these modules, and copies the\n`depmod` output files into the vendor partition at the same\nlocation. The mechanism for loading kernel modules from `/vendor`\nremains the same as it was for prior releases of Android. It's your decision\nhow and when to load these modules, although typically this is done using\n`init.rc` scripts.\n\nWildcards and integrated kernel builds\n--------------------------------------\n\nVendors who combine their device kernel build with the Android platform build\nmay run into a problem using the above mentioned `BOARD` macros to\nspecify kernel modules to be copied on to the device. If the vendor wishes to avoid\nlisting kernel modules in the device's platform build files, they can use a wildcard\n(`$(wildcard device/vendor/mydevice/*.ko`). Note that the wildcard doesn't\nwork in the case of an integrated kernel build, because when make is invoked and the\nmacros are expanded in makefiles, the kernel modules haven't been built, so the macros\nare empty.\n\nTo get around this problem, the vendor may have their kernel build create a zip\narchive containing the kernel modules to be be copied onto each partition.\nSet the path of that zip archive in `BOARD_*_KERNEL_MODULES_ARCHIVE`\nwhere `*` is the name of the partition (such as\n`BOARD_VENDOR_KERNEL_MODULES_ARCHIVE`). The Android platform build\nextracts this zip archive into the appropriate location and runs `depmod`\non the modules.\n\nThe kernel module zip archive should have a make rule that ensures the platform\nbuild can generate the archive when required.\n\nRecovery\n--------\n\nIn prior Android releases, kernel modules required for recovery were\nspecified in `BOARD_RECOVERY_KERNEL_MODULES`. In Android 12,\nkernel modules required for recovery are still\nspecified using this macro. However, the recovery kernel modules are copied to\nthe vendor ramdisk cpio, rather than the generic ramdisk cpio. By default all\nkernel modules listed in `BOARD_RECOVERY_KERNEL_MODULES` are loaded\nduring first-stage `init`. If you only want a subset of these\nmodules to be loaded, specify the contents of that subset in\n`BOARD_RECOVERY_KERNEL_MODULES_LOAD`.\n\nRelated documentation\n---------------------\n\nTo learn about creating a vendor boot partition (which contains the vendor\nramdisk mentioned on this page), see\n[Boot\npartitions](/docs/core/architecture/bootloader/partitions/vendor-boot-partitions)."]]
