[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Kernel modules overview\n\nThere are two types of kernel modules: hardware agnostic\n[GKI modules](#gki-modules) and hardware-specific\n[vendor modules](#vendor-modules). This page provides an overview of both types\nof modules.\n\nGKI modules\n-----------\n\nGeneric kernel image (GKI) modules are used to deliver nonboot-required kernel\ncapabilities separate from the generic core kernel. With GKI modules, you can\nchoose specific kernel capabilities to use, often reducing kernel image size\nand runtime memory consumption. The reduction in size makes GKI well suited for\nAndroid Go devices and other resource-restricted form factors.\n\nGKI modules also provide a mechanism to let vendors incorporate new\nupstream features after the KMI freeze milestone. Built-in code\ncan't be replaced without building another image, whereas code delivered as a\nmodule can be replaced by another module.\n\nGKI modules use the kernel's build time signing infrastructure to differentiate\nbetween GKI and other modules at run time. Unsigned modules are allowed to load\nas long as they only use symbols appearing on the allowlist or provided by other\nunsigned modules.\n| **Note:** For an overview of GKI-related terms, refer to [Kernel overview](/docs/core/architecture/kernel).\n\nThere are two logical types of GKI modules: *protected GKI module*\nand *unprotected GKI module*.\n\n### Protected GKI module\n\nA protected GKI module is delivered by Google, isn't restricted in any way, and\nbehaves as though it is built with the kernel after loading. Additionally,\nprotected GKI modules have the following characteristics:\n\n- Protected GKI modules have access to non-KMI kernel symbols that aren't available to vendor modules or unprotected GKI modules.\n- Protected GKI modules can export symbols that become part of the KMI surface as long as those symbols are cited in a symbol list.\n- Protected GKI modules can't be overridden by vendor modules.\n\nA protected GKI module is the default class of GKI modules. All GKI\nmodules are considered protected at the time of KMI freeze.\n\n### Unprotected GKI module\n\nAn unprotected GKI module can be overridden by a vendor module. After KMI freeze,\na protected GKI module might be reclassified as unprotected if the GKI team\ndecides that vendors need to override the default implementation\nwith a version that includes new features from upstream Linux. On the next\nGKI release, unprotected modules are reclassified as protected after\nupstream code lands in an Android Common Kernel (ACK). Unprotected GKI modules\nhave the following characteristics:\n\n- Unprotected GKI modules have the same access to exported symbols as vendor modules.\n- Unprotected GKI modules can't export symbols exported by protected GKI modules.\n- Unprotected GKI modules must preserve any KMI interfaces as though part of the core kernel.\n- Unprotected GKI modules can be overridden by vendor modules.\n\nVendor modules\n--------------\n\nA vendor module is delivered by partners to implement SoC and device-specific\ncapabilities. Any existing kernel module that isn't delivered as part of the\nGKI kernel can be delivered as a vendor module.\n\nSince one of the primary goals of the GKI project is to minimize\nhardware-specific code in the core kernel, vendors can expect that the GKI\nkernel won't include modules that are clearly managing their own hardware. For\nexample, vendor ABC Inc. can expect that configs such as\n`CONFIG_ABC_SOC_SUPPORT` won't be enabled either as built-in or loadable\nGKI modules without their support.\n\nIf a kernel driver or framework exists in ACK, but isn't delivered as part of\nthe GKI kernel, vendors can modify the driver and deliver it as a vendor\nmodule. Such modifications are discouraged for non vendor-specific modules\nbecause the same capabilities might be delivered with the GKI kernel in a\nfuture release. When the GKI kernel contains capabilities provided by a vendor\nmodule, the vendor module won't load. For example,\n`CONFIG_GREYBUS` isn't set for GKI in Android 11, so\nvendors may deliver greybus vendor modules. However, `CONFIG_GREYBUS` might be\nenabled as a GKI built-in or module in Android 12, in\nwhich case greybus vendor modules won't be loaded. A best practice is to use\nthe upstream version of non vendor-specific drivers if they are delivered as\nvendor modules.\n\nYou can deliver vendor modules in the `vendor` or the\n[`vendor_boot`](/devices/bootloader/partitions/vendor-boot-partitions)\nimage. Modules required early in the boot process must be in `vendor_boot`.\nThere is a boot-time cost associated with loading modules from `vendor_boot`."]]