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. Diese Patches können Folgendes umfassen:
- Backports und besondere Upstream-Funktionen, die für Android-Funktionen benötigt werden
- 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 in android-mainline zusammengeführt, wenn Linus Torvalds einen Release oder Releasekandidaten veröffentlicht. Vor 2019 wurden gängige Android-Kernels durch Klonen des kürzlich deklarierten LTS-Kernels und Hinzufügen der Android-spezifischen Patches erstellt. 2019 wurde dieser Prozess geändert, um den neuen allgemeinen Android-Kernel von android-mainline zu verzweigen. Dieses neue Modell vermeidet den erheblichen Aufwand beim Weiterleiten und Testen von Android-Patches, indem dasselbe Ergebnis schrittweise erzielt wird. android-mainline durchläuft umfassende kontinuierliche Tests. Dieses Modell sorgt ab dem Tag der Veröffentlichung für einen qualitativ hochwertigen Kernel.
Wenn ein neuer LTS als Upstream deklariert wird, ist der entsprechende gemeinsame Kernel von android-mainline verzweigt. So können Partner vor der Deklaration der LTS-Version ein Projekt durch Zusammenführen von android-mainline starten. Nachdem der neue gemeinsame Kernel-Branch erstellt wurde, können Partner die Zusammenführungsquelle nahtlos zum neuen Branch ändern.
Andere gängige Kernel-Zweige erhalten regelmäßige Zusammenführungen vom zugehörigen LTS-Kernel.
Diese Zusammenführungen werden in der Regel sofort nach der Veröffentlichung der Version von „Langzeitsupport“ durchgeführt. 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 durch die Kernel-Version und den Android-Plattformrelease eindeutig identifiziert, sodass die Zweige ANDROID_RELEASE-KERNEL_VERSION heißen. Der 6.1-GKI-Kernel für Android 14 heißt beispielsweise android14-6.1. Für Android 15 (experimentell mit AOSP) wurde der GKI-Kernel android15-6.6 eingeführt.
Feature- und Launch-Kernel
Vor Android 15 (AOSP experimentell) konnte jeder der drei neuesten Kernels für den Gerätestart verwendet werden. Ab Android 15 (AOSP experimentell) können die beiden neuesten Kernel-Versionen für den Gerätestart verwendet werden. Die Start-Kernel für Android 15 (experimentell über AOSP) sind android15-6.6 und android14-6.1.
Da für die Aktualisierung des Plattformrelease keine Kernel-Upgrades erforderlich sind, können Kernel, denen die neuesten Funktionen für einen Plattformrelease fehlen, weiterhin zum Starten von Geräten verwendet werden. Daher können für Android 14 entwickelte Kernel wie android14-6.1 auch nach einem Upgrade des Plattformrelease auf Android 15 (experimentell (AOSP experimentell)) auf Geräten verwendet werden.
| Android-Plattformrelease | Kernel starten | Feature-Kernel |
|---|---|---|
| Android 15 (AOSP experimentell) (2024) |
android15-6.6
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.101
|
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 Wenn die zugehörige BSP für den Plattformrelease aktualisiert wurde, können zusätzliche Einschränkungen gelten. Allgemein ausgedrückt: Die Android-Releasenummer des Kernels muss größer oder gleich der FCM-Zielversion sein. Weitere Informationen finden Sie unter Vendor Interface Object – Match Kernel Branches (Kernel-Zweige abgleichen). |
||
Gemeinsame Kernel-Hierarchie
Zweig von Android-Mainline
Die oberste Ebene der gemeinsamen Kernel-Hierarchie ist in Abbildung 1 dargestellt.
Abbildung 1: Allgemeine Kernel aus dem Android-Mainline-Kernel erstellen
Wie Sie sehen, wurde 2022 der neue gemeinsame Android-Kernel android14-6.1 von android-mainline verzweigt. Bei der Deklaration des nächsten LTS im Jahr 2023 wurde android15-6.6 von android-mainline verzweigt.
Wie in Abbildung 1 gezeigt, kann jede Kernel-Version die Grundlage für zwei GKI-Kernels sein.
Die beiden v5.15-Kernels android13-5.15 und android14-5.15 sind beispielsweise Feature-Kernels für ihre jeweiligen Plattform-Releases. Das trifft auch auf Version 5.10 zu: android12-5.10 wurde erstellt, als der LTS deklariert wurde, und android13-5.10 verzweigte sich von android12-5.10 im Frühjahr 2021 zum Abschluss des Kernel-Feature-Releases im Frühjahr 2021, um die Entwicklung von Funktionen für Android 13 zu ermöglichen. Ab Android 15 (AOSP experimentell) (2024) gibt es nur einen neuen 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.
Abbildung 2: 6.6 ACK KMI-Branch-Lebenszyklus
Zur Verdeutlichung des Entwicklungsprozesses und des Zweiglebenszyklus stehen in Abbildung 2 die ACK KMI-Zweige für 6.6 im Mittelpunkt.
Jeder ACK KMI-Zweig durchläuft drei Phasen, die in Abbildung 2 durch verschiedene Farben in jedem Zweig dargestellt sind. Wie Sie sehen, wird die Version „Langzeitsupport“ regelmäßig unabhängig von der Phase zusammengeführt.
Entwicklungsphase
Nach seiner Erstellung geht ein ACK KMI-Zweig in die Entwicklungsphase ein (in Abbildung 2 als dev bezeichnet) und ist für Funktionsbeiträge für das nächste Android-Plattformrelease verfügbar. 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 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 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 KMI-Monitoring finden Sie in der GKI-Übersicht.
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 fixiert. Dies bedeutet, dass keine abwärtskompatiblen Änderungen für KMI akzeptiert werden, es sei denn, ein schwerwiegendes Sicherheitsproblem wird erkannt, das sich nur auf den stabilen KMI auswirken kann. 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 allgemeine KMI-Kernel nicht fehlerhaft ist. 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 mehr unterbrochen werden.
Eine Änderung, durch die ein Feld zu einer Struktur hinzugefügt wird, die von einem allgemeinen Kernel einer KMI-Schnittstelle verwendet wird, ist nicht zulässig, da dadurch die Schnittstellendefinition 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 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 wird die Abwärtskompatibilität mit dem Userspace aufrechterhalten, sodass der Kernel sicher für den Android-Plattformrelease verwendet werden kann, mit dem das Gerät gestartet wurde. Kontinuierliche Tests mit früheren Releases stellen sicher, dass die Kompatibilität aufrechterhalten wird. In Abbildung 2 kann der android15-6.6-Kernel für Android 15-Geräte (experimentell über AOSP) und höher verwendet werden. Da der Android-Plattformrelease auch mit früheren Versionen kompatibel ist, kann der android14-6.1-Kernel für Android 15-Geräte (AOSP-Experimental) entweder für den Start oder für ein Upgrade verwendet werden.
KMI-Generierungsnummer
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 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-Generation ändert, ist der Kernel nicht mit Anbietermodulen kompatibel, die der vorherigen KMI-Generation entsprechen. Daher müssen die Module synchron mit dem Kernel neu erstellt und aktualisiert werden. Nach dem Einfrieren von KMI sind Änderungen der KMI-Generierung sehr selten.
Kompatibilität zwischen Kerneln
Die Kompatibilitätsanforderungen zwischen Kerneln derselben LTS-Familie ändern sich anfangs mit den neuen GKI-Kerneln.
GKI-Kernels
GKI-Kernels sind abwärtskompatibel mit allen Android-Plattformreleases, die die Kernel-Version unterstützten. Darüber hinaus sind die Android-Plattformreleases abwärtskompatibel mit GKI-Kernels aus vorherigen Releases. Sie können also den für Android 14 (2023) entwickelten Kernel android14-6.1 bedenkenlos auf Geräten mit Android 15 (AOSP experimentell) (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 Kernelmodule im Anbieter-Image neu erstellt werden müssen.
Die KMI-Kompatibilität wird nicht zwischen verschiedenen GKI-Kerneln aufrechterhalten. So kann beispielsweise ein android14-6.1-Kernel nicht durch einen android15-6.6-Kernel 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. Daher wird ein android15-6.6-Kernel für Geräte mit Android 14 (2023) nicht unterstützt.
Kompatibilitätsmatrix
Diese Tabelle enthält die Kernel-Versionen, die mit jedem Android-Plattformrelease unterstützt und getestet werden.
| Android-Plattformrelease | Unterstützte Kernel für Upgrades | Unterstützte Kernel für den Start |
|---|---|---|
| Android 15 (AOSP experimentell) (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
Gängige Android-Kernel werden so lange unterstützt, bis entweder der zugehörige LTS-Kernel oder der Android Platform-Release nicht mehr unterstützt wird. Ein Kernel wird zwar unterstützt, aber weiterhin LTS-Zusammenführungen von Upstreams sowie Fehlerkorrekturen für Android-spezifischen Code erhalten. Diese Fehlerbehebungen umfassen alle Kernel-Sicherheitspatches, die in den monatlichen Android-Sicherheitsbulletins aufgeführt sind, die für die allgemeinen Android-Kernels relevant sind.
Partner können sich darauf verlassen, dass sie durch die Verwendung von GKI-Kerneln alle verfügbaren Kernel-Sicherheitspatches erhalten.
Gängige Kerneltests
Die gängigen Kernel werden zusätzlich zu den Downstream-Tests durch die Anbieter mit verschiedenen CI-Systemen getestet.
Linux-Kernel-Funktionstest
Durch LKFT-Tests (Linux Kernel Function Test) werden verschiedene Testsuites, einschließlich kselftest, LTP, VTS und CTS, auf einer Reihe von physischen arm32- und arm64-Geräten initiiert. Aktuelle Testergebnisse finden Sie hier.
KernelCI-Tests
Build- und Boot-Tests von KernelCI werden jedes Mal initiiert, wenn ein neuer Patch an einen gemeinsamen Kernel-Zweig übergeben wird. Mehrere hundert Build-Konfigurationen werden auf verschiedenen Boards getestet und gestartet. Aktuelle Ergebnisse für Android-Kernel finden Sie hier.
Vorab- und Postsubmit-Tests für Android
Vorabsendetests werden verwendet, um zu verhindern, dass Fehler in die gängigen Kernels von Android eingeschleust werden. Die Zusammenfassung der Testergebnisse findest du auf dem Tab „Vorabprüfung“ der Codeänderung in der allgemeinen Kernelgerrit von Android.
Die Android-Postsubmit-Tests werden für neue veröffentlichte Builds in gemeinsamen Kernel-Zweigen von Android durchgeführt, wenn neue Patches an einen gemeinsamen Android-Kernel-Branch auf ci.android.com übergeben werden. Wenn Sie aosp_kernel als partiellen Zweignamen auf ci.android.com eingeben, wird eine Liste der Kernel-Zweige mit verfügbaren Ergebnissen angezeigt. Ergebnisse für android-mainline finden Sie beispielsweise 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-Tage-Tests werden Patch-für-Patch-Tests für alle gängigen Kernel-Zweige von Android durchgeführt, wenn für neue Patches ein Commit durchgeführt wird. Es werden verschiedene Start-, Funktions- und Leistungstests durchgeführt. Der öffentlichen Gruppe cros-kernel-buildreports beitreten
Test matrix
| Allgemeiner Android-Kernel | Android-Plattform-Releases | Test-Suites | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hauptnummer | 15 | 14 | 13 | 12 | 11 | 10 | Logo: LKFT | Kernel-CI | Vorab einreichen | Beitrag senden | 0 Tage | |
android-mainline
|
✅ | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android5-6.6
|
✅ | ✅ | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android14-6.1
|
✅ | ✅ | ✅ | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android13-5.15
|
✅ | ✅ | ✅ | ✅ | ❌ Vorstellung | ❌ Vorstellung | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android12-5.10
|
✅ | ✅ | ✅ | ✅ | ✅ | ❌ Vorstellung | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android11-5.4
|
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ Vorstellung | ✅ | ✅ | ✅ | ✅ | ✅ |
android-4.19-stable
|
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Zu gängigen Kernels von Android beitragen
Generell sollte die Funktionsentwicklung unter Mainline Linux und nicht auf gängigen Android-Kerneln erfolgen. Die vorgelagerte Entwicklung wird dringend empfohlen. Sobald die Entwicklung dort akzeptiert wurde, kann sie bei Bedarf einfach zum spezifischen ACK-Zweig zurückportiert werden. Das Android Kernel Team unterstützt Sie gerne beim Upstreaming zugunsten des Android-Ökosystems.
Reiche Patches an Gerrit ein und halte dich an diese Beitragsrichtlinien.