Generisches Kernel-Image-Projekt (GKI)

Ein Produkt-Kernel, auch als Geräte-Kernel oder OEM-Kernel bezeichnet, 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 Kernelerweiterungen zu einem Produktkernel (OEM-/Gerätekernel) führen:

Produktkernel-Erstellung vor GKI

Abbildung 1. Konstruktion des Produktkernels vor GKI

  1. Der Linux-LTS-Kernel (Long Term Support) 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 Leistungsoptimierungen hinzufügen. Der resultierende Kernel wird als Anbieter-Kernel bezeichnet.
  3. Schließlich wurde der Anbieterkernel von OEMs mit zusätzlichen Gerätetreibern und Anpassungen weiter modifiziert, die sie für erforderlich halten. Der resultierende Kern wird als Produktkern bezeichnet.

All diese Änderungen können dazu führen, dass bis zu 50% des Kernelcodes nicht aus dem Stammbaum stammen, sondern aus Upstream-Linux-Kerneln oder ACKs. Vor GKI hatte fast jedes Gerät einen benutzerdefinierten Kernel, was zu einer Kernelfragmentierung führte.

Kosten der Fragmentierung

Die Kernel-Fragmentierung hat mehrere negative Auswirkungen auf die Android-Community.

Sicherheitsupdates sind zeitaufwendig

Sicherheitspatches, die im Android Security Bulletin (ASB) aufgeführt sind, müssen in jeden Geräte-Kernel zurückportiert werden. Aufgrund der Kernelfragmentierung ist es jedoch extrem teuer, Sicherheitskorrekturen auf Android-Geräte im Einsatz zu übertragen.

Schwierige Zusammenführung von Updates mit langfristiger Unterstützung

Die LTS-Releases (Long-Term Supported, LTS) enthalten Sicherheitspatches und andere kritische Fehlerkorrekturen. Es hat sich bewährt, immer auf dem neuesten Stand der LTS-Releases zu bleiben, um Sicherheitsfixes bereitzustellen. Bei Pixel-Geräten wurde festgestellt, dass 90% der im ASB gemeldeten Kernel-Sicherheitsprobleme bereits für Geräte behoben wurden, die immer auf dem neuesten Stand sind.

Aufgrund der vielen benutzerdefinierten Änderungen an den Gerätekernen ist es jedoch schwierig, die LTS-Fehlerkorrekturen einfach in die Gerätekerne einzubinden.

Aktualisierungen der Android-Plattformversion verhindern

Aufgrund der Fragmentierung ist es schwierig, neuen Android-Funktionen, die Kerneländerungen erfordern, Geräte im Einsatz hinzuzufügen. Der Android-Framework-Code muss davon ausgehen, dass bis zu fünf Kernelversionen 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, die in einigen Fällen seit Android 8 im Jahr 2017 nicht mit neuen Funktionen erweitert wurden.

Es war schwierig, Kernel-Änderungen an Upstream-Linux-Änderungen zurückzugeben

Aufgrund der vielen Änderungen am Kernel werden die meisten Flaggschiff-Geräte mit einer Kernelversion ausgeliefert, die bereits mindestens 18 Monate alt ist. Der Kernel 4.14 wurde beispielsweise von kernel.org im November 2017 veröffentlicht und die ersten Android-Smartphones mit 4.14-Kerneln wurden im Frühjahr 2019 ausgeliefert.

Diese lange Verzögerung zwischen der Upstream-Kernel-Veröffentlichung und den Produkten erschwert es der Android-Community, die erforderlichen Funktionen und Treiber in die Upstream-Kernel einzubringen.

Fragmentierung beheben: Allgemeines Kernel-Image

Das Projekt „Generic Kernel Image“ (GKI) behebt die Kernel-Fragmentierung, indem der Kern-Kernel vereinheitlicht und die SoC- und Board-Unterstützung aus dem Kern-Kernel in ladbare Anbietermodule verschoben wird. GKI bietet außerdem eine stabile Kernel-Modul-Schnittstelle (Kernel Module Interface, KMI) für Anbietermodule, sodass Module und Kernel unabhängig voneinander aktualisiert werden können. Einige Merkmale des GKI-Kernels:

  • Der GKI-Kernel wird aus den ACK-Quellen erstellt.
  • Der GKI-Kernel besteht aus einem einzelnen Kernel-Binärcode und zugehörigen ladbaren Modulen pro Architektur und LTS-Release (derzeit nur arm64 für android11-5.4 und android12-5.4).
  • Der GKI-Kernel wird mit allen Android-Plattform-Releases getestet, die für die zugehörige ACK unterstützt werden. Während der Lebensdauer einer GKI-Kernelversion werden keine Funktionen eingestellt.
  • Der GKI-Kernel stellt Treibern innerhalb eines bestimmten LTS eine stabile KMI bereit.
  • Der GKI-Kernel enthält keinen SoC- 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 im Android 11-Plattformrelease.

Es gibt zwei GKI-Phasen:

  • 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 auf den Markt gebracht wurden.
  • GKI 2.0 wurde in Android 12 für Geräte mit 5.10-Kerneln eingeführt und ist der neue Standard für alle Geräte, die mit 5.10- oder höher ausgeliefert werden.

GKI 1.0

In GKI 1.0 müssen Geräte, die mit der Kernelversion 5.4 auf den Markt kommen, die GKI-Tests bestehen (Android 11 und höher). Zu den Zielen von GKI 1.0 gehören:

  • Vermeiden Sie Rückschritte in der Vendor Test Suite (VTS) oder Compatibility Test Suite (CTS), wenn Sie den Produktkernel durch den GKI-Kernel ersetzen.
  • Partner müssen ihren Kernel nicht mehr mit AOSP-gemeinsamen Kerneln auf dem neuesten Stand halten.
  • Grundlegende Android-Änderungen in Kernel für Geräte aufnehmen, für die ein Upgrade durchgeführt oder mit neuen Android-Releases gestartet wird.
  • Der Android-Nutzerbereich darf nicht beschädigt werden.
  • Hardwarespezifische Komponenten als ladbare Module vom Kernkernel trennen.

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

GKI 2.0

Bei GKI 2.0 müssen Geräte, die mit der Kernelversion 5.10 oder höher ausgeliefert werden, mit dem GKI-Kernel ausgeliefert werden (ab Android 12). Signierte Boot-Images sind verfügbar und werden regelmäßig mit LTS- und kritischen Fehlerkorrekturen aktualisiert. Da die Binärstabilität für das KMI beibehalten wird, können Sie diese Boot-Images installieren, ohne Änderungen an den Anbieter-Images vorzunehmen. Zu den Zielen von GKI 2.0 gehören:

  • Es dürfen keine erheblichen Leistungs- oder Leistungsrückgänge auftreten, wenn der Produktkernel durch den GKI-Kernel ersetzt wird.
  • Partnern die Möglichkeit geben, ohne Einbindung des Anbieters Kernel-Sicherheitsupdates und Fehlerkorrekturen bereitzustellen
  • Reduzieren Sie die Kosten für die Aktualisierung der Kernel-Hauptversion für Geräte (z. B. von v5.10 auf den LTS-Kernel 2021).
  • Verwalten Sie eine einzige GKI-Kernel-Binärdatei pro Architektur, indem Sie die Kernel-Versionen mit einem eindeutigen Upgradeprozess aktualisieren.

GKI 2.0 entspricht dem aktuellen Stand der Android-Kernel. Die Kerneldokumentation außerhalb der Unterabschnitte GKI 1.0 und Vorherige Kernel (≤ 4.19) entspricht der GKI 2.0-Architektur.