Allgemeine AOSP-Kernel (auch bekannt als Android Common Kernel oder ACKs) sind kernel.org-Kerneln nachgeschaltet und enthalten für die Android-Community relevante Patches, die nicht zu Mainline- oder LTS-Kerneln zusammengeführt wurden. 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. Dieses neue Modell vermeidet den erheblichen Aufwand beim Weiterleiten und Testen von Android-Patches, indem dasselbe Ergebnis schrittweise erzielt 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 ein Projekt vor der Erklärung der LTS-Version beginnen, 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. Beispielsweise wurde Linux 6.1.75 nach der Veröffentlichung im gemeinsamen Kernel 6.1 (android14-6.1) zusammengeführt. Partnern wird dringend empfohlen, ihre Kernel zu aktualisieren, um hinsichtlich LTS- und Android-spezifischer Fehlerkorrekturen auf dem neuesten Stand zu bleiben.
ACK KMI-Kernel-Branch
GKI-Kernels haben eine stabile Kernel Module Interface. 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.
Feature- und Launch-Kernel
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.
| Android-Plattformrelease | Launch-Kernel | Feature-Kernel |
|---|---|---|
| Android 15 (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.10
|
android14-6.1
android14-5.15
|
| Android 13 (2022) |
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
|
android13-5.15
android13-5.10
|
| Android 12 (2021) |
android12-5.10
android12-5.4
android11-5.4
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 Es können zusätzliche Einschränkungen gelten, wenn die zugehörige BSP für die Plattformversion aktualisiert wurde. Allgemein gilt: Die Android-Release-Nummer des Kernels muss mindestens der Ziel-FCM-Version entsprechen. Weitere Informationen finden Sie unter Vendor Interface Object – Match Kernel Branches (Kernel-Zweige abgleichen). |
||
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 die nächste LTS-Version 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-Branches
Der Lebenszyklus eines ACK KMI-Zweigs ist unten in Abbildung 2 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 betritt ein ACK-KMI-Zweig 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 abgeschlossen erklärt wurde, geht er in die Stabilisierungsphase ein (in Abbildung 2 als stable bezeichnet). 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 nicht abwärtskompatible Änderungen an KMI akzeptiert und die KMI-Definition in einem vordefinierten Rhythmus aktualisiert (in der Regel alle zwei Wochen). Weitere Informationen zum Monitoring von KMI finden Sie in der GKI-Übersicht.
KMI-Eingefrorene Phase
Bevor ein neuer Plattformrelease an AOSP übertragen wird, wird der ACK KMI-Zweig eingefroren und bleibt für die Lebensdauer des Zweigs fixiert. 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-Ausfälle zu vermeiden, werden einige aus LTS zusammengeführte Patches möglicherweise geändert oder gelöscht, wenn die Fehlerbehebung 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-Zusammenführung oder ein Sicherheitsproblem oder ein anderes Ereignis auftritt, für das ein KMI-Änderungspatch akzeptiert werden muss, wird die in build.config.common aufgezeichnete KMI-Generierungsnummer erhöht. Die aktuelle KMI-Generation lässt sich mit dem Befehl uname ermitteln:
$ 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-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. Darüber hinaus sind die Android-Plattformreleases abwärtskompatibel mit GKI-Kernels aus vorherigen Releases. Auf Geräten mit Android 15 (2024) können Sie also den für Android 14 (2023) entwickelten Kernel android14-6.1 sicher 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 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.
| Android-Plattformrelease | Unterstützte Kernel für Upgrades | Unterstützte Kernel zur Einführung |
|---|---|---|
| Android 15 (2024) |
android15-6.6
|
android15-6.6
|
| Android 14 (2023) |
android14-6.1
|
android14-6.1
|
| Android 13 (2022) |
android13-5.15
|
android13-5.15
|
| Android 12 (2021) |
android12-5.10
|
android-4.19-stable
|
| Android 11 (2020) |
android11-5.4
|
android11-5.4
|
Supportlebensdauer und Sicherheitspatches
Bestätigungen erhalten LTS-Zusammenführungen von Upstreams 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 Supportlebensdauer der stabilen Kernel vier Jahre.
In dieser Tabelle sind die Lebensdauern der unterstützten ACKs aufgeführt:
| ACK-Zweig | Einführungsdatum |
Support Lebensdauer (Jahre) |
EOL |
|---|---|---|---|
| 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 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 Postsubmit-Tests für Android
Mit Presubmit-Tests wird verhindert, dass Fehler in die gemeinsamen Android-Kernel eindringen. Die Zusammenfassung der Testergebnisse findest du auf dem Tab „Vorabprüfung“ der Codeänderung in der allgemeinen Kernelgerrit von Android.
Die Android-Tests nach der Einreichung werden auf neu veröffentlichten Builds in Android Common Kernel-Branches durchgeführt, wenn neue Patches in einen Android Common Kernel-Branch in 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, wird der Teststatus auf dem Tab Test Results angezeigt.
Die von test-mapping mit der Testgruppe kernel-presubmit im Android-Plattform-Quellbaum definierten Tests werden als Presubmit 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 getestet, sobald diese gesendet wurden. Es werden verschiedene Boot-, Funktions- und Leistungstests ausgeführt. Treten Sie der öffentlichen Gruppe cros-kernel-buildreports bei.
Test matrix
| Allgemeiner Android-Kernel | Android-Plattform-Releases | Test-Suites | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hauptnavigationsmenü | 15 | 14 | 13 | 12 | 11 | 10 | LKFT | KernelCI | Vor dem Einreichen | Nach dem Senden | Zero-Day | |
android-mainline
|
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android15-6.6
|
✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android14-6.1
|
✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android13-5.15
|
✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android12-5.10
|
✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android11-5.4
|
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android-4.19-stable
|
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Beiträge zu Android Common Kernels leisten
Im Allgemeinen sollte die Funktionsentwicklung auf dem Mainline-Linux-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.