Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Eine stabile Kernelmodul-Benutzeroberfläche aufrechterhalten
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Es ist wichtig, eine stabile Kernelmodulschnittstelle (KMI) für Anbietermodule zu pflegen. Der GKI-Kernel wird in Binärform erstellt und bereitgestellt. Von Anbietern ladbare Module werden in einem separaten Verzeichnis erstellt. Der daraus resultierende GKI-Kernel und die Anbietermodule müssen so funktionieren, als wären sie zusammen erstellt worden.
Im Allgemeinen hat die Linux-Community Bedenken hinsichtlich der Stabilität des In-Kernel-ABI für den Mainline-Kernel geäußert. Angesichts der verschiedenen Toolchains, Konfigurationen und des sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, eine stabile KMI im Mainline zu pflegen. Es ist jedoch möglich, unter Einhaltung der folgenden Einschränkungen eine stabile KMI in der stark eingeschränkten GKI-Umgebung aufrechtzuerhalten:
Zum Erstellen des Kernels kann nur eine einzige Konfiguration, gki_defconfig, verwendet werden.
Der KMI ist nur innerhalb derselben LTS- und Android-Version eines Kernels stabil, z. B. android14-6.1, android15-6.6 oder android16-6.12.
- Für
android-mainline wird keine KMI-Stabilität aufrechterhalten.
Für das Erstellen des Kernels und der Module wird nur die spezifische Clang-Toolchain verwendet, die in AOSP bereitgestellt und für den entsprechenden Branch definiert ist.
Nur Symbole, die bekanntermaßen von Modulen verwendet werden, wie in einer Symbolliste angegeben, werden auf Stabilität überwacht und als KMI-Symbole betrachtet.
- Das bedeutet, dass Anbietermodule nur KMI-Symbole verwenden dürfen. Diese Einschränkung wird durch fehlgeschlagene Modulladungen erzwungen, wenn keine KMI-Symbole erforderlich sind.
Nachdem der KMI-Zweig eingefroren wurde, sind Änderungen zulässig, dürfen aber die KMI nicht beeinträchtigen.
Zu diesen Änderungen gehören:
- Konfigurationsänderungen
- Änderungen am Kernelcode
- Änderungen an der Toolchain (einschließlich Updates)
Hermetischen Buildprozess und LLVM-Toolchain verwenden
Der hermetische Build-Prozess sorgt für eine stabile KMI, da die Build-Umgebung vollständig in repo-Manifesten in kernel/manifest beschrieben wird. Das Manifest für android16-6.12 enthält beispielsweise die Toolchain, das Buildsystem und alles andere, was zum Erstellen des GKI-Kernels (Generic Kernel Image) erforderlich ist. Die Build-Konfiguration, insbesondere BUILD.bazel, sorgt dafür, dass die enthaltenen Tools richtig verwendet werden, um konsistente Build-Ergebnisse zu generieren.
Durch einen hermetischen Buildprozess wird außerdem sichergestellt, dass die ABI-Beschreibung für den Verzeichnisbaum konsistent ist, unabhängig davon, ob sie von Google generiert wurde (z. B. gki/aarch64/abi.stg für android16-6.12) oder in einem lokalen Verzeichnisbaum, der die Anbietermodule enthält. Die Tools zum Erstellen und Vergleichen der ABI-Beschreibung für die Kernelmodulschnittstelle (KMI) sind ebenfalls Teil des vom Manifest beschriebenen Repos.
Die Toolchain, mit der der GKI-Kernel erstellt wird, muss vollständig mit der Toolchain kompatibel sein, die zum Erstellen von Anbietermodulen verwendet wird. Ab Android 10 müssen alle Android-Kernel mit einer LLVM-Toolchain erstellt werden. Bei GKI muss die LLVM-Toolchain, die zum Erstellen von Produktkerneln und Anbietermodulen verwendet wird, dieselbe ABI generieren wie die LLVM-Toolchain von AOSP. Außerdem müssen Partner dafür sorgen, dass die KMI mit dem GKI-Kernel kompatibel ist.
Wir empfehlen dringend, die bereitgestellten Build-Tools zu verwenden, da sie die beste Kompatibilität bieten.
Und jetzt?
Eine Anleitung zum Erstellen des Kernels mit dem hermetischen Build-Prozess und der LLVM-Toolchain finden Sie unter Kernel erstellen.
Eine Anleitung zum Überwachen des ABI und zum Beheben von Problemen finden Sie unter Android Kernel ABI Monitoring.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],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)"]]
