ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
การสนับสนุนโมดูลเคอร์เนล
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
อิมเมจเคอร์เนลทั่วไป (GKI) อาจไม่รองรับไดรเวอร์ที่จำเป็นในการทำให้อุปกรณ์สามารถต่อเชื่อมพาร์ติชัน init ระยะที่ 1 ได้รับการปรับปรุงให้โหลดโมดูลเคอร์เนลที่อยู่ใน RAMdisk เพื่อให้อุปกรณ์สามารถต่อเชื่อมพาร์ติชันและบูตต่อไปได้ แรมดิสก์จะแบ่งออกเป็นแรมดิสก์ทั่วไปและแรมดิสก์ของผู้ให้บริการ โมดูลเคอร์เนลของผู้ให้บริการจะจัดเก็บไว้ใน RAMdisk ของผู้ให้บริการ คุณสามารถกำหนดค่าลําดับการโหลดโมดูลเคอร์เนลได้
ตำแหน่งของโมดูล
แรมดิสก์คือระบบไฟล์สำหรับ init, ระยะแรกและสำหรับภาพ recovery/fastbootd ในอุปกรณ์ A/B และ A/B เสมือน ไฟล์นี้
initramfsประกอบด้วยไฟล์เก็บถาวร cpio 2 ไฟล์ที่เชื่อมต่อกันโดย bootloader ไฟล์เก็บถาวร cpio ไฟล์แรกซึ่งจัดเก็บเป็น RAMdisk ของผู้ให้บริการในพาร์ติชัน vendor-boot ประกอบด้วยคอมโพเนนต์ต่อไปนี้
- โมดูลเคอร์เนลของผู้ให้บริการ
init ระยะที่ 1 ซึ่งอยู่ใน
/lib/modules/
- ไฟล์
modprobe config ซึ่งอยู่ใน /lib/modules/
modules.dep, modules.softdep,
modules.alias, modules.options
- ไฟล์
modules.load ที่ระบุโมดูลที่จะโหลดระหว่างการเริ่มต้นระยะแรก และลำดับใน /lib/modules/
- โมดูลเคอร์เนลการกู้คืนของผู้ให้บริการสำหรับอุปกรณ์ A/B และ A/B เสมือนใน
/lib/modules/
modules.load.recovery ซึ่งระบุโมดูลที่จะโหลดและลำดับสำหรับอุปกรณ์ A/B และ A/B เสมือนใน/lib/modules
ไฟล์เก็บถาวร cpio ที่ 2 ซึ่งมาพร้อมกับ GKI เป็น RAMdisk ของ boot.img และวางไว้ด้านบนของไฟล์แรกจะมี first_stage_init และไลบรารีที่ first_stage_init นั้นใช้
การโหลดโมดูลในอินทิทัลระยะแรก
init ระยะที่ 1 เริ่มต้นด้วยการอ่านไฟล์การกำหนดค่า modprobe จาก /lib/modules/ ใน RAMdisk จากนั้นจะอ่านรายการของโมดูลที่ระบุใน /lib/modules/modules.load (หรือในกรณีการกู้คืน /lib/modules/modules.load.recovery) และพยายามโหลดโมดูลแต่ละรายการตามลำดับตามการกำหนดค่าที่ระบุไว้ในไฟล์ที่โหลดก่อนหน้านี้ ระบบอาจเปลี่ยนลำดับคำสั่งซื้อที่ขอเพื่อตอบสนองความต้องการแบบบังคับหรือแบบไม่บังคับ
การสนับสนุนการสร้าง การสร้างระยะแรก
หากต้องการระบุโมดูลเคอร์เนลที่จะคัดลอกไปยัง cpio ของแรมดิสก์ของผู้ให้บริการ ให้ระบุไว้ใน BOARD_VENDOR_RAMDISK_KERNEL_MODULES บิลด์จะทำงานdepmodในโมดูลเหล่านี้และวางไฟล์การกำหนดค่า modprobe ที่ได้ไว้ใน cpio ของ ramdisk ของผู้ให้บริการ
บิลด์จะสร้างไฟล์ modules.load และจัดเก็บไว้ใน 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 และรุ่นที่ต่ำกว่า แพลตฟอร์ม Android จะคัดลอกโมดูลเคอร์เนลที่แสดงใน BOARD_VENDOR_KERNEL_MODULES ไปไว้ในพาร์ติชันของผู้ให้บริการที่ /vendor/lib/modules บิลด์แพลตฟอร์มจะเรียกใช้ depmod ในโมดูลเหล่านี้ และคัดลอกไฟล์เอาต์พุต depmod ไปยังพาร์ติชันของผู้ให้บริการที่ตำแหน่งเดียวกัน กลไกในการโหลดโมดูลเคอร์เนลจาก /vendor
จะยังคงเหมือนเดิมกับที่ใช้กับ Android เวอร์ชันก่อนหน้า คุณตัดสินใจได้ว่าจะโหลดโมดูลเหล่านี้อย่างไรและเมื่อใด แม้ว่าโดยทั่วไปแล้วจะใช้สคริปต์init.rc
ไวลด์การ์ดและบิลด์เคอร์เนลแบบรวม
ผู้ให้บริการที่รวมบิลด์เคอร์เนลของอุปกรณ์เข้ากับบิลด์แพลตฟอร์ม Android อาจพบปัญหาเมื่อใช้มาโคร BOARD ที่กล่าวถึงข้างต้นเพื่อระบุโมดูลเคอร์เนลที่จะคัดลอกไปยังอุปกรณ์ หากผู้จำหน่ายต้องการหลีกเลี่ยงการระบุโมดูลเคอร์เนลในไฟล์บิลด์แพลตฟอร์มของอุปกรณ์ ก็สามารถใช้ไวลด์การ์ด ($(wildcard device/vendor/mydevice/*.ko) ได้ โปรดทราบว่าไวลด์การ์ดจะใช้ไม่ได้ในกรณีของบิลด์เคอร์เนลแบบรวม เนื่องจากเมื่อเรียกใช้ make และขยายมาโครในไฟล์ make โมดูลเคอร์เนลจะยังไม่ได้รับการสร้าง ดังนั้นมาโครจึงว่างเปล่า
ผู้ให้บริการอาจใช้บิลด์เคอร์เนลเพื่อสร้างไฟล์เก็บถาวร ZIP ที่มีโมดูลเคอร์เนลที่จะคัดลอกไปยังพาร์ติชันแต่ละรายการเพื่อแก้ปัญหานี้
ตั้งค่าเส้นทางของไฟล์ ZIP นั้นใน BOARD_*_KERNEL_MODULES_ARCHIVE โดยที่ * คือชื่อของพาร์ติชัน (เช่น BOARD_VENDOR_KERNEL_MODULES_ARCHIVE) บิลด์แพลตฟอร์ม Android จะแตกไฟล์ ZIP นี้ไปยังตำแหน่งที่เหมาะสมและเรียกใช้ depmod ในโมดูล
ไฟล์ ZIP ของโมดูลเคอร์เนลควรมีกฎ make ที่ช่วยให้มั่นใจได้ว่าการสร้างแพลตฟอร์มจะสร้างไฟล์เก็บถาวรได้เมื่อจำเป็น
การกู้คืน
ใน Android เวอร์ชันก่อนหน้า โมดูลเคอร์เนลที่จําเป็นสําหรับการกู้คืนจะระบุไว้ใน BOARD_RECOVERY_KERNEL_MODULES ใน Android 12 ระบบจะยังคงระบุข้อบังคับของเคอร์เนลที่จําเป็นสําหรับการกู้คืนโดยใช้มาโครนี้ อย่างไรก็ตาม ระบบจะคัดลอกโมดูลเคอร์เนลการกู้คืนไปยัง cpio ของแรมดิสก์ของผู้ให้บริการแทน cpio ของแรมดิสก์ทั่วไป โดยค่าเริ่มต้น ระบบจะโหลดข้อบังคับของเคอร์เนลทั้งหมดที่แสดงใน BOARD_RECOVERY_KERNEL_MODULES ในระหว่างระยะที่ 1 ของ init หากต้องการโหลดเฉพาะชุดย่อยของข้อบังคับเหล่านี้ ให้ระบุเนื้อหาของชุดย่อยนั้นใน BOARD_RECOVERY_KERNEL_MODULES_LOAD
ดูข้อมูลเกี่ยวกับการสร้างพาร์ติชันสำหรับบูตของผู้ให้บริการ (ซึ่งมีแรมดิสก์ของผู้ให้บริการที่กล่าวถึงในหน้านี้) ได้ที่พาร์ติชันสำหรับบูต
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 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-07-27 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)."]]
