Es gibt zwei Arten von Kernelmodulen: hardwareunabhängige GKI-Module und hardwarespezifische Anbietermodule. Auf dieser Seite finden Sie einen Überblick über beide Arten von Modulen.
GKI-Module
GKI-Module (Generic Kernel Image) werden verwendet, um Kernel-Funktionen, die nicht für den Start erforderlich sind, getrennt vom generischen Core-Kernel bereitzustellen. Mit GKI-Modulen können Sie bestimmte Kernel-Funktionen auswählen, die verwendet werden sollen. Dadurch wird oft die Größe des Kernel-Images und der Arbeitsspeicherverbrauch zur Laufzeit reduziert. Durch die geringere Größe eignet sich GKI gut für Android Go-Geräte und andere Formfaktoren mit eingeschränkten Ressourcen.
GKI-Module bieten auch einen Mechanismus, mit dem Anbieter nach dem KMI-Freeze-Meilenstein neue Upstream-Funktionen einbinden können. Integrierter Code kann nicht ersetzt werden, ohne ein anderes Image zu erstellen. Code, der als Modul bereitgestellt wird, kann dagegen durch ein anderes Modul ersetzt werden.
GKI-Module verwenden die Signaturinfrastruktur des Kernels zur Build-Zeit, um zur Laufzeit zwischen GKI- und anderen Modulen zu unterscheiden. Nicht signierte Module dürfen geladen werden, sofern sie nur Symbole verwenden, die auf der Zulassungsliste stehen oder von anderen nicht signierten Modulen bereitgestellt werden.
Es gibt zwei logische Arten von GKI-Modulen: geschütztes GKI-Modul und ungeschütztes 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. Außerdem haben geschützte GKI-Module die folgenden Eigenschaften:
- Geschützte GKI-Module haben Zugriff auf Nicht-KMI-Kernelsymbole, die für Anbietermodule oder ungeschützte GKI-Module nicht verfügbar sind.
- Geschützte GKI-Module können Symbole exportieren, die Teil der KMI-Oberfläche werden, sofern diese Symbole in einer Symbolliste aufgeführt sind.
- Geschützte GKI-Module können nicht durch Anbietermodule ü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 nicht geschütztes GKI-Modul kann durch ein Anbietermodul überschrieben werden. Nach dem KMI-Freeze kann ein geschütztes GKI-Modul als ungeschützt neu klassifiziert werden, wenn das GKI-Team entscheidet, dass Anbieter die Standardimplementierung mit einer Version überschreiben müssen, die neue Funktionen aus dem Upstream-Linux enthält. In der nächsten GKI-Version werden ungeschützte Module neu als geschützt klassifiziert, nachdem der Upstream-Code in einem Android Common Kernel (ACK) landet. Nicht geschützte GKI-Module haben die folgenden Eigenschaften:
- Nicht geschützte GKI-Module haben denselben Zugriff auf exportierte Symbole wie Anbietermodule.
- Nicht geschützte GKI-Module können keine Symbole exportieren, die von geschützten GKI-Modulen exportiert werden.
- Bei ungeschützten GKI-Modulen müssen alle KMI-Schnittstellen so beibehalten werden, als wären sie Teil des Core-Kernels.
- Nicht geschützte GKI-Module können durch Anbietermodule überschrieben werden.
Anbietermodule
Ein Anbietermodul wird von Partnern bereitgestellt, um SoC- und gerätespezifische Funktionen zu implementieren. Alle vorhandenen Kernelmodule, die nicht Teil des GKI-Kernels sind, können als Anbietermodul bereitgestellt werden.
Eines der Hauptziele des GKI-Projekts ist es, hardwarespezifischen Code im Core-Kernel zu minimieren. Daher können Anbieter davon ausgehen, dass der GKI-Kernel keine Module enthält, die eindeutig ihre eigene Hardware verwalten. Beispielsweise kann der Anbieter ABC Inc. 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 Kerneltreiber oder ‑framework in ACK vorhanden ist, aber nicht als Teil des GKI-Kernels ausgeliefert wird, können Anbieter den Treiber ändern und als Anbietermodul ausliefern. 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 bereitgestellt werden, wird das Anbietermodul nicht geladen. In Android 11 ist CONFIG_GREYBUS beispielsweise nicht für GKI festgelegt, sodass Anbieter Greybus-Anbietermodule bereitstellen können. CONFIG_GREYBUS kann jedoch in Android 12 als GKI-integriert oder als Modul aktiviert sein. In diesem Fall werden Greybus-Anbietermodule nicht geladen. Es empfiehlt sich, die Upstream-Version von nicht anbieterspezifischen Treibern zu verwenden, wenn sie als Anbietermodule bereitgestellt werden.
Sie können Vendormodule 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 Kosten für die Bootzeit verbunden.