Eine stabile Kernelmodul-Benutzeroberfläche aufrechterhalten

Es ist wichtig, eine stabile Kernelmodulschnittstelle (Kernel Module Interface, KMI) für Anbietermodule beizubehalten. Der GKI-Kernel wird in binärer Form erstellt und ausgeliefert. Anbieter-loadable Module werden in einem separaten Baum erstellt. Der resultierende GKI-Kernel und die Anbietermodule müssen so funktionieren, als wären sie zusammen erstellt worden.

Im Allgemeinen hat die Linux-Community die Vorstellung einer ABI-Stabilität im Kernel für den Mainline-Kernel abgelehnt. Angesichts der verschiedenen Toolchains, Konfigurationen und des sich ständig weiterentwickelnden Linux-Mainline-Kernels ist es nicht möglich, ein stabiles KMI in der Mainline aufrechtzuerhalten. Es ist jedoch möglich, in der stark eingeschränkten GKI-Umgebung mit den folgenden Einschränkungen einen stabilen KMI aufrechtzuerhalten:

  • Für den Build des Kernels kann nur eine einzige Konfiguration, gki_defconfig, verwendet werden.

  • Das 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 von Kernel und Modulen wird nur die spezifische Clang-Toolchain verwendet, die in AOSP enthalten 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.

    • Daraus folgt, dass in Vendormodulen nur KMI-Symbole verwendet werden dürfen. Diese Einschränkung wird durch fehlgeschlagene Modulladevorgänge erzwungen, wenn Nicht-KMI-Symbole erforderlich sind.

  • Nachdem der KMI-Branch eingefroren wurde, sind Änderungen zulässig, dürfen aber nicht zu einem Fehler im KMI führen. Diese Änderungen umfassen Folgendes:

    • Konfigurationsänderungen
    • Änderungen am Kernel-Code
    • Toolchain-Änderungen (einschließlich Updates)

Hermetischen Build-Prozess und LLVM-Toolchain verwenden

Der hermetische Build-Prozess sorgt für ein stabiles KMI, da repo-Manifeste in kernel/manifest die Build-Umgebung vollständig beschreiben. Das Manifest für android16-6.12 enthält beispielsweise die Toolchain, das Build-System und alles andere, was zum Erstellen des Generic Kernel Image (GKI)-Kernels erforderlich ist. Die Build-Konfiguration, hauptsächlich BUILD.bazel, sorgt dafür, dass die enthaltenen Tools korrekt verwendet werden, um konsistente Build-Ergebnisse zu generieren.

Durch die Verwendung eines hermetischen Build-Prozesses wird auch sichergestellt, dass die ABI-Beschreibung für den Baum konsistent ist, unabhängig davon, ob sie von Google (z. B. gki/aarch64/abi.stg für android16-6.12) oder in einem lokalen Baum mit den Anbietermodulen generiert wird. Die Tools zum Erstellen und Vergleichen der ABI-Beschreibung für die Kernelmodulschnittstelle (Kernel Module Interface, KMI) sind ebenfalls Teil des im Manifest beschriebenen Repositorys.

Die Toolchain, mit der der GKI-Kernel erstellt wird, muss vollständig mit der Toolchain kompatibel sein, mit der Herstellermodule erstellt werden. Seit Android 10 müssen alle Android-Kernel mit einer LLVM-Toolchain erstellt werden. Bei GKI muss die LLVM-Toolchain, mit der Produkt-Kernel und Anbietermodule erstellt werden, dieselbe ABI wie die LLVM-Toolchain aus AOSP generieren. Partner müssen dafür sorgen, dass das 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 dazu, wie Sie das ABI überwachen und Probleme beheben können, finden Sie unter Android Kernel ABI Monitoring.