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-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, einschließlich OTA- oder Mainline-Updates, verringert werden. |
| 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 |
Diese zusätzliche Zahl wird hinzugefügt, um unwahrscheinliche Ereignisse zu berücksichtigen. 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 Kernelrelease 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 keine OTA-Updates verringert werden.
Unterebene
Die Unterebene 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 heißt, wenn sich die KMI-Version nicht ändert, darf das untergeordnete Level durch kein OTA-Update verringert werden.
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. Genauer gesagt wird die Ausgabe von uname -r 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 OTA 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 der Ramdisk-Zeitstempel aus, um das gesamte Boot-Image zu beschreiben. Es ist nicht erforderlich, die Kernel-Version in der Boot-Image-Version zu codieren, es sei denn, Sie fügen in Zukunft ein altes Boot-Image in eine neue Kernel-Binärdatei ein.
Vor einem OTA-Update prüft der OTA-Client die Version des Boot-Images auf dieselbe Weise wie bei jeder anderen Partition.