Auf dieser Seite wird das Versionierungsschema für generische Kernel-Images (GKIs) beschrieben. Ein generisches Kernel-Image (GKI) hat eine eindeutige Kennung, die als Kernel-Release bezeichnet wird. Die Kernelversion besteht aus der KMI-Version (Kernel Module Interface) und dem Unterlevel. Der Kernel-Release ist spezifisch für das freigegebene Image, während die KMI-Version die Schnittstelle darstellt, aus der ein Release erstellt wird. Eine KMI-Version kann mehrere Kernel-Releases unterstützen. Eine Kernelversion ist nur mit einer KMI-Version verknüpft. Für den unwahrscheinlichen Fall, dass die Kernelmodul-Benutzeroberfläche geändert werden muss, wird die KMI-Generation wiederholt, um die Änderung der KMI-Version widerzuspiegeln.
Zusammenfassung der Nutzungsbedingungen
In der folgenden Tabelle sind wichtige Begriffe zusammengefasst, die auf dieser Seite und für GKI-Updates verwendet werden.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| Kernel-Release | w.x.y-zzz-k-suffix | 5.4.42-android12-0-foo | Eindeutige Kennung für eine GKI-Version. Das ist der Wert, der von uname zurückgegeben wird. |
| KMI-Version | w.x-zzz-k | 5.4-android12-0 | Beschreibt die Kernelmodulschnittstelle (KMI) zwischen GKI und dynamisch ladbaren Kernelmodulen (DLKM). |
| Unterebene | y | 42 | Beschreibt die Releasereihenfolge der Kernel-Releases innerhalb einer KMI-Version. |
In der folgenden Tabelle sind weitere ähnliche Begriffe aufgeführt.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| w.x.y | w.x.y | 5.4.42 |
Weitere Informationen finden Sie unter Linux-Kernel-Makefiles (Suchen Sie nach „KERNELRELEASE“). w.x.y wird in diesem Dokument direkt verwendet. Diese wird auch als dreiteilige Versionsnummer bezeichnet. Der in VINTF verwendete Begriff Kernelversion kann mit anderen Begriffen verwechselt werden, insbesondere mit w. In libkver wird diese Variable als kernel_version_tuple bezeichnet. Dieses Tupel darf durch Updates, einschließlich OTA- oder Mainline-Updates, nicht verringert werden. |
| Kernel-Branch | zzz-w.x | android12-5.4 | Dieser Begriff wird in Gängige Kernel-Branch-Typen verwendet. |
| Version | w | 5 | Dieser Begriff wird in diesem Dokument nicht verwendet. In libkver wird diese Variable als version bezeichnet. |
| Patchebene | x | 4 | Dieser Begriff wird in diesem Dokument nicht verwendet. In libkver wird diese Variable als patch_level bezeichnet. |
| Android-Release | zzz | Android12 |
Dies ist die Android-Versionsnummer (dessert), mit der der Kernel verknüpft ist.
Beim Vergleichen des Felds Die Android-Release-Nummer darf durch Updates nicht niedriger werden, einschließlich OTA- oder Mainline-Updates. |
| KMI-Generierung | k | 0 |
Dies ist eine zusätzliche Zahl, die für den Fall unwahrscheinlicher Ereignisse hinzugefügt wird. Wenn eine Sicherheitsfehlerbehebung Änderungen am KMI innerhalb derselben Android-Version erfordert, wird eine KMI-Generation erhöht. Die KMI-Generierungsnummer beginnt mit 0. |
Versionsdesign
Kernel-Release
Definition
Für Geräte, die mit GKI ausgeliefert werden, ist die Kernelversion so definiert:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Weitere Informationen finden Sie unter Kernelversion von einem Gerät ermitteln.
Das folgende Beispiel zeigt eine Kernelversion.
5.4.42-android12-0-00544-ged21d463f856
Beschreibung
Der Kernel-Release ist die eindeutige ID einer GKI-Version. Wenn zwei GKI-Binärdateien dieselbe Kernelversion haben, müssen sie byteweise identisch sein.
Ein Kernelrelease besteht aus einer KMI-Version, einer Unterebene und einem Suffix. In diesem Dokument wird das Suffix nach der KMI-Generierung ignoriert.
KMI-Version
Definition
Die KMI-Version ist so definiert:
KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w .x -zzz -k
Beachten Sie, dass die untergeordnete Ebene y nicht Teil der KMI-Version ist. Im Beispiel unter Kernel-Release lautet die KMI-Version:
5.4-android12-0
Beschreibung
Die KMI-Version beschreibt die Kernel-Modul-Schnittstelle (Kernel Module Interface, KMI) zwischen der GKI und dynamisch ladbaren Kernelmodulen (Dynamically Loadable Kernel Modules, DLKM).
Wenn zwei Kernel-Releases dieselbe KMI-Version haben, implementieren sie dieselbe Kernelmodulschnittstelle. Die DLKMs, die mit einer Version kompatibel sind, sind auch mit der anderen kompatibel.
Die KMI-Version darf nicht durch OTA-Updates herabgesetzt werden.
Unterebene
Die Unterebene y beschreibt die Releasereihenfolge der Kernel-Releases innerhalb einer KMI-Version.
Für zwei Kernel-Releases mit derselben KMI-Version, aber einer Unterebene Y1 bzw. Y2:
- Wenn Y1 kleiner oder gleich Y2 ist, kann ein Gerät mit Y1 ein Update auf Y2 erhalten.
- Wenn Y1 größer als Y2 ist, kann ein Gerät mit Y1 nicht auf Y2 aktualisiert werden.
Das heißt, wenn sich die KMI-Version nicht ändert, darf die Unterebene durch ein Over-the-air-Update nicht herabgesetzt werden.
Kernel-Release von einem Gerät ermitteln
Die vollständige Kernelversion finden Sie, indem Sie uname -r oder uname(2) mit dem folgenden Code-Snippet ausführen:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Beispielausgabe:
5.4.42-android12-0-00544-ged21d463f856
Im Rahmen dieses Dokuments wird beim Extrahieren von Kernelinformationen alles nach der KMI-Generierung ignoriert. Genauer gesagt wird die Ausgabe von uname -r mit dem folgenden Regex geparst, wobei davon ausgegangen wird, dass „zzz“ immer mit „android“ beginnt:
^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$
Zu den ignorierten Informationen gehören unter anderem die Build-Nummer von ci.android.com, die Anzahl der Patches auf dem Basiskernel und die SHA-Hashes des Git-Commits.
libkver
Die Bibliothek libkver bietet eine C++-Schnittstelle zum Parsen des Kernel-Release oder eines KMI-Versionsstrings. Eine Liste der von libkver freigegebenen APIs finden Sie unter packages/modules/Gki/libkver/include/kver.
VINTF-Prüfungen
Bei Android 11 oder niedriger wird der Android-Release-Teil der KMI-Version manuell im Gerätemanifest vom Gerätehersteller angegeben. Weitere Informationen finden Sie unter VINTF-Kernel-Übereinstimmungsregeln.
Ab Android S kann der Android-Release-Teil der KMI-Version aus dem Kernel extrahiert und beim Build-Vorgang in das Gerätemanifest eingefügt werden.
Da sich die Anforderungen an die Kernelkonfiguration in der Regel nicht ändern, muss k nicht in die Kompatibilitätsmatrix codiert werden. Für den unwahrscheinlichen Fall, dass die Kernelkonfiguration geändert werden muss, beachten Sie Folgendes:
- Die entsprechende Anforderung wird aus der Kompatibilitätsmatrix entfernt.
- Es werden zusätzliche VTS-Tests hinzugefügt, um die neuen Anforderungen an die KMI-Generierung zu prüfen.
Version des Boot-Images in den OTA-Metadaten
Auch wenn das Boot-Image über ein OTA-Update aktualisiert wird, muss es im OTA-Nutzlastformat payload.bin verpackt sein. Die OTA-Nutzlast codiert ein version-Feld für jede Partition. Wenn update_engine eine OTA-Nutzlast verarbeitet, wird dieses Feld verglichen, um sicherzustellen, dass die Partition nicht heruntergestuft wird.
Zur Vermeidung von Verwechslungen wird das Feld version für die Bootpartition in den OTA-Metadaten boot image version genannt.
Da das RAM-Disk immer von Grund auf neu erstellt wird, reicht der RAM-Disk-Zeitstempel aus, um das gesamte Boot-Image zu beschreiben. Es ist nicht erforderlich, den Kernel-Release in der Boot-Image-Version zu codieren, es sei denn, Sie möchten in Zukunft ein altes Boot-Image mit einem neuen Kernel-Binärcode zusammenführen.
Vor einem OTA-Update prüft der OTA-Client die Version des Boot-Images auf dieselbe Weise wie jede andere Partition.