Es gibt zwei Arten von Kernelmodulen: hardwareunabhängige GKI-Module und hardwarespezifische Anbietermodule. Auf dieser Seite finden Sie eine Übersicht über beide Arten von Modulen.
GKI-Module
GKI-Module (Generic Kernel Image) werden verwendet, um Kernelfunktionen bereitzustellen, die nicht für den Start erforderlich sind, getrennt vom generischen Kernkernel. Mit GKI-Modulen können Sie bestimmte Kernelfunktionen auswählen, wodurch die Größe des Kernel-Images und die Arbeitsspeichernutzung während der Laufzeit häufig reduziert werden. Durch die Verringerung der Größe eignet sich GKI gut für Android Go-Geräte und andere Formfaktoren mit begrenzten Ressourcen.
GKI-Module bieten auch einen Mechanismus, mit dem Anbieter neue vorgelagerte Features nach dem Meilenstein zur KMI-Fixierung integrieren können. Eingebetteter Code kann nicht ohne Erstellen eines anderen Images ersetzt werden, während Code, der als Modul bereitgestellt wird, durch ein anderes Modul ersetzt werden kann.
GKI-Module verwenden die Build-Zeitsignaturinfrastruktur des Kernels, um während der Laufzeit zwischen GKI und anderen Modulen zu unterscheiden. Unsignierte Module dürfen geladen werden, solange sie nur Symbole verwenden, die sich auf der Zulassungsliste befinden oder von anderen unsignierten Modulen bereitgestellt werden.
Es gibt zwei logische Typen von GKI-Modulen: das geschützte GKI-Modul und das ungeschützte GKI-Modul.
Geschütztes GKI-Modul
Ein geschütztes GKI-Modul wird von Google bereitgestellt, ist in keiner Weise eingeschränkt und verhält sich so, als wäre es nach dem Laden mit dem Kernel erstellt worden. Geschützte GKI-Module haben außerdem folgende Eigenschaften:
- Geschützte GKI-Module haben Zugriff auf nicht KMI-Kernelsymbole, die für Anbietermodule oder ungeschützte GKI-Module nicht verfügbar sind.
- Aus geschützten GKI-Modulen können Symbole exportiert werden, die Teil der KMI-Oberfläche werden, sofern diese Symbole in einer Symbolliste aufgeführt sind.
- Geschützte GKI-Module können nicht von Anbietermodulen überschrieben werden.
Ein geschütztes GKI-Modul ist die Standardklasse von GKI-Modulen. Alle GKI-Module gelten zum Zeitpunkt des KMI-Freeze als geschützt.
Ungeschütztes GKI-Modul
Ein ungeschütztes GKI-Modul kann von einem Anbietermodul überschrieben werden. Nach dem KMI-Freeze kann ein geschütztes GKI-Modul als nicht geschützt eingestuft werden, wenn das GKI-Team entscheidet, dass Anbieter die Standardimplementierung durch eine Version mit neuen Funktionen aus dem Upstream-Linux überschreiben müssen. Beim nächsten GKI-Release werden nicht geschützte Module als geschützt eingestuft, nachdem Upstream-Code in einem Android Common Kernel (ACK) gelandet ist. Ungeschützte GKI-Module haben folgende Eigenschaften:
- Ungeschützte GKI-Module haben denselben Zugriff auf exportierte Symbole wie Anbietermodule.
- Ungeschützte GKI-Module können keine Symbole exportieren, die von geschützten GKI-Modulen exportiert wurden.
- Bei ungeschützten GKI-Modulen müssen alle KMI-Schnittstellen so beibehalten werden, als wären sie Teil des Kernkernels.
- Nicht geschützte GKI-Module können von Anbietermodulen überschrieben werden.
Anbietermodule
Ein Anbietermodul wird von Partnern bereitgestellt, um SoC- und gerätespezifische Funktionen zu implementieren. Jedes vorhandene Kernelmodul, das nicht als Teil des GKI-Kernels bereitgestellt wird, kann als Anbietermodul bereitgestellt werden.
Da eines der Hauptziele des GKI-Projekts darin besteht, hardwarespezifischen Code im Kernkernel zu minimieren, können Anbieter davon ausgehen, dass der GKI-Kernel keine Module enthält, die ihre eigene Hardware eindeutig verwalten. So kann der Anbieter „ABC Inc.“ beispielsweise davon ausgehen, dass Konfigurationen wie CONFIG_ABC_SOC_SUPPORT ohne seine Unterstützung weder als integrierte noch als ladbare GKI-Module aktiviert werden.
Wenn ein Kernel-Treiber oder -Framework in ACK vorhanden ist, aber nicht als Teil des GKI-Kernels bereitgestellt wird, können Anbieter den Treiber ändern und als Anbietermodul bereitstellen. Solche Änderungen werden für nicht anbieterspezifische Module nicht empfohlen, da dieselben Funktionen möglicherweise in einer zukünftigen Version mit dem GKI-Kernel bereitgestellt werden. Wenn der GKI-Kernel Funktionen enthält, die von einem Anbietermodul zur Verfügung gestellt werden, wird das Anbietermodul nicht geladen. Beispielsweise ist CONFIG_GREYBUS in Android 11 nicht für GKI festgelegt. Daher können Anbieter Greybus-Anbietermodule bereitstellen. CONFIG_GREYBUS kann jedoch in Android 12 als integrierte GKI oder als Modul aktiviert werden. In diesem Fall werden keine Greybus-Anbietermodule geladen. Es wird empfohlen, die Upstream-Version nicht anbieterspezifischer Treiber zu verwenden, wenn sie als Anbietermodule bereitgestellt werden.
Sie können Anbietermodule im vendor- oder vendor_boot-Image bereitstellen. Module, die früh im Bootvorgang benötigt werden, müssen sich in vendor_boot befinden.
Das Laden von Modulen aus vendor_boot ist mit Bootzeitkosten verbunden.