Gängige Android-Kernels

Gängige AOSP-Kernel (auch bekannt als allgemeine Android-Kernel oder ACKs) sind nachgelagerten kernel.org-Kernels und Patches für die Android-Community interessant, die noch nicht zur Mainline- oder LTS-Kernel (Long Term Supported) Diese Patches können Folgendes umfassen:

  • Backports und neuartige Upstream-Funktionen für Android Funktionen
  • Funktionen, die für Android-Geräte bereit sind, aber noch in der Entwicklungsphase sind
  • Anbieter-/OEM-Funktionen, die für andere Partnerunternehmen nützlich sind

android-mainline ist der primäre Entwicklungszweig für Android-Funktionen. Linux Mainline wird immer dann mit android-mainline zusammengeführt, wenn Linus Torvalds Release- oder Release-Kandidaten. Vor 2019 waren gängige Android-Kernels die durch Klonen des kürzlich deklarierten LTS-Kernels und Hinzufügen der Android-spezifische Patches. Dieser Prozess wurde 2019 geändert, um die neue Android-Version gemeinsamer Kernel von android-mainline. Dieses neue Modell vermeidet die erheblichen Portion und Test von Android-Patches mit demselben Ergebnis inkrementell. android-mainline wird erheblichen kontinuierlichen Tests unterzogen. Das ab dem Tag der Veröffentlichung einen hochwertigen Kernel gewährleistet.

Wenn ein neuer LTS als Upstream deklariert wird, ist der entsprechende gemeinsame Kernel verzweigt von android-mainline. So können Partner ein Projekt schon vor der Deklaration der Version mit Langzeitsupport durch Zusammenführen aus android-mainline. Nach dem neuer gemeinsamer Kernel-Branch erstellt wird, können Partner die Zusammenführung nahtlos ändern. Quelle in den neuen Zweig.

Andere allgemeine Kernel-Zweige erhalten regelmäßige Zusammenführungen von ihren verknüpften LTS-Kernel Diese Zusammenführungen werden in der Regel sofort nach der Veröffentlichung der Version von „Langzeitsupport“ durchgeführt. Für Beispielsweise wurde Linux 6.1.75 bei der Veröffentlichung mit der allgemeinen Version 6.1 zusammengeführt. Kernel (android14-6.1) Partnern wird dringend empfohlen, ihre Kernel aktualisieren, um hinsichtlich der LTS- und Android-spezifischen Fehlerkorrekturen auf dem neuesten Stand zu bleiben.

ACK KMI-Kernel-Branch

GKI-Kernels haben eine stabile Kernel Module Interface. Die KMI ist einzigartig die durch die Kernel-Version und den Release der Android-Plattform identifiziert werden, Zweige sind benannt ANDROID_RELEASEKERNEL_VERSION. Beispiel: Die GKI 6.1 Der Kernel für Android 14 heißt android14-6.1. Für Android 15 (AOSP experimentell), der GKI-Kernel android15-6.6 war eingeführt.

Feature- und Launch-Kernel

Vor Android 15 (AOSP experimentell) hatte einer der drei neuesten Kernels für den Gerätestart verwendet werden. Beginnend mit Unter Android 15 (AOSP experimentell) können die beiden neuesten Kernel-Versionen für den Gerätestart verwendet werden. Die Start-Kernels für Android 15 (AOSP experimentell) ist android15-6.6 und android14-6.1.

Weil beim Aktualisieren der Plattform keine Kernel-Upgrades erforderlich sind können Kernel, denen die neuesten Funktionen für ein Plattformrelease fehlen, verwendet werden, um Geräte zu starten. Daher werden Kernel, die für Android 14, z. B. android14-6.1, kann auf folgenden Geräten verwendet werden: auch nach dem Upgrade der Plattformversion auf Android 15 (AOSP experimentell)

Android-Plattformrelease Kernel starten Feature-Kernel
Android 15 (AOSP experimentell) (2024) android15-6.6
android14-6.1
android15-6.6
Android 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.101
android14-6.1
android14-5.15
Android 13 (2022) android13-5.15
android13-5.10
android12-5.101
android12-5.41
android11-5.41
android13-5.15
android13-5.10
Android 12 (2021) android12-5.10
android12-5.4
android11-5.41
android-4.19-stable
android12-5.10
android12-5.4
Android 11 (2020) android11-5.4
android-4.19-stable
android11-5.4
android-4.19-stable

1 Möglicherweise gelten zusätzliche Einschränkungen, wenn der zugehörige BSP für den Plattformrelease aktualisiert. Allgemein gesagt, Android-Release-Nummer des Kernels muss größer oder gleich der FCM-Zielversion. Weitere Informationen finden Sie unter Vendor Interface Object – Match Kernel Branches .

Gemeinsame Kernel-Hierarchie

Zweig von Android-Mainline

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

Allgemeine Kernel aus dem Android-Mainline-Kernel erstellen

Abbildung 1: Allgemeine Kernel aus dem Android-Mainline-Kernel erstellen

Beachten Sie, dass ein neuer gemeinsamer Android-Kernel android14-6.1 von einem android-mainline. Als 2023 der nächste Langzeitsupport verkündet wurde, android15-6.6 wurde von android-mainline verzweigt.

Wie in Abbildung 1 gezeigt, kann jede Kernel-Version die Grundlage für zwei GKI-Kernels sein. Die beiden Kernel von Version 5.15 sind beispielsweise android13-5.15 und android14-5.15. Beide sind Funktions-Kernels für ihre jeweiligen Plattform-Releases. Dieses gilt auch für 5,10. „android12-5.10“ wurde erstellt, als der Langzeitsupport ausgeführt wurde deklariert und android13-5.10 im Kernel von android12-5.10 verzweigt im Frühjahr 2021 fertiggestellt, um die Entwicklung von Funktionen für Android 13 Mit Android starten 15 (AOSP experimentell) (2024), gibt es nur Ein neuer GKI-Kernel pro Kernel-Version (es gibt keinen android15-6.1-Kernel).

ACK-KMI-Zweiglebenszyklus

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

6.6 ACK KMI-Branch-Lebenszyklus

Abbildung 2: 6.6 ACK KMI-Branch-Lebenszyklus

Um den Entwicklungsprozess und den Zweiglebenszyklus zu verdeutlichen, konzentriert sich Abbildung 2 auf die ACK KMI verzweigt für 6.6.

Jeder ACK KMI-Zweig durchläuft drei Phasen, die in Abbildung 2 durch verschiedenen Farben in jedem Zweig. Wie Sie sehen, wird die Version „Langzeitsupport“ regelmäßig zusammengeführt, der Phase.

Entwicklungsphase

Nach seiner Erstellung geht ein ACK KMI-Zweig in die Entwicklungsphase ein (gekennzeichnet als dev in Abbildung 2) und bereit für Funktionsbeiträge für die nächste Android-Version Plattformrelease. In Abbildung 2 wurde android15-6.6 erstellt, als 6.6 im als neuer Upstream-LTS-Kernel deklariert.

Stabilisierungsphase

Wenn der ACK KMI-Zweig für die Funktion als abgeschlossen erklärt wird, tritt er in den Stabilisierungsphase (in Abbildung 2 als stable gekennzeichnet) Partnerfunktionen und Fehlerkorrekturen werden weiterhin akzeptiert, aber das KMI-Tracking ist aktiviert, um Änderungen zu erkennen die sich auf die Benutzeroberfläche auswirken. In dieser Phase werden abwärtskompatible Änderungen an KMI-Daten akzeptiert. und die KMI-Definition in einem vordefinierten Rhythmus aktualisiert (normalerweise alle zwei Wochen). Weitere Informationen finden Sie in der GKI-Übersicht für zum KMI-Monitoring.

Eingefrorene KMI-Phase

Bevor ein neuer Plattformrelease an AOSP übertragen wird, wird der ACK KMI-Zweig eingefroren und bleibt für die Lebensdauer des Zweigs eingefroren. Das bedeutet, dass keine Änderungen mit funktionsgefährdenden KMI-Daten werden akzeptiert, sofern kein schwerwiegendes Sicherheitsproblem festgestellt wird. der nicht gemindert werden kann, ohne den stabilen KMI zu beeinträchtigen. Um KMI zu vermeiden Patches, die aus der Langzeitsupport-Version zusammengefügt wurden, werden möglicherweise geändert oder verworfen, ist für Android-Geräte nicht erforderlich.

Wenn ein ACK KMI-Zweig eingefroren ist, können Fehlerkorrekturen und Partnerfunktionen akzeptiert werden solange der vorhandene gemeinsame KMI-Kernel nicht fehlerhaft ist. Die KMI kann verlängert werden mit neuen exportierten Symbolen, solange die Schnittstellen, aus denen die aktuelle KMI besteht, sind davon nicht betroffen. Wenn der KMI neue Schnittstellen hinzugefügt werden, und durch zukünftige Änderungen nicht beeinträchtigt werden kann.

Beispiel: Eine Änderung, durch die ein Feld einer Struktur hinzugefügt wird, die von einer KMI-Schnittstelle verwendet wird Common Kernel nicht zulässig, da er 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);

Es ist jedoch kein Problem, 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);

Für die gesamte Lebensdauer des GKI-Kernels ist die Abwärtskompatibilität mit dem Userspace Pflegen, damit der Kernel sicher für die Android-Plattform verwendet werden kann mit der das Gerät gestartet wurde. Kontinuierliche Tests mit früheren Releases sorgt dafür, dass die Kompatibilität aufrechterhalten wird. In Abbildung 2 ist der android15-6.6 Der Kernel kann für Geräte mit Android 15 (experimentell über AOSP) und höher verwendet werden Geräte. Da der Release der Android-Plattform auch mit früheren Versionen kompatibel; der Kernel android14-6.1 kann verwendet werden für Geräte mit Android 15 (AOSP-Experimentell), entweder zur Markteinführung oder für ein Upgrade.

KMI-Generierungsnummer

Wenn während der Stabilisierungsphase eine Zusammenführung mit Langzeitsupport oder ein Sicherheitsproblem auftritt Ereignis ein, für das ein KMI-Änderungspatch erforderlich ist, Die in build.config.common aufgezeichnete KMI-Generierungsnummer wird erhöht. Die Die aktuelle KMI-Generierung kann mit dem Befehl uname abgerufen werden:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

Die Nummer nach dem Plattformrelease ist die KMI-Generation (in diesem Fall 6).

Wenn sich die KMI-Generierung ändert, ist der Kernel nicht mit Anbietermodulen kompatibel die der vorherigen KMI-Generation entsprechen, sodass die Module synchron mit dem Kernel aktualisiert werden. Nach dem Einfrieren von KMI ändert sich die KMI-Generierung sehr selten sind.

Kompatibilität zwischen Kerneln

Die Kompatibilitätsanforderungen zwischen Kerneln derselben LTS-Familie sind und beginnen mit den neuen GKI-Kerneln.

GKI-Kernels

GKI-Kernels sind mit allen Android-Plattformen abwärtskompatibel Releases, die die Kernel-Version unterstützten. Die Android-Plattform Releases sind abwärtskompatibel mit GKI-Kernels aus früheren Releases. Also können Sie den android14-6.1-Kernel sicher verwenden, der für Android 14 (2023) auf Geräten mit Android 15 (AOSP experimentell) (2024). Kompatibilität wird überprüft durch Kontinuierliche VTS- und CTS-Tests der GKI-Kernel mit allen unterstützten Releases.

Die KMI ist stabil, sodass der Kernel ohne Neuerstellung aktualisiert werden kann. der Kernel-Module im Anbieter-Image.

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

GKI-Kernels werden nur für ihre ersten und nachfolgenden Releases unterstützt. Für ältere Releases werden sie nicht unterstützt. Das heißt: Der Kernel android15-6.6 wird für ausgeführte Devics nicht unterstützt Android 14 (2023):

Kompatibilitätsmatrix

Diese Tabelle zeigt die Kernel-Versionen, die mit jedem Android-Gerät unterstützt und getestet wurden. Plattformrelease.

Android-Plattformrelease Unterstützte Kernel für Upgrades Unterstützte Kernel für den Start
Android 15 (AOSP experimentell) (2024) android15-6.6
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android15-6.6
android14-6.1
Android 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
Android 13 (2022) android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
Android 12 (2021) android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.19-stable
android11-5.4
android12-5.4
android12-5.10
Android 11 (2020) android11-5.4
android-4.19-stable
android11-5.4
android-4.19-stable

Supportlebensdauer und Sicherheitspatches

Bestätigungen erhalten LTS-Zusammenführungen von Upstreams und Fehlerkorrekturen für Android-spezifischen Code. Zu diesen Fehlerbehebungen gehören alle Kernel-Sicherheitspatches, die in der monatlichen Android-Dokumentation Sicherheitsbulletins, die für die Bestätigung relevant sind.

ACKs werden möglicherweise länger unterstützt als der entsprechende stabile Upstream-Kernel unter kernel.org In diesem Fall hat Google bietet verlängerten Support bis zum Ende des Produktzyklus (End of Life, EOL), der hier angegeben ist . Wenn die Kernel am Ende des Produktzyklus (EOL) beendet sind, sind sie nicht mehr die von Google unterstützt werden, und Geräte, auf denen sie ausgeführt werden, gelten als anfällig.

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

In der folgenden Tabelle sind die Lebensdauer der unterstützten ACKs aufgeführt:

ACK-Zweig Einführungsdatum
Support
Lebensdauer
(Jahre)
Ende des Produktzyklus
Android-4.19-stable 2018-10-22 6 2025-01-01
android11–5.4 2019-11-24 6 2026-01-01
android12–5.4 2019-11-24 6 2026-01-01
android12–5.10 2020-12-13 6 2027-07-01
android13–5.10 2020-12-13 6 2027-07-01
android13–5.15 2021-10-31 6 2028-07-01
android14–5.15 2021-10-31 6 2028-07-01
android14–6.1 2022-12-11 6 2029-07-01
android15–6.6 2023-10-29 4 2028-07-01

Gängige Kerneltests

Die gängigen Kernel werden neben nachgelagerten Systemen mit mehreren CI-Systemen getestet. von Anbietern testen.

Linux-Kernel-Funktionstest

Linux-Kernel-Funktionstest (LKFT) Tests initiieren verschiedene Testsuites wie kselftest, LTP, VTS und CTS auf einer physische arm32- und arm64-Geräte. Aktuelle Testergebnisse finden Sie hier.

KernelCI-Tests

Build- und Boot-Tests von KernelCI die jedes Mal initiiert wird, wenn ein neuer Patch zu einem gemeinsamen Kernel-Zweig per Commit übertragen wird. Mehrere auf verschiedenen Boards getestet und gebootet werden. Letzte finden Sie die Ergebnisse für Android-Kernels hier.

Vorab- und Postsubmit-Tests für Android

Vorabsendetests werden verwendet, um zu verhindern, dass Fehler in den Gängige Android-Kernels. Die Zusammenfassung der Testergebnisse findest du unter „Vorabprüfung“ Tab der Codeänderung in der allgemeinen Kernelgerrit von Android.

Android – Postsubmit-Test wird ausgeführt bei neu veröffentlichten Builds in gemeinsamen Android-Kernel-Zweigen, wenn neue Patches an einen gemeinsamen Android-Kernel-Zweig auf ci.android.com übergeben werden. Wenn Sie aosp_kernel als partiellen Zweignamen auf ci.android.com enthält, sehen Sie eine Liste der Kernel-Zweige mit Ergebnisse verfügbar. Ergebnisse für android-mainline können beispielsweise gefunden werden. finden Sie hier. Wenn Sie auf einen bestimmten Build klicken, wird der Teststatus auf dem Tab Test Results angezeigt.

Die durch test-mapping mit Testgruppe kernel-presubmit im Quellbaum der Android-Plattform 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 Presbumit-Test beim Einchecken des gemeinsamen Android-Kernel-Codes.

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

Zero-Day-Test

Bei 0-tägigen Tests werden Patch-für-Patch-Tests durchgeführt. in allen gängigen Kernel-Zweigen von Android, wenn ein Commit neuer Patches ausgeführt wird. Verschiedene Boot-, Funktions- und Leistungstests. Der öffentlichen Gruppe beitreten cros-kernel-buildreports

Test matrix

Allgemeiner Android-Kernel Android-Plattform-Releases Test-Suites
Main 15 14 13 12 11 10 Logo: LKFT Kernel-CI Vorab einreichen Beitrag senden 0 Tage
android-mainline ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung
android15-6.6 ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung
android14-6.1
android14-5.15
❌ Vorstellung ❌ Vorstellung ❌ Vorstellung ❌ Vorstellung
android13-5.15
android13-5.10
❌ Vorstellung ❌ Vorstellung ❌ Vorstellung
android12-5.10
android12-5.4
❌ Vorstellung ❌ Vorstellung
android11-5.4 ❌ Vorstellung
android-4.19-stable

Zu gängigen Kernels von Android beitragen

Im Allgemeinen sollte die Funktionsentwicklung unter Mainline-Linux und nicht auf Gängige Android-Kernels. Vorgelagerte Entwicklung wird dringend empfohlen. Entwicklung dort akzeptiert wird, kann sie einfach zum spezifischen ACK zurückportiert werden. Zweig nach Bedarf aus. Das Android Kernel-Team ist wir unterstützen gern Upstreaming-Initiativen zugunsten des Android-Ökosystems.

Patches an Gerrit senden und sich an diese Richtlinien für Beiträge.