2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
커널 모듈 지원
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
GKI(Generic Kernel Image)에는 기기가 파티션을 마운트하는 데 필요한 드라이버 지원이 포함되어 있지 않을 수 있습니다. 기기가 파티션을 마운트하고 부팅을 계속할 수 있도록 지원하기 위해 1단계 init를 향상함으로써 램디스크에 있는 커널 모듈을 로드할 수 있습니다. 램디스크는 일반 및 공급업체 램디스크로 분할되어 있습니다. 공급업체 커널 모듈은 공급업체 램디스크에 저장됩니다. 커널 모듈이 로드되는 순서는 설정 가능합니다.
모듈 위치
램디스크는 1단계 init,용 파일 시스템이자, A/B 및 가상 A/B 기기의 복구/fastbootd 이미지용 파일 시스템입니다. 이 파일 시스템은 부트로더에 의해 연결되는 2개의 CPIO 아카이브로 구성된 initramfs입니다. 공급업체 부팅 파티션에 공급업체 램디스크로 저장되는 첫 번째 CPIO 아카이브에는 다음 구성요소가 포함됩니다.
- 1단계
init 공급업체 커널 모듈(/lib/modules/에 있음)
modprobe 구성 파일(/lib/modules/에 있음): 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에 있음)
GKI와 함께 boot.img의 램디스크로 제공되며 첫 번째 위에 적용되는 두 번째 CPIO 아카이브에는 first_stage_init 및 종속되는 라이브러리가 포함됩니다.
1단계 init에서 모듈 로드
1단계 init는 램디스크의 /lib/modules/에서 modprobe 구성 파일을 읽는 것으로 시작됩니다. 다음으로, /lib/modules/modules.load(또는 복구의 경우 /lib/modules/modules.load.recovery)에 지정된 모듈 목록을 읽고, 이전에 로드된 파일에 지정된 구성에 따라 각 모듈을 순서대로 로드하려고 합니다. 하드 또는 소프트 종속 항목을 충족하기 위해 요청된 순서에서 벗어날 수 있습니다.
빌드 지원, 1단계 init
공급업체 램디스크 CPIO에 복사할 커널 모듈을 지정하려면 BOARD_VENDOR_RAMDISK_KERNEL_MODULES에 나열합니다. 빌드는 이러한 모듈에서 depmod를 실행하고 결과로 생성된 modprobe 구성 파일을 공급업체 램디스크 CPIO에 넣습니다.
또한 빌드는 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가 호출되고 매크로가 makefile에서 확장될 때 커널 모듈이 빌드되지 않아서 매크로가 비어 있기 때문입니다.
이 문제를 해결하기 위해 공급업체는 커널 빌드에서 각 파티션에 복사할 커널 모듈이 포함된 zip 보관 파일을 생성하도록 할 수 있습니다.
BOARD_*_KERNEL_MODULES_ARCHIVE에서 이 zip 보관 파일의 경로를 설정합니다. 여기서 *는 파티션의 이름입니다(예: 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에서 해당 하위 집합의 콘텐츠를 지정합니다.
이 페이지에 언급된 공급업체 램디스크가 포함된 공급업체 부팅 파티션을 만드는 방법에 관해 알아보려면 부팅 파티션을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 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)."]]
