Auf dieser Seite wird das Versionsverwaltungsschema für Generic Kernel Images (GKIs) beschrieben. Ein Generic Kernel Image (GKI) hat eine eindeutige Kennung, die als Kernel-Release bezeichnet wird. Die Kernel-Release besteht aus der Version der Kernelmodulschnittstelle (Kernel Module Interface, KMI) und der Unterebene. Die Kernel-Release-Version ist spezifisch für das veröffentlichte 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 Kernel-Version ist nur an eine KMI-Version gebunden. Im unwahrscheinlichen Fall, dass die Kernelmodulschnittstelle geändert werden muss, wird die KMI-Generierung wiederholt, um die Änderung der KMI-Version zu berücksichtigen.
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. Dies ist der Wert, der von uname zurückgegeben wird. |
| KMI-Version | w.x-zzz-k | 5.4-android12-0 | Beschreibt die Kernelmodulschnittstelle (Kernel Module Interface, KMI) zwischen GKI und dynamisch ladbaren Kernelmodulen (Dynamically Loadable Kernel Modules, DLKM). |
| Unterebene | y | 42 | Beschreibt die Reihenfolge der Kernel-Releases innerhalb derselben KMI-Version. |
In der folgenden Tabelle finden Sie weitere zugehörige Begriffe als Referenz.
| 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. Dies wird auch als dreiteilige Versionsnummer bezeichnet. Der in VINTF verwendete Begriff Kernel-Version kann zu Verwechslungen mit anderen Begriffen führen, insbesondere mit w. Diese Variable wird in libkver als kernel_version_tuple bezeichnet. Dieses Tupel darf durch keine Updates verringert werden, auch nicht durch OTA- oder Mainline-Updates. |
| Kernel-Branch | zzz-w.x | android12-5.4 | Dieser Begriff wird in Häufige Kernel-Branch-Typen verwendet. |
| Version | w | 5 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird in libkver als version bezeichnet. |
| Patchebene | x | 4 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird in libkver als patch_level bezeichnet. |
| Android-Release | zzz | android12 |
Das ist die Android-Versionsnummer (Dessert), mit der der Kernel verknüpft ist.
Beim Vergleich des Felds Die Android-Versionsnummer darf durch keine Updates verringert werden, auch nicht durch OTA- oder Mainline-Updates. |
| KMI-Generierung | k | 0 |
Dies ist eine zusätzliche Nummer, die für unwahrscheinliche Ereignisse hinzugefügt wurde. Wenn für einen Sicherheitsfehlerkorrektur Änderungen am KMI innerhalb derselben Android-Version erforderlich sind, wird die KMI-Generation erhöht. Die KMI-Generierungsnummer beginnt mit 0. |
Versionsverwaltungsdesign
Kernel-Release
Definition
Bei Geräten, die mit GKI ausgeliefert werden, wird die Kernel-Version so definiert:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Weitere Informationen finden Sie unter Kernel-Release auf einem Gerät ermitteln.
Das Folgende ist ein Beispiel für eine Kernel-Version.
5.4.42-android12-0-00544-ged21d463f856
Beschreibung
Die Kernel-Version ist die eindeutige ID einer GKI-Version. Wenn zwei GKI-Binärdateien denselben Kernel-Release haben, müssen sie bytegenau identisch sein.
Ein Kernel-Release besteht aus einer KMI-Version, einer Unterebene und einem Suffix. Für die Zwecke dieses Dokuments wird das Suffix nach der KMI-Generierung ignoriert.
KMI-Version
Definition
Die KMI-Version wird so definiert:
KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w .x -zzz -k
Beachten Sie, dass die untergeordnete Ebene y nicht Teil der KMI-Version ist. Für das Beispiel im Abschnitt Kernel-Release ist die KMI-Version:
5.4-android12-0
Beschreibung
Die KMI-Version beschreibt die Kernelmodulschnittstelle (Kernel Module Interface, KMI) zwischen 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 dem einen kompatibel sind, sind auch mit dem anderen kompatibel.
Die KMI-Version darf durch OTA-Updates nicht verringert werden.
Unterebene
Die untergeordnete Ebene y beschreibt die Reihenfolge der Kernel-Releases innerhalb derselben KMI-Version.
Für zwei Kernel-Releases mit derselben KMI-Version, aber mit den Unterebenen 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 bedeutet, dass das untergeordnete Niveau durch kein OTA-Update verringert werden darf, wenn sich die KMI-Version nicht ändert.
Kernel-Release auf einem Gerät ermitteln
Die vollständige Kernel-Version kann mit dem folgenden Code-Snippet durch Ausführen von uname -r oder uname(2) ermittelt werden:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Beispielausgabe:
5.4.42-android12-0-00544-ged21d463f856
Für dieses Dokument wird alles nach der KMI-Generierung beim Extrahieren von Kernelinformationen ignoriert. Die Ausgabe von uname -r wird mit dem folgenden regulären Ausdruck geparst (vorausgesetzt, zzz beginnt immer mit „android“):
^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$
Die ignorierten Informationen können Informationen wie die Build-Nummer von ci.android.com, die Anzahl der Patches für den Baseline-Kernel und die SHA-Hashes des Git-Commits enthalten.
libkver
Die Bibliothek „libkver“ bietet eine C++-Schnittstelle zum Parsen der Kernel-Release- oder KMI-Versionsstrings. Eine Liste der APIs, die von libkver bereitgestellt werden, 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 von Geräteherstellern angegeben. Weitere Informationen finden Sie unter VINTF-Kernel-Abgleichsregeln.
Ab Android S kann der Android-Release-Teil der KMI-Version aus dem Kernel extrahiert und zur Build-Zeit in das Geräte-Manifest eingefügt werden.
Da sich die Anforderungen an die Kernelkonfiguration in der Regel nicht ändern, muss k nicht in der Kompatibilitätsmatrix codiert werden. Sollte es jedoch erforderlich sein, die Anforderung an die Kernelkonfiguration zu ändern, achten Sie auf Folgendes:
- Die entsprechende Anforderung aus der Kompatibilitätsmatrix wird entfernt.
- Es werden zusätzliche VTS-Tests hinzugefügt, um die neuen Anforderungen in Abhängigkeit von der KMI-Generierung zu prüfen.
Boot-Image-Version in OTA-Metadaten
Auch wenn das Boot-Image über ein OTA-Update aktualisiert wird, muss es im OTA-Payload-Format payload.bin verpackt sein. Die OTA-Nutzlast codiert für jede Partition ein version-Feld. Wenn update_engine eine OTA-Nutzlast verarbeitet, wird dieses Feld verglichen, um sicherzustellen, dass die Partition nicht herabgestuft wird.
Um Verwirrung zu vermeiden, wird das Feld version für die Boot-Partition in den OTA-Metadaten als boot image version bezeichnet.
Da die Ramdisk immer von Grund auf neu erstellt wird, reicht die Verwendung des Ramdisk-Zeitstempels aus, um das gesamte Boot-Image zu beschreiben. Die Kernel-Version muss nicht in der Boot-Image-Version codiert werden, es sei denn, Sie fügen in Zukunft ein altes Boot-Image in ein neues Kernel-Binärprogramm ein.
Vor einem OTA-Update prüft der OTA-Client die Version des Boot-Images auf dieselbe Weise wie bei jeder anderen Partition.