از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
پشتیبانی از ماژول هسته
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
یک تصویر هسته عمومی (GKI) ممکن است شامل پشتیبانی درایور مورد نیاز برای فعال کردن دستگاه برای نصب پارتیشن ها نباشد. برای فعال کردن دستگاه برای نصب پارتیشن‌ها و ادامه راه‌اندازی، init مرحله اول برای بارگذاری ماژول‌های هسته موجود در ramdisk بهبود می‌یابد. ramdisk به دو دسته عمومی و فروشنده تقسیم می شود. ماژول های هسته فروشنده در ramdisk فروشنده ذخیره می شوند. ترتیب بارگذاری ماژول های هسته قابل تنظیم است.
مکان ماژول
ramdisk سیستم فایلی برای مرحله اول init, و برای بازیابی/تصویر فست بوت در A/B و A/B مجازی است. این یک initramfs متشکل از دو آرشیو cpio است که توسط بوت لودر به هم متصل می شوند. اولین بایگانی cpio، که به عنوان ramdisk فروشنده در پارتیشن vendor-boot ذخیره می‌شود، شامل این اجزا است:
- ماژول‌های هسته فروشنده
init مرحله اول، واقع در /lib/modules/ . - فایل‌های پیکربندی
modprobe ، واقع در /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 و Virtual A/B، در /lib/modules .
آرشیو cpio دوم که با GKI به عنوان ramdisk boot.img ارائه می شود و در بالای اولین مورد اعمال می شود، شامل first_stage_init و کتابخانه هایی است که به آن بستگی دارد.
بارگذاری ماژول در مرحله اول init
init مرحله اول با خواندن فایل های پیکربندی modprobe از /lib/modules/ روی ramdisk شروع می شود. سپس، فهرست ماژول‌های مشخص‌شده در /lib/modules/modules.load (یا در مورد بازیابی، /lib/modules/modules.load.recovery ) را می‌خواند و سعی می‌کند هر یک از آن ماژول‌ها را به ترتیب بارگذاری کند، طبق پیکربندی مشخص‌شده در فایل‌های بارگذاری‌شده قبلی. دستور درخواستی ممکن است برای ارضای وابستگی های سخت یا نرم از آن منحرف شود.
ساخت پشتیبانی، مرحله اول شروع
برای تعیین ماژول‌های هسته برای کپی شدن در cpio ramdisk فروشنده، آنها را در BOARD_VENDOR_RAMDISK_KERNEL_MODULES فهرست کنید. بیلد روی این ماژول‌ها depmod اجرا می‌کند و فایل‌های پیکربندی modprobe را در cpio ramdisk فروشنده قرار می‌دهد.
این بیلد همچنین یک فایل modules.load ایجاد می کند و آن را در فروشنده ramdisk 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 10 و نسخه‌های پایین‌تر وجود دارد، ماژول‌های هسته فهرست‌شده در BOARD_VENDOR_KERNEL_MODULES توسط پلتفرم Android در پارتیشن فروشنده در /vendor/lib/modules کپی می‌شوند. ساخت پلتفرم depmod را روی این ماژول ها اجرا می کند و فایل های خروجی depmod را در پارتیشن فروشنده در همان مکان کپی می کند. مکانیسم بارگیری ماژول‌های هسته از /vendor مانند نسخه‌های قبلی اندروید باقی می‌ماند. این تصمیم شماست که چگونه و چه زمانی این ماژول ها را بارگیری کنید، اگرچه معمولاً این کار با استفاده از اسکریپت های init.rc انجام می شود.
Wildcards و ساختن هسته یکپارچه
فروشندگانی که ساخت هسته دستگاه خود را با ساخت پلتفرم Android ترکیب می‌کنند، ممکن است با استفاده از ماکروهای BOARD ذکر شده در بالا برای تعیین ماژول‌های هسته برای کپی شدن در دستگاه، با مشکل مواجه شوند. اگر فروشنده بخواهد از فهرست کردن ماژول‌های هسته در فایل‌های ساخت پلتفرم دستگاه خودداری کند، می‌تواند از علامت عام استفاده کند ( $(wildcard device/vendor/mydevice/*.ko ). توجه داشته باشید که علامت عام در مورد ساخت هسته یکپارچه کار نمی‌کند، زیرا زمانی که make فراخوانی می‌شود و ماکروهای ماکرو ساخته می‌شوند، ماژول‌های make گسترش می‌یابند. ماکروها خالی هستند
برای حل این مشکل، ممکن است فروشنده از ساخت هسته خود بخواهد یک بایگانی فشرده حاوی ماژول های هسته برای کپی شدن در هر پارتیشن ایجاد کند. مسیر آن بایگانی فشرده را در BOARD_*_KERNEL_MODULES_ARCHIVE تنظیم کنید که * نام پارتیشن است (مانند BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). پلتفرم اندروید این آرشیو فشرده را در مکان مناسب استخراج می کند و depmod روی ماژول ها اجرا می کند.
آرشیو فشرده ماژول هسته باید دارای یک قانون ساخت باشد که تضمین کند ساخت پلتفرم می تواند در صورت لزوم آرشیو ایجاد کند.
بازیابی
در نسخه‌های قبلی اندروید، ماژول‌های هسته مورد نیاز برای بازیابی در BOARD_RECOVERY_KERNEL_MODULES مشخص شده‌اند. در اندروید 12، ماژول‌های هسته مورد نیاز برای بازیابی همچنان با استفاده از این ماکرو مشخص می‌شوند. با این حال، ماژول‌های هسته بازیابی در cpio ramdisk فروشنده، به جای cpio ramdisk عمومی کپی می‌شوند. به‌طور پیش‌فرض، همه ماژول‌های هسته فهرست‌شده در BOARD_RECOVERY_KERNEL_MODULES در مرحله init بارگیری می‌شوند. اگر می‌خواهید فقط زیر مجموعه‌ای از این ماژول‌ها بارگیری شود، محتویات آن زیر مجموعه را در BOARD_RECOVERY_KERNEL_MODULES_LOAD مشخص کنید.
برای آشنایی با ایجاد یک پارتیشن بوت فروشنده (که حاوی ramdisk فروشنده ذکر شده در این صفحه است)، به Boot partitions مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
