Gemeinsame Android-Kernel

AOSP-Common-Kernel (auch als Android-Common-Kernel oder ACKs bezeichnet) sind Downstream-Kernel von kernel.org 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 bereit sind, aber noch in der Upstream-Entwicklung sind
• Funktionen von Anbietern/OEMs, die für andere Ökosystempartner nützlich sind

android-mainline ist der primäre Entwicklungszweig für Android-Funktionen. Linux Mainline wird in android-mainline zusammengeführt, wenn Linus Torvalds ein Release oder einen Releasekandidaten veröffentlicht. Vor 2019 wurden Android-Common-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 zu verzweigen. Mit diesem neuen Modell wird der erhebliche Aufwand für das Forward-Porting und Testen von Android-Patches vermieden, da das gleiche Ergebnis inkrementell erreicht wird. android-mainline wird kontinuierlich umfassend getestet. Dieses Modell enthält ab dem Tag der Veröffentlichung einen hochwertigen Kernel.

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

Andere Common-Kernel-Zweige werden regelmäßig mit dem zugehörigen LTS-Kernel zusammengeführt. Diese Zusammenführungen erfolgen in der Regel unmittelbar nach der Veröffentlichung des LTS-Kernel. Als beispielsweise Linux 6.1.75 veröffentlicht wurde, wurde es in den 6.1-Common-Kernel (android14-6.1) zusammengeführt. Partner sollten ihre Kernel aktualisieren, um über LTS- und Android-spezifische Fehlerkorrekturen auf dem Laufenden zu bleiben.

ACK-KMI-Kernel-Zweig

GKI-Kernel haben eine stabile Kernel-Modul-Schnittstelle. Die KMI wird eindeutig durch die Kernel-Version und das Android-Plattform-Release identifiziert. Die Zweige werden daher ANDROID_RELEASE-KERNEL_VERSION genannt. 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.

Common-Kernel-Hierarchie

Verzweigung von android-mainline

Die oberste Ebene der Common-Kernel-Hierarchie ist in Abbildung 1 dargestellt.

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

2022 wurde ein neuer Android-Common-Kernel android14-6.1 von android-mainline verzweigt. Als 2023 der nächste LTS-Kernel deklariert wurde, wurde android15-6.6 von android-mainline verzweigt.

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

Lebenszyklus des ACK-KMI-Zweigs

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

Abbildung 2 : Lebenszyklus des 6.6-ACK-KMI-Zweigs

Zur Verdeutlichung des Entwicklungsprozesses und des Lebenszyklus des Zweigs konzentriert sich Abbildung 2 auf die ACK-KMI-Zweige 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 dargestellt, wird LTS unabhängig von der Phase regelmäßig zusammengeführt.

Entwicklungsphase

Nach der Erstellung tritt ein ACK-KMI-Zweig in die Entwicklungsphase ein (in Abbildung 2 als dev bezeichnet) und ist für Feature-Beiträge für das nächste Android-Plattform-Release 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 „Funktionen vollständig“ deklariert wird, tritt er in die Stabilisierungsphase ein (in Abbildung 2 als stable bezeichnet). Partnerfunktionen und Fehlerkorrekturen werden weiterhin akzeptiert, aber die KMI-Verfolgung ist aktiviert, um alle Änderungen zu erkennen, die sich auf die Schnittstelle auswirken. In dieser Phase werden KMI-Änderungen akzeptiert und die KMI-Definition in einem vordefinierten Rhythmus aktualisiert (normalerweise alle zwei Wochen). Weitere Informationen zur KMI-Überwachung finden Sie in der GKI-Übersicht.

Phase „KMI eingefroren“

Bevor ein neues Plattform-Release an AOSP übertragen wird, wird der ACK-KMI-Zweig eingefroren und bleibt für die gesamte Lebensdauer des Zweigs eingefroren. Das bedeutet, dass keine KMI-Änderungen akzeptiert werden, es sei denn, es wird ein schwerwiegendes Sicherheitsproblem festgestellt, das nicht behoben werden kann, ohne die stabile KMI zu beeinträchtigen. Um KMI-Änderungen zu vermeiden, werden einige Patches, die aus LTS zusammengeführt wurden, 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 Common-Kernel der KMI nicht beschädigt wird. Die KMI kann mit neuen exportierten Symbolen erweitert werden, solange die Schnittstellen, aus denen die aktuelle KMI besteht, nicht betroffen sind. Wenn der KMI neue Schnittstellen hinzugefügt werden, werden sie sofort stabil und können durch zukünftige Änderungen nicht beschädigt werden.

Eine Änderung, die einer Struktur, die von einem Common-Kernel einer KMI-Schnittstelle verwendet wird, ein Feld hinzufügt, 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 Userspace beibehalten, sodass der Kernel sicher für das Android-Plattform-Release verwendet werden kann, mit dem das Gerät auf den Markt gebracht wurde. Durch kontinuierliche Tests mit früheren Releases wird die Kompatibilität beibehalten. In Abbildung 2 kann der Kernel android15-6.6 also für Geräte mit Android 15 und höher verwendet werden. Da das Android-Plattform-Release auch mit früheren Versionen kompatibel ist, kann der Kernel android14-6.1 für Geräte mit Android 15 entweder für die Markteinführung oder für ein Upgrade verwendet werden.

KMI-Generationsnummer

Wenn während der Stabilisierungsphase eine LTS-Zusammenführung erfolgt oder nach dieser Phase ein Sicherheitsproblem oder ein anderes Ereignis auftritt, das die Akzeptanz eines Patches erfordert, der die KMI ändert, wird die in build.config.common aufgezeichnete KMI-Generationsnummer erhöht. Die aktuelle KMI-Generation kann mit dem Befehl uname ermittelt werden:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

Die Zahl nach dem Plattform-Release ist die KMI-Generation (6 in diesem Fall).

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

Kompatibilität zwischen Kerneln

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

GKI-Kernel

GKI-Kernel behalten die Abwärtskompatibilität mit allen Android-Plattform-Releases bei, die die Kernel-Version 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 Kernel android14-6.1 also sicher 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.

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

Die KMI-Kompatibilität wird nicht zwischen verschiedenen GKI-Kerneln beibehalten. 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 die ursprünglichen und nachfolgenden Releases unterstützt. Für ältere Releases werden sie nicht unterstützt. Ein android15-6.6-Kernel wird also nicht für Geräte mit Android 14 (2023) unterstützt.

Kompatibilitätsmatrix

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

Support-Lebenszyklen und Sicherheitspatches

ACKs erhalten LTS-Zusammenführungen 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 stabile Upstream-Kernel auf kernel.org. In diesem Fall bietet Google erweiterten Support bis zum End-of-Life-Datum (EOL), das in diesem Abschnitt angegeben ist. Wenn Kernel das EOL-Datum erreichen, 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 Support-Lebensdauer für die stabilen Kernel 4 Jahre.

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

Common-Kernel-Tests

Die Common-Kernel werden mit mehreren CI-Systemen getestet, zusätzlich zu den Downstream-Tests durch Anbieter.

KernelCI-Tests

KernelCI-Build- und -Boot-Tests werden initiiert, wenn ein neuer Patch an einen Common-Kernel-Zweig übertragen wird. Mehrere Hundert Build-Konfigurationen werden getestet und auf verschiedenen Boards gebootet. Aktuelle Ergebnisse für Android-Kernel finden Sie auf der KernelCL-Website.

Android-Tests vor und nach dem Senden

Mit Tests vor dem Senden soll verhindert werden, dass Fehler in die Android-Common-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 Senden werden für neue veröffentlichte Builds in Android-Common-Kernel-Zweigen durchgeführt, wenn neue Patches an einen Android-Common-Kernel-Zweig in ci.android.com übertragen werden. Wenn Sie aosp_kernel als Teil des Zweignamens in ci.android.com eingeben, wird eine Liste der Kernel-Zweige mit verfügbaren Ergebnissen angezeigt. Ergebnisse für android-mainline finden Sie beispielsweise im Android-Dashboard für die kontinuierliche Build-Integration (Android CI). Klicken Sie auf einen bestimmten Build, um den Teststatus auf dem Tab Test Results zu sehen.

Die durch die Testzuordnung mit der Testgruppe kernel-presubmit im Android-Plattform-Quellbaum definierten Tests werden als Tests vor dem Senden für Android-Kernel-Zweige 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 Test vor dem Senden beim Einchecken von Android-Common- Kernel-Code.

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

Zero-Day-Tests

Zero-Day-Tests führen Patch-für-Patch-Tests für alle Android-Common-Kernel-Zweige durch, wenn neue Patches übertragen werden. Es werden verschiedene Boot-, Funktions- und Leistungstests ausgeführt. Treten Sie der öffentlichen Gruppe cros-kernel-buildreports bei.

Test matrix

Beiträge zu Android-Common-Kerneln

Im Allgemeinen sollte die Feature-Entwicklung in Mainline Linux und nicht in Android-Common-Kerneln erfolgen. Die Upstream-Entwicklung wird dringend empfohlen. Nachdem die Entwicklung dort akzeptiert wurde, kann sie bei Bedarf in den spezifischen ACK-Zweig zurückportiert werden. Das Android-Kernel-Team unterstützt gerne Upstream-Bemühungen zum Nutzen des Android-Ökosystems.

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