Gängige Android-Kernels

AOSP-gemeinsame Kernel (auch als Android-gemeinsame Kernel oder ACKs bezeichnet) sind nachgeschaltete kernel.org-Kernel und enthalten Patches, die für die Android-Community von Interesse sind, aber nicht in Mainline- oder LTS-Kernel (Long Term Supported) eingeflossen sind. Dazu gehören:

• Backports und ausgewählte Upstream-Funktionen, die für Android-Funktionen erforderlich sind
• Funktionen, die für Android-Geräte bereit sind, aber noch in der Entwicklung sind
• Funktionen von Anbietern/OEMs, die für andere Partner im Ökosystem nützlich sind

android-mainline ist der primäre Entwicklungszweig für Android-Funktionen. Linux mainline wird in android-mainline zusammengeführt, sobald Linus Torvalds eine Veröffentlichung oder einen Release-Kandidaten veröffentlicht. Vor 2019 wurden Android-gemeinsame Kernel erstellt, indem der kürzlich deklarierte LTS-Kernel geklont und die Android-spezifischen Patches hinzugefügt wurden. Dieser Prozess wurde 2019 geändert, um den neuen Android Common Kernel von android-mainline abzuzweigen. Mit diesem neuen Modell wird der erhebliche Aufwand vermieden, den Port weiterzuleiten und Android-Patches zu testen, da das gleiche Ergebnis inkrementell erreicht wird. android-mainline wird kontinuierlich getestet. Dieses Modell sorgt für einen hochwertigen Kernel ab dem Tag der Veröffentlichung.

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

Andere gängige Kernel-Branches erhalten regelmäßig Merges aus dem zugehörigen LTS-Kernel. Diese Zusammenführungen erfolgen normalerweise direkt nach der Veröffentlichung des LTS-Release. Beispiel: Als Linux 6.1.75 veröffentlicht wurde, wurde es in den gemeinsamen Kernel 6.1 (android14-6.1) eingegliedert. Wir empfehlen Partnern dringend, ihre Kernel zu aktualisieren, um immer auf dem neuesten Stand zu sein und LTS- und Android-spezifische Fehlerkorrekturen zu erhalten.

ACK KMI-Kernel-Branch

GKI-Kernel haben eine stabile Kernel-Modul-Schnittstelle. Die KMI wird eindeutig durch die Kernelversion und die Android-Plattformversion identifiziert. Daher werden die Branches ANDROID_RELEASE–KERNEL_VERSION genannt. Der 6.1-GKI-Kernel für Android 14 heißt beispielsweise android14-6.1. Mit Android 15 wurde der GKI-Kernel android15-6.6 eingeführt.

Kernel für Funktionen und Einführung

Vor Android 15 konnte für die Markteinführung eines Geräts jeder der drei neuesten Kernel verwendet werden. Ab Android 15 können die beiden neuesten Kernelversionen für die Geräteeinführung verwendet werden. Die Startkernel für Android 15 sind android15-6.6 und android14-6.1.

Da beim Aktualisieren des Plattformreleases keine Kernel-Upgrades erforderlich sind, können Kernel, denen die neuesten Funktionen für eine Plattformversion fehlen, weiterhin zum Starten von Geräten verwendet werden. Daher können Kernel, die für Android 14 entwickelt wurden, wie android14-6.1, auch nach dem Upgrade der Plattformversion auf Android 15 auf Geräten verwendet werden.

Gemeinsame Kernelhierarchie

Von android-mainline ableiten

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 von android-mainline abgezweigt wurde. 2023, als der nächste LTS angekündigt wurde, wurde android15-6.6 von android-mainline abgezweigt.

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

Lebenszyklus von ACK-KMI-Zweigen

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

Abbildung 2: 6.6 ACK KMI-Zweig – Lebenszyklus

Zur Verdeutlichung des Entwicklungs- und Branch-Lebenszyklus liegt der Schwerpunkt in Abbildung 2 auf den ACK-KMI-Branches für 6.6.

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

Entwicklungsphase

Nach der Erstellung begibt sich ein ACK-KMI-Zweig in die Entwicklungsphase (in Abbildung 2 als dev gekennzeichnet) und ist für Funktionsbeiträge für die nächste Android-Plattformversion offen. 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 funktionsfähig erklärt wurde, tritt er in die Stabilisierungsphase ein (in Abbildung 2 als stabil gekennzeichnet). Partnerfunktionen und Fehlerkorrekturen sind weiterhin zulässig, aber das KMI-Tracking ist aktiviert, um Änderungen zu erkennen, die sich auf die Benutzeroberfläche auswirken. In dieser Phase werden funktionsgefährdende Änderungen an den KMIs akzeptiert 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-Eingefrorene Phase

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

Wenn ein ACK-KMI-Zweig eingefroren ist, können Fehlerkorrekturen und Partnerfunktionen akzeptiert werden, solange der vorhandene KMI-Common-Kernel nicht beschädigt ist. Das KMI kann mit neuen exportierten Symbolen erweitert werden, solange die Schnittstellen, aus denen das aktuelle KMI besteht, 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.

Beispielsweise ist eine Änderung, durch die einer Struktur, die von einem KMI-Interface-Common-Kernel verwendet wird, ein Feld hinzugefügt wird, nicht zulässig, da dadurch die Interfacedefinition geändert wird:

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);

Es ist jedoch in Ordnung, eine neue Funktion hinzuzufügen:

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 Lebensdauer des GKI-Kernels wird die Abwärtskompatibilität mit dem Userspace aufrechterhalten, damit der Kernel für die Android-Plattformversion verwendet werden kann, mit der das Gerät auf den Markt gebracht wurde. Durch kontinuierliche Tests mit früheren Releases wird die Kompatibilität aufrechterhalten. 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 zum Starten oder zum Aktualisieren verwendet werden.

KMI-Generationsnummer

Wenn während der Stabilisierungsphase eine LTS-Merger-Aktion, ein Sicherheitsproblem oder ein anderes Ereignis auftritt, bei dem ein Patch zur Änderung der KMI akzeptiert werden muss, wird die in build.config.common aufgezeichnete KMI-Generationsnummer erhöht. Die aktuelle KMI-Generation lässt sich mit dem Befehl uname ermitteln:

$ 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. Daher müssen die Module neu erstellt und synchron mit dem Kernel aktualisiert werden. Nach dem KMI-Freeze sind Änderungen an der KMI-Generierung voraussichtlich sehr selten.

Kompatibilität zwischen Kerneln

Die Kompatibilitätsanforderungen zwischen Kerneln derselben LTS-Familie ändern sich ab den neuen GKI-Kerneln.

GKI-Kernel

GKI-Kernel sind abwärtskompatibel mit allen Android-Plattformveröffentlichungen, die die Kernelversion unterstützt haben. Außerdem sind die Android-Plattformversionen abwärtskompatibel mit GKI-Kerneln aus früheren Releases. So können Sie den android14-6.1-Kernel, der für Android 14 (2023) entwickelt wurde, auch 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 die Kernelmodule im Anbieter-Image neu erstellt werden müssen.

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

GKI-Kernel werden nur für ihre Erstveröffentlichung und nachfolgende 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-Plattformversionen 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-Sicherheits-Patches, 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 stabile Upstream-Kernel unter kernel.org. In diesem Fall bietet Google erweiterten Support bis zum in diesem Abschnitt angegebenen EOL-Datum (Ende des Produktzyklus). Wenn für einen Kernel das Ende der Lebensdauer erreicht ist, wird er von Google nicht mehr unterstützt und Geräte, auf denen er ausgeführt wird, gelten als anfällig.

Ab Kernel 6.6 beträgt die Supportdauer für stabile Kernel 4 Jahre.

In dieser Tabelle sind die Lebensdauern der unterstützten ACKs aufgeführt:

Gängige Kernel-Tests

Die gängigen Kernel werden zusätzlich zu den Downstream-Tests der Anbieter mit mehreren CI-Systemen getestet.

Funktionstest des Linux-Kernels

Beim Linux Kernel Functional Test (LKFT) werden verschiedene Test-Suites wie kselftest, LTP, VTS und CTS auf einer Reihe von physischen arm32- und arm64-Geräten gestartet. Aktuelle Testergebnisse finden Sie hier.

KernelCI-Tests

Build- und Boot-Tests von KernelCI werden gestartet, wenn ein neuer Patch an einen gemeinsamen Kernel-Branch übergeben wird. Mehrere hundert Buildkonfigurationen werden auf verschiedenen Boards getestet und gestartet. Aktuelle Ergebnisse für Android-Kernel finden Sie hier.

Vorab- und Nachabtests für Android

Mit Presubmit-Tests wird verhindert, dass Fehler in die gemeinsamen Android-Kernel eindringen. Die Zusammenfassung der Testergebnisse finden Sie auf dem Tab „Checks“ der Codeänderung im Gerrit-Repository des Android Common Kernel.

Die Android-Tests nach der Einreichung werden auf neuen veröffentlichten Builds in Android Common Kernel-Branches durchgeführt, wenn neue Patches in einem Android Common Kernel-Branch auf ci.android.com committet werden. Wenn Sie aosp_kernel als Teilnamen des Branches in ci.android.com eingeben, wird eine Liste der Kernel-Branches mit verfügbaren Ergebnissen angezeigt. Ergebnisse für android-mainline finden Sie hier. Wenn Sie auf einen bestimmten Build klicken, sehen Sie den Teststatus auf dem Tab Test Results.

Die mit test-mapping definierten Tests mit der Testgruppe kernel-presubmit im Android-Plattform-Quellbaum werden als Presubmit-Tests für Android-Kernel-Branches ausgeführt. Mit der folgenden Konfiguration in test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING wird vts_kernel_proc_file_api_test als Presubmit-Test beim Check-in des gemeinsamen Kernelcodes von Android aktiviert.

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

Zero-Day-Tests

Bei Null-Tage-Tests werden alle Android-Kernel-Branches nacheinander auf neue Patches geprüft, sobald diese gesendet wurden. Es werden verschiedene Boot-, Funktions- und Leistungstests ausgeführt. Treten Sie der öffentlichen Gruppe cros-kernel-buildreports bei.

Test matrix

Beiträge zu gemeinsamen Android-Kerneln leisten

Im Allgemeinen sollte die Funktionsentwicklung auf dem Linux-Mainline-Kernel und nicht auf den gemeinsamen Android-Kerneln erfolgen. Die Vorabentwicklung wird dringend empfohlen. Nachdem die Entwicklung dort akzeptiert wurde, kann sie bei Bedarf problemlos in den entsprechenden ACK-Branch zurückportiert werden. Das Android-Kernel-Team unterstützt gerne Upstreaming-Bemühungen zum Nutzen der Android-Plattform.

Reichen Sie Patches bei Gerrit ein und halten Sie sich an diese Richtlinien für Beiträge.