Gemeinsame Android-Kernel

AOSP-Common-Kernel (auch als Android-Common-Kernel oder ACKs bezeichnet) sind nachgelagert von kernel.org-Kerneln und enthalten Patches, die für die Android-Community von Interesse sind und nicht in Mainline- oder LTS-Kernel (Long Term Supported) zusammengeführt wurden. Diese Patches können Folgendes umfassen:

• Backports und Cherry-Picks von Upstream-Funktionen, die für Android-Funktionen erforderlich sind
• Funktionen, die für Android-Geräte verfügbar sind, aber noch in der Entwicklung sind
• Anbieter-/OEM-Funktionen, die für andere Ökosystempartner nützlich sind

android-mainline ist der primäre Entwicklungszweig für Android-Funktionen. Der Linux-Mainline-Kernel wird in android-mainline zusammengeführt, sobald Linus Torvalds eine Version oder einen Release-Kandidaten veröffentlicht. Vor 2019 wurden allgemeine Android-Kernel durch Klonen des zuletzt deklarierten LTS-Kernels und Hinzufügen der Android-spezifischen Patches erstellt. 2019 wurde dieser Prozess geändert, um den neuen gemeinsamen Android-Kernel von android-mainline abzuzweigen. Dieses neue Modell vermeidet den erheblichen Aufwand für das Forward-Porting und Testen von Android-Patches, indem es das gleiche Ergebnis inkrementell erreicht. android-mainline wird kontinuierlich getestet. Das Modell enthält daher von Anfang an einen hochwertigen Kernel.

Wenn ein neuer LTS-Zweig upstream deklariert wird, wird der entsprechende gemeinsame Kernel von android-mainline verzweigt. So können Partner ein Projekt vor der Deklaration der LTS-Version starten, indem sie android-mainline zusammenführen. Nachdem der neue gemeinsame Kernel-Branch erstellt wurde, können Partner die Merge-Quelle nahtlos in den neuen Branch ändern.

Andere gängige Kernel-Branches werden regelmäßig mit dem zugehörigen LTS-Kernel zusammengeführt. Diese Zusammenführungen erfolgen normalerweise unmittelbar nach der Veröffentlichung des LTS-Release. Als beispielsweise Linux 6.1.75 veröffentlicht wurde, wurde es in den gemeinsamen Kernel 6.1 (android14-6.1) aufgenommen. Partner werden dringend aufgefordert, ihre Kernel zu aktualisieren, um mit LTS- und Android-spezifischen Fehlerkorrekturen auf dem neuesten Stand zu bleiben.

ACK-KMI-Kernel-Branch

GKI-Kernel haben eine stabile Kernelmodulschnittstelle. Das KMI wird eindeutig durch die Kernelversion und die Android-Plattformversion identifiziert. Die Zweige werden daher als ANDROID_RELEASE-KERNEL_VERSION benannt. Der 6.1 GKI-Kernel für Android 14 heißt beispielsweise android14-6.1. Für Android 15 wurde der GKI-Kernel android15-6.6 eingeführt.

Funktions- und Launch-Kernel

Vor Android 15 konnte für die Einführung eines Geräts einer der drei letzten Kernel verwendet werden. Ab Android 15 können die beiden letzten Kernel-Versionen für die Markteinführung von Geräten verwendet werden. Die Launch-Kernel für Android 15 sind android15-6.6 und android14-6.1.

Da Kernel-Upgrades beim Aktualisieren der Plattformversion nicht erforderlich sind, können Kernel, die die neuesten Funktionen für eine Plattformversion nicht enthalten, trotzdem zum Starten von Geräten verwendet werden. Daher können Kernel, die für Android 14 entwickelt wurden, z. B. android14-6.1, auch nach dem Upgrade der Plattformversion auf Android 15 auf Geräten verwendet werden.

Gemeinsame Kernel-Hierarchie

Branch von android-mainline

Die oberste Ebene der gemeinsamen Kernelhierarchie ist in Abbildung 1 dargestellt.

Abbildung 1: Gemeinsame Kernel aus dem android-mainline-Kernel erstellen

Beachten Sie, dass 2022 ein neuer Android-Common-Kernel android14-6.1 aus android-mainline abgeleitet wurde. 2023, als die nächste LTS-Version angekündigt wurde, wurde android15-6.6 von android-mainline abgeleitet.

Wie in Abbildung 1 dargestellt, kann jede Kernel-Version die Grundlage für zwei GKI-Kernel sein. Die beiden v5.15-Kernel sind beispielsweise android13-5.15 und android14-5.15. Beide sind Feature-Kernel für die jeweiligen Plattformversionen. Das war auch bei 5.10 der Fall. android12-5.10 wurde erstellt, als der LTS deklariert wurde, und android13-5.10 wurde im Frühjahr 2021 beim Kernel-Feature-Complete-Meilenstein von android12-5.10 abgeleitet, um die Entwicklung von Funktionen für Android 13 zu ermöglichen. Ab Android 15 (2024) gibt es nur einen neuen GKI-Kernel pro Kernelversion (es gibt keinen android15-6.1-Kernel).

ACK-KMI-Branch-Lebenszyklus

Der Lebenszyklus eines ACK-KMI-Zweigs ist in Abbildung 2 dargestellt.

Abbildung 2: 6.6 Lebenszyklus des ACK-KMI-Branch

Zur Verdeutlichung des Entwicklungsprozesses und des Branch-Lebenszyklus konzentriert sich Abbildung 2 auf die ACK-KMI-Branches für 6.6.

Jeder ACK-KMI-Zweig durchläuft drei Phasen, die in Abbildung 2 durch unterschiedliche Farben in jedem Zweig dargestellt werden. Wie gezeigt, wird LTS unabhängig von der Phase regelmäßig zusammengeführt.

Entwicklungsphase

Nach der Erstellung wechselt ein ACK KMI-Branch in die Entwicklungsphase (in Abbildung 2 als dev gekennzeichnet) und ist für die nächste Android-Plattformversion für Funktionsbeiträge geöffnet. In Abbildung 2 wurde android15-6.6 erstellt, als 6.6 als neuer Upstream-LTS-Kernel deklariert wurde.

Stabilisierungsphase

Wenn der ACK-KMI-Zweig als vollständig deklariert wird, beginnt die Stabilisierungsphase (in Abbildung 2 als stabil bezeichnet). Partnerfunktionen und Fehlerkorrekturen werden weiterhin akzeptiert, aber KMI-Tracking ist aktiviert, um Änderungen zu erkennen, die sich auf die Schnittstelle auswirken. In dieser Phase sind KMI-gefährdende Änderungen zulässig und die KMI-Definition wird in einem vordefinierten Rhythmus (normalerweise alle zwei Wochen) aktualisiert. Weitere Informationen zum KMI-Monitoring finden Sie in der GKI-Übersicht.

KMI-Einfrierphase

Bevor ein neuer Plattformrelease in AOSP übertragen wird, wird der ACK-KMI-Branch eingefroren und bleibt für die gesamte Lebensdauer des Branch eingefroren. Das bedeutet, dass keine KMI-Breaking Changes akzeptiert werden, es sei denn, es wird ein schwerwiegendes Sicherheitsproblem festgestellt, das nicht behoben werden kann, ohne das stabile KMI zu beeinträchtigen. Um KMI-Fehler zu vermeiden, werden einige aus LTS übernommene Patches möglicherweise geändert oder entfernt, wenn der Fix für Android-Geräte nicht erforderlich ist.

Wenn ein ACK KMI-Branch eingefroren ist, können Fehlerkorrekturen und Partnerfunktionen akzeptiert werden, solange der vorhandene KMI-Common-Kernel nicht beschädigt wird. Die KMI kann mit neuen exportierten Symbolen erweitert werden, solange die Schnittstellen der aktuellen KMI nicht betroffen sind. Wenn dem KMI neue Schnittstellen hinzugefügt werden, sind sie sofort stabil und können durch zukünftige Änderungen nicht beschädigt werden.

Eine Änderung, durch die ein Feld zu einer Struktur hinzugefügt wird, die von einer KMI-Schnittstelle des gemeinsamen Kernels verwendet wird, ist beispielsweise nicht zulässig, da sie die Schnittstellendefinition ändert:

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Das Hinzufügen einer neuen Funktion ist jedoch in Ordnung:

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

Während der gesamten Lebensdauer des GKI-Kernels wird die Abwärtskompatibilität mit dem Nutzerbereich aufrechterhalten, sodass der Kernel sicher für die Android-Plattformversion verwendet werden kann, mit der das Gerät eingeführt wurde. Kontinuierliche Tests mit früheren Releases sorgen für Kompatibilität. In Abbildung 2 kann der android15-6.6-Kernel also für Geräte mit Android 15 und höher verwendet werden. Da die Android-Plattformversion auch mit früheren Versionen kompatibel ist, kann der android14-6.1-Kernel für Android 15-Geräte entweder für den Start oder für das Upgrade verwendet werden.

KMI-Generationsnummer

Wenn während der Stabilisierungsphase ein LTS-Merge oder danach ein Sicherheitsproblem oder ein anderes Ereignis auftritt, das die Annahme eines Patches erfordert, der das KMI ändert, wird die in build.config.common aufgezeichnete KMI-Generierungsnummer erhöht. Die aktuelle KMI-Generation kann mit dem Befehl uname ermittelt werden:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

Die Zahl nach der Plattformversion ist die KMI-Generation (in diesem Fall 6).

Wenn sich die KMI-Generation ändert, ist der Kernel nicht mit Anbietermodulen kompatibel, die der vorherigen KMI-Generation entsprechen. Die Module müssen also neu erstellt und synchron mit dem Kernel aktualisiert werden. Nach dem KMI-Freeze sind Änderungen bei der KMI-Generierung sehr selten.

Kompatibilität zwischen Kernels

Die Kompatibilitätsanforderungen zwischen Kernels in derselben LTS-Familie ändern sich mit den neuen GKI-Kernels.

GKI-Kernel

GKI-Kernel sind abwärtskompatibel mit allen Android-Plattformversionen, die die Kernelversion unterstützt haben. Außerdem sind die Android-Plattform-Releases abwärtskompatibel mit GKI-Kerneln aus früheren Releases. Sie können den für Android 14 (2023) entwickelten android14-6.1-Kernel also bedenkenlos auf Geräten mit Android 15 (2024) verwenden. Die Kompatibilität wird durch kontinuierliche VTS- und CTS-Tests der GKI-Kernel mit allen unterstützten Releases überprüft.

Das KMI ist stabil, sodass der Kernel aktualisiert werden kann, ohne dass Kernelmodule im Anbieter-Image neu erstellt werden müssen.

Die KMI-Kompatibilität wird nicht zwischen verschiedenen GKI-Kerneln aufrechterhalten. Ein android14-6.1-Kernel kann beispielsweise nicht durch einen android15-6.6-Kernel ersetzt werden, ohne alle Module neu zu erstellen.

GKI-Kernel werden nur für ihre ursprünglichen und nachfolgenden Releases unterstützt. Sie werden für ältere Releases nicht unterstützt. Ein android15-6.6-Kernel wird daher für Geräte mit Android 14 (2023) nicht unterstützt.

Kompatibilitätsmatrix

In dieser Tabelle sind die Kernelversionen aufgeführt, die mit den einzelnen Android-Plattform-Releases unterstützt und getestet werden.

Supportzeiträume und Sicherheitspatches

ACKs erhalten LTS-Merges von Upstream und Fehlerkorrekturen für Android-spezifischen Code. Diese Korrekturen umfassen alle Kernel-Sicherheitspatches, die in den monatlichen Android-Sicherheitsbulletins aufgeführt sind und für ACK relevant sind.

ACKs werden möglicherweise länger unterstützt als der entsprechende Upstream-Kernel auf kernel.org. In diesem Fall bietet Google erweiterten Support bis zum Ende des Produktzyklus (End of Life, EOL), das in diesem Abschnitt angegeben ist. Wenn der Support für Kernel eingestellt wird, werden sie nicht mehr von Google unterstützt und Geräte, auf denen sie ausgeführt werden, gelten als anfällig.

Ab Kernel 6.6 beträgt die Supportlaufzeit für die stabilen Kernel vier Jahre.

In dieser Tabelle sind die Gültigkeitsdauern für die unterstützten ACKs aufgeführt:

Häufige Kernel-Tests

Die gemeinsamen Kernel werden mit mehreren CI-Systemen getestet. Außerdem führen Anbieter Downstream-Tests durch.

Funktionstest des Linux-Kernels

Beim Linux Kernel Functional Test (LKFT) werden verschiedene Testsuiten wie kselftest, LTP, VTS und CTS auf einer Reihe von physischen arm32- und arm64-Geräten ausgeführt. Die aktuellen Testergebnisse finden Sie auf der Seite android-lkft.

KernelCI-Tests

KernelCI-Build-and-Boot-Tests werden immer dann gestartet, wenn ein neuer Patch in einem gemeinsamen Kernel-Branch committet wird. Mehrere Hundert Build-Konfigurationen werden auf verschiedenen Boards getestet und gebootet. Aktuelle Ergebnisse für Android-Kernel finden Sie auf der KernelCL-Website.

Vorab- und Nachabtests für Android

Mit Tests vor dem Einreichen soll verhindert werden, dass Fehler in die gemeinsamen Android-Kernel eingeführt werden. Die Zusammenfassung der Testergebnisse finden Sie auf dem Tab „Checks“ der Codeänderung in Android Common Kernel Gerrit.

Android-Tests nach dem Einreichen werden für neue veröffentlichte Builds in allgemeinen Android-Kernel-Branches durchgeführt, wenn neue Patches in einem allgemeinen Android-Kernel-Branch in ci.android.com committet werden. Wenn Sie aosp_kernel als partiellen Branch-Namen in ci.android.com eingeben, wird eine Liste der Kernel-Branches mit verfügbaren Ergebnissen angezeigt. Ergebnisse für android-mainline finden Sie beispielsweise im Android CI-Dashboard. Klicken Sie auf einen bestimmten Build, um den Teststatus auf dem Tab Test Results aufzurufen.

Die durch test-mapping mit der Testgruppe kernel-presubmit im Android-Quellbaum definierten Tests werden als Presubmit für Android-Kernel-Branches ausgeführt. Die folgende Konfiguration in test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING aktiviert beispielsweise vts_kernel_proc_file_api_test als Presubmit-Test beim Einchecken von Android Common Kernel-Code.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

0-Tage-Test

Beim 0-Day-Test werden alle Android Common Kernel-Branches patchweise getestet, wenn neue Patches übernommen werden. Es werden verschiedene Boot-, Funktions- und Leistungstests ausgeführt. Treten Sie der öffentlichen Gruppe cros-kernel-buildreports bei.

Test matrix

Beiträge zu allgemeinen Android-Kerneln leisten

Im Allgemeinen sollte die Entwicklung von Funktionen im Mainline-Linux-Kernel und nicht in Android-Common-Kernels erfolgen. Die Upstream-Entwicklung wird dringend empfohlen. Nachdem die Entwicklung dort akzeptiert wurde, kann sie bei Bedarf auf den jeweiligen ACK-Branch zurückportiert werden. Das Android Kernel Team unterstützt gerne Upstreaming-Bemühungen zum Wohle des Android-Ökosystems.

Senden Sie Patches an Gerrit und halten Sie sich an diese Beitragsrichtlinien.