Das Generic Kernel Image (GKI)-Projekt

Ein Produktkernel , auch Gerätekernel oder OEM-Kernel genannt, ist der Kernel, den Sie auf Ihrem Gerät ausliefern. Vor GKI wurde der Produktkernel aus einer Reihe von Upstream-Kerneländerungen abgeleitet. Abbildung 1 zeigt, wie Kernel-Ergänzungen einen Produktkernel (OEM-/Gerätekernel) ergeben:

Kernelkonstruktion des Produkts vor GKI

Abbildung 1. Kernelkonstruktion des Produkts vor GKI.

  1. Der Linux Long Term Supported (LTS) -Kernel von kernel.org wurde mit Android-spezifischen Patches modifiziert, was zu einem Android Common Kernel (ACK) führte.
  2. Das ACK wurde von Anbietern geändert, die Unterstützung für ihr System-on-a-Chip (SoC) hinzugefügt haben. Die Anbieter können auch Leistungs- oder Energieoptimierungen hinzufügen. Der resultierende Kernel wird Vendor-Kernel genannt.
  3. Schließlich wurde der Herstellerkernel von OEMs mit zusätzlichen Gerätetreibern und Anpassungen, die sie für notwendig erachteten, weiter modifiziert. Der resultierende Kernel wird als Produktkernel bezeichnet.

Alle diese Änderungen können dazu führen, dass bis zu 50 % des Kernel-Codes nicht aus dem Baum stammen und nicht von Upstream-Linux-Kerneln oder ACKs stammen. Vor GKI verfügte fast jedes Gerät über einen benutzerdefinierten Kernel, was zu einer Kernelfragmentierung führte.

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, Sicherheitskorrekturen vor Ort auf Android-Geräten zu verbreiten.

Es ist schwierig, langfristig unterstützte Updates zusammenzuführen

Die Long-Term Supported (LTS) -Releases enthalten Sicherheitsfixes und andere kritische Fehlerbehebungen. Sich über LTS-Releases auf dem Laufenden zu halten, hat sich als die effektivste Methode zur Bereitstellung von Sicherheitskorrekturen erwiesen. Bei 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 bleiben.

Bei all den benutzerdefinierten Änderungen in den Gerätekerneln ist es jedoch schwierig, die LTS-Korrekturen einfach in die Gerätekerne zu integrieren.

Verhindert Release-Upgrades der Android-Plattform

Die Fragmentierung erschwert das Hinzufügen neuer Android-Funktionen, die Kerneländerungen erfordern, zu Geräten im Feld. Der Android Framework-Code muss davon ausgehen, dass bis zu fünf Kernel-Versionen unterstützt werden und dass für die neue Plattformversion keine Kernel-Änderungen 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). erweitert um neue Funktionen seit Android 8 im Jahr 2017).

Es ist schwierig, Kernel-Änderungen wieder in das Upstream-Linux einzubringen

Da alle Änderungen am Kernel vorgenommen werden, werden die meisten Flaggschiff-Geräte mit einer Kernelversion 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 macht es für die Android-Community schwierig, benötigte Funktionen und Treiber in die Upstream-Kernel einzuspeisen.

Behebung der Fragmentierung: Generisches Kernel-Image

Das Generic Kernel Image (GKI)-Projekt bekämpft die Kernel-Fragmentierung, indem es den Kernel vereinheitlicht und die SoC- und Board-Unterstützung aus dem Kernel in ladbare Herstellermodule verlagert. GKI bietet außerdem eine stabile Kernel Module Interface (KMI) für Herstellermodule, 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 mit zugehörigen ladbaren Modulen pro Architektur und LTS-Version (derzeit nur arm64 für android11-5.4 und android12-5.4 ).
  • Der GKI-Kernel wird mit allen Android-Plattformversionen getestet, die für das zugehörige ACK unterstützt werden. Während der gesamten 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 Android 11-Plattformversion.

Derzeit gibt es zwei GKI-Stufen:

  • GKI 1.0 wurde in Android 11 für Geräte mit 5.4 Kerneln eingeführt. GKI 1.0 gilt für alle Geräte, die mit 5.4-Kerneln 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 5.10-Kernel eingeführt und ist der neue Standard für alle Geräte, die mit 5.10-Kernel 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 Produktkernel durch den GKI-Kernel ersetzen.
  • Reduzieren Sie den Aufwand für Partner, ihren Kernel mit den gemeinsamen AOSP-Kerneln auf dem neuesten Stand zu halten.
  • Integrieren Sie grundlegende Android-Änderungen in Kernel für Geräte, die mit neuen Android-Versionen aktualisiert und gestartet werden.
  • Zerstören Sie nicht den Android-Benutzerbereich.
  • Trennen Sie hardwarespezifische Komponenten als ladbare Module vom Kernel.

Die Dokumentation zu GKI 1.0 finden Sie im Abschnitt zu GKI 1.0 .

GKI 2.0

In GKI 2.0 müssen Geräte, die mit 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 gewahrt bleibt, 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 Leistungseinbußen ein, wenn Sie den Produktkernel durch den GKI-Kernel ersetzen.
  • Ermöglichen Sie Partnern die Bereitstellung von Kernel-Sicherheitskorrekturen und Fehlerbehebungen ohne Beteiligung des Anbieters.
  • Reduzieren Sie die Kosten für die Aktualisierung der Hauptkernelversion für Geräte (z. B. von v5.10 auf den 2021 LTS-Kernel).
  • Behalten Sie eine einzelne GKI-Kernel-Binärdatei pro Architektur bei, indem Sie Kernelversionen mit einem klaren Upgrade-Prozess aktualisieren.

GKI 2.0 repräsentiert den aktuellsten Stand der Android-Kernel. Die Kernel-Dokumentation außerhalb der Unterabschnitte „GKI 1.0“ und „Vorherige Kernel (<=4.19)“ spiegelt die GKI 2.0-Architektur wider.