自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
保持稳定的内核模块接口
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
为供应商模块维持稳定的内核模块接口 (KMI) 至关重要。GKI 内核以二进制文件的形式构建和推出,并且供应商可加载模块在单独的树中构建。生成的 GKI 内核和供应商模块必须正常运行,就如同它们是一起构建的一样。
通常情况下,Linux 社区对 Mainline 内核的内核内 ABI 稳定性这一概念并不满意。面对不同的工具链、配置和不断发展的 Linux Mainline 内核,在 Mainline 中维持稳定版 KMI 并不可行。但是,在高度约束的 GKI 环境中,借助以下约束条件或许能维持稳定的 KMI:
只能使用一个配置 gki_defconfig
来构建内核。
KMI 仅在一个内核(例如 android13-5.10
、android12-5.10
或 android13-5.15
)的相同 LTS 和 Android 版本内保持稳定。
- 不对
android-mainline
维持 KMI 稳定性。
只使用 AOSP 中提供的并且为相应分支指定的特定 Clang 工具链来构建内核和模块。
只有在符号列表中指定的已知由模块使用的符号才会受到稳定性监控,并被视为 KMI 符号。
- 最后的结果就是,供应商模块只能使用 KMI 符号。此约束通过在需要非 KMI 符号时使模块加载失败来强制执行。
KMI 分支被冻结后,可以进行更改,但不能破坏 KMI。这些更改包括:
使用封闭构建流程和 LLVM 工具链
封闭构建流程让 kernel/manifest
中的 repo
清单能够完整描述构建环境,从而确保 KMI 保持稳定。例如,android13-5.15
的清单包括工具链、构建脚本以及构建通用内核映像 (GKI) 内核所需的所有其他内容。相应的 build.config
配置文件(例如 GKI build 配置 build.config.gki.aarch64
)可确保正确地使用所含工具来生成一致的构建结果。
使用封闭构建流程还可确保树的 ABI 说明保持一致,无论此说明是 Google 生成的(例如,针对 android13-5.15
的 abi_gki_aarch64.xml
),还是在包含供应商模块的本地树中生成的。内核模块接口 (KMI) 的用于创建和比较 ABI 说明的工具也会在清单所述的 repo 中提供。
用于构建 GKI 内核的工具链必须与用于构建供应商模块的工具链完全兼容。从 Android 10 开始,所有 Android 内核都必须使用 LLVM 工具链构建。使用 GKI 后,用于构建产品内核和供应商模块的 LLVM 工具链必须生成与 AOSP 中的 LLVM 工具链相同的 ABI,并且合作伙伴必须确保 KMI 与 GKI 内核兼容。
强烈建议使用收到的构建工具,因为这些工具可以提供最佳兼容性。
后续操作
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-03-26。"],[],[],null,["# Maintain a stable kernel module interface\n\nIt's critical to maintain a stable kernel module interface (KMI) for vendor\nmodules. The GKI kernel is\nbuilt and shipped in binary form and vendor-loadable modules are built in a\nseparate tree. The resulting GKI kernel and vendor modules must work as\nthough they were built together.\n\nGenerally, the Linux community has\n[frowned on the notion of in-kernel ABI\nstability](https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst)\nfor the mainline kernel. In the face of different toolchains, configurations,\nand an ever-evolving Linux mainline kernel, it isn't feasible to maintain a\nstable KMI in mainline. However, it's possible to maintain a stable KMI in\nthe highly-constrained GKI environment with these constraints:\n\n- Only a single configuration, `gki_defconfig`, can be used to build the\n kernel.\n\n- The KMI is only stable within the same LTS and Android version of a kernel,\n such as `android14-6.1`, `android15-6.6` or `android16-6.12`.\n\n - No KMI stability is maintained for `android-mainline`.\n- Only the specific *Clang* toolchain supplied in AOSP and defined for the\n corresponding branch is used for building kernel and modules.\n\n- Only symbols known to be used by modules as specified in a symbol list are\n monitored for stability and considered KMI symbols.\n\n - The corollary is that vendor modules must use only KMI symbols. This constraint is enforced by failing module loads if non-KMI-symbols are required.\n- After the KMI branch is frozen, changes are allowed but can't break the KMI.\n These changes include the following:\n\n - Config changes\n - Kernel code changes\n - Toolchain changes (including updates)\n\nUse the hermetic build process and LLVM toolchain\n-------------------------------------------------\n\nThe hermetic build process ensures a stable KMI by having `repo` manifests in\n`kernel/manifest` completely describe the build environment. For example, the\n[manifest for `android16-6.12`](https://android.googlesource.com/kernel/manifest/+/refs/heads/common-android16-6.12/default.xml)\nincludes the toolchain, build system, and everything else required to build the\nGeneric Kernel Image (GKI) kernel. The build configuration, primarily\n[`BUILD.bazel`](https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12/BUILD.bazel),\nensures that the included tools are used correctly to generate consistent build\nresults.\n\nUsing a hermetic build process also ensures that the ABI description for the\ntree is consistent whether generated by Google (for example,\n[`gki/aarch64/abi.stg`](https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12/gki/aarch64/abi.stg)\nfor `android16-6.12`) or generated in a local tree that includes the vendor\nmodules. The\n[tools to create and compare the ABI description](https://android.googlesource.com/kernel/build/+/refs/heads/main-kernel/abi/)\nfor the Kernel Module Interface (KMI) are also provided as part of the repo\ndescribed by the manifest.\n\nThe toolchain used to build the GKI kernel must be completely compatible with\nthe toolchain used to build vendor modules. As of Android\n10, all Android kernels must be built\nwith an LLVM toolchain. With GKI, the LLVM toolchain used to build product\nkernels and vendor modules must generate the same ABI as the LLVM toolchain from\nAOSP and partners must ensure that the KMI is compatible with the GKI kernel.\nUsing the provided build tools is strongly encouraged as they provide the\nbest compatibility.\n\nWhat's next?\n------------\n\n- For instructions on building the kernel using the hermetic build process and\n LLVM toolchain, refer to refer to\n [Build kernels](/docs/setup/build/building-kernels).\n\n- For instructions on how to monitor the ABI and fix issues, refer to\n [Android Kernel ABI Monitoring](/docs/core/architecture/kernel/abi-monitor)"]]