Android Common Kernels (ACKs) sind die Grundlage für alle Android-Produktkerne. Vendor- und Device-Kernel sind ACKs nachgeschaltet. Anbieter fügen Unterstützung für SoCs und Peripheriegeräte hinzu, indem sie den Kernel-Quellcode ändern und Gerätetreiber hinzufügen. Diese Modifikationen können so umfangreich sein, dass bis zu 50 % des Codes, der auf einem Gerät ausgeführt wird, Out-of-Tree-Code ist und nicht von Upstream-Linux oder von allgemeinen AOSP-Kerneln stammt.
Somit besteht ein Gerätekern aus:
- Upstream: Der Linux-Kernel von kernel.org
- AOSP: Zusätzliche Android-spezifische Patches von allgemeinen AOSP-Kerneln
- Anbieter: Aktivierungs- und Optimierungspatches für SoCs und Peripheriegeräte von Anbietern
- OEM/Gerät: Zusätzliche Gerätetreiber und Anpassungen
Fast jedes Gerät hat einen benutzerdefinierten Kernel. Dies ist Kernel-Fragmentierung.
Abbildung 1. Die Android-Kernel-Hierarchie führt zu Fragmentierung
Die Kosten der Fragmentierung
Die Kernel-Fragmentierung hat mehrere negative Auswirkungen auf die Android-Community.
Sicherheitsupdates sind arbeitsintensiv
Im Android Security Bulletin (ASB) genannte Sicherheitspatches müssen in jeden Gerätekernel zurückportiert werden. Aufgrund der Kernel-Fragmentierung ist es jedoch unerschwinglich teuer, Sicherheitsfixes auf Android-Geräten im Feld zu verbreiten.
Es ist schwierig, langfristig unterstützte Updates zusammenzuführen
Die LTS-Versionen (Long-Term Supported) enthalten Sicherheitskorrekturen und andere kritische Fehlerbehebungen. Mit LTS-Releases auf dem Laufenden zu bleiben, hat sich als die effektivste Methode zur Bereitstellung von Sicherheitsfixes erwiesen. Auf Pixel-Geräten wurde festgestellt, dass 90 % der im ASB gemeldeten Kernel-Sicherheitsprobleme bereits für Geräte behoben wurden, die auf dem neuesten Stand sind.
Bei all den benutzerdefinierten Änderungen in den Gerätekernen ist es jedoch schwierig, die LTS-Fixes einfach in Gerätekerne einzufügen.
Hemmt Release-Upgrades der Android-Plattform
Die Fragmentierung erschwert neue Android-Funktionen, die Kernel-Änderungen erfordern, um Geräte im Feld hinzuzufügen. Android Framework-Code muss davon ausgehen, dass bis zu fünf Kernelversionen unterstützt werden und dass keine Kerneländerungen für die neue Plattformversion vorgenommen wurden (Android 10 unterstützt die Kernel 3.18, 4.4, 4.9, 4.14 und 4.19, was in einigen Fällen nicht der Fall war mit neuen Funktionen seit Android 8 im Jahr 2017 erweitert).
Schwierig, Kernel-Änderungen an Upstream-Linux zurückzugeben
Bei all den Änderungen am Kernel werden die meisten Flaggschiff-Geräte mit einer Kernel-Version ausgeliefert, die bereits mindestens 18 Monate alt ist. Beispielsweise wurde der 4.14-Kernel im November 2017 von kernel.org veröffentlicht und die ersten Android-Telefone mit 4.14-Kernel wurden im Frühjahr 2019 ausgeliefert.
Diese lange Verzögerung zwischen der Veröffentlichung des Upstream-Kernels und den Produkten erschwert es der Android-Community, die benötigten Funktionen und Treiber in die Upstream-Kernel einzuspeisen.
Behebung der Fragmentierung: Generisches Kernel-Image
Das Projekt Generic Kernel Image (GKI) befasst sich mit der Kernel-Fragmentierung, indem es den Kernel vereinheitlicht und die SoC- und Board-Unterstützung aus dem Kernel in ladbare Anbietermodule verlagert. GKI bietet auch ein stabiles Kernel Module Interface (KMI) für Anbietermodule, sodass Module und Kernel unabhängig voneinander aktualisiert werden können. Einige Merkmale des GKI-Kernels sind:
- Der GKI-Kernel wird aus den ACK-Quellen erstellt.
- Der GKI-Kernel ist eine Single-Kernel-Binärdatei plus zugehörige ladbare Module pro Architektur, pro LTS-Release (derzeit nur arm64 für
android11-5.4undandroid12-5.4). - Der GKI-Kernel wird mit allen Versionen der Android-Plattform getestet, die für das zugehörige ACK unterstützt werden. Für die Lebensdauer einer GKI-Kernelversion gibt es keine veralteten Funktionen.
- Der GKI-Kernel stellt Treibern innerhalb eines bestimmten LTS ein stabiles KMI zur Verfügung.
- Der GKI-Kernel enthält keinen SoC-spezifischen oder Board-spezifischen Code.
Ein Bild der GKI-Architektur finden Sie in der Kernel-Übersicht .
GKI ist eine komplexe Änderung, die in mehreren Phasen eingeführt wurde, beginnend mit den v5.4-Kerneln in der Plattformversion von Android 11.
Derzeit gibt es zwei GKI-Stufen:
- GKI 1.0 wurde in Android 11 für Geräte mit 5.4-Kernel eingeführt. GKI 1.0 gilt für alle Geräte, die mit 5.4-Kernel ausgeliefert werden, auch für solche, die mit Android 12 oder Android 13 gestartet wurden.
- GKI 2.0 wurde in Android 12 für Geräte mit Kernel 5.10 eingeführt und ist der neue Standard für alle Geräte, die mit Kernel 5.10 oder höher ausgeliefert werden.
GKI 1.0
In GKI 1.0 müssen Geräte, die mit der Kernel-Version 5.4 gestartet werden, die GKI-Tests bestehen (Android 11 und spätere Plattformversionen). Zu den Zielen von GKI 1.0 gehören:
- Vermeiden Sie Regressionen in der Vendor Test Suite (VTS) oder Compatibility Test Suite (CTS) , wenn Sie den Produkt-Kernel durch den GKI-Kernel ersetzen.
- Reduzieren Sie die Belastung für Partner, deren Kernel mit AOSP Common Kernels auf dem neuesten Stand zu halten.
- Nehmen Sie grundlegende Android-Änderungen in Kernels für Geräte auf, die mit neuen Android-Versionen aktualisiert und gestartet werden.
- Unterbrechen Sie nicht den Android-Benutzerbereich.
- Trennen Sie hardwarespezifische Komponenten vom Kernel als ladbare Module.
Die GKI 1.0-Dokumentation finden Sie im GKI 1.0-Abschnitt .
GKI 2.0
In GKI 2.0 müssen Geräte, die mit der Kernel-Version 5.10 oder höher gestartet werden, mit dem GKI-Kernel ausgeliefert werden (ab Android 12). Signierte Boot-Images sind verfügbar und werden regelmäßig mit LTS und kritischen Fehlerbehebungen aktualisiert. Da die Binärstabilität für das KMI aufrechterhalten wird, können Sie diese Boot-Images installieren, ohne Änderungen an den Anbieter-Images vorzunehmen. Zu den Zielen von GKI 2.0 gehören:
- Führen Sie keine erheblichen Leistungs- oder Leistungsregressionen ein, wenn Sie den Produktkernel durch den GKI-Kernel ersetzen.
- Ermöglichen Sie es Partnern, Kernel-Sicherheitskorrekturen und Fehlerkorrekturen ohne Beteiligung des Anbieters bereitzustellen.
- Reduzieren Sie die Kosten für die Aktualisierung der Kernel-Hauptversion für Geräte (z. B. von v5.10 auf den 2021 LTS-Kernel).
- Pflegen Sie eine einzelne GKI-Kernel-Binärdatei pro Architektur, indem Sie Kernel-Versionen mit einem klaren Prozess für das Upgrade aktualisieren.
GKI 2.0 repräsentiert den aktuellsten Stand der Android-Kernel. Die Kernel-Dokumentation außerhalb der Unterabschnitte GKI 1.0 und frühere Kernel (<=4.19) spiegelt die GKI 2.0-Architektur wider.