Es ist wichtig, eine stabile Kernelmodulschnittstelle (KMI) für die Anbietermodule zu haben. 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:
Nur eine einzige Konfiguration (
gki_defconfig) kann zum Erstellen des Kernels verwendet werden.Der KMI ist nur innerhalb derselben LTS- und Android-Version eines Kernels stabil, z. B.
android13-5.10,android12-5.10oderandroid13-5.15.- Für
android-mainlinewird keine KMI-Stabilität aufrechterhalten.
- Für
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.
- Folglich dürfen in den Anbietermodulen nur KMI-Symbole verwendet werden. 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 Aktualisierungen)
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 android13-5.15 enthält beispielsweise die Toolchain, Build-Scripts und alles andere, was zum Erstellen des GKI-Kernels (Generic Kernel Image) erforderlich ist. Die entsprechenden build.config-Konfigurationsdateien, z. B. die GKI-Build-Konfiguration build.config.gki.aarch64, sorgen dafür, dass die enthaltenen Tools korrekt 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. abi_gki_aarch64.xml für android13-5.15) oder in einem lokalen Verzeichnisbaum, der die Anbietermodule enthält. Die Tools zum Erstellen und Vergleichen der ABI-Beschreibung für die Kernel-Modul-Schnittstelle (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-Kernels mit einer LLVM-Toolchain erstellt werden. Bei GKI muss die LLVM-Toolchain, die zum Erstellen von Produktkernels und Anbietermodulen verwendet wird, dieselbe ABI generieren wie die LLVM-Toolchain von AOSP. Partner müssen sicherstellen, 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.
Wie geht es weiter?
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.