Auf dieser Seite wird das Versionierungsschema für generische Kernel-Images (GKIs) beschrieben. Ein Generic Kernel Image (GKI) verfügt über eine eindeutige Kennung, die als Kernel-Release bezeichnet wird. Die Kernel-Version besteht aus der Kernel-Modul-Interface-Version (KMI) und der Unterebene. Die Kernel-Version ist spezifisch für das zu veröffentlichende Image, während die KMI-Version die Schnittstelle darstellt, auf der eine Version erstellt wird. Eine KMI-Version kann mehrere Kernel-Releases unterstützen. Eine Kernel-Version ist nur an eine KMI-Version gebunden. In dem unwahrscheinlichen Fall, dass die Kernelmodulschnittstelle geändert werden muss, wird die KMI-Generierung iteriert, um die Änderung in der KMI-Version widerzuspiegeln.
Zusammenfassung der Begriffe
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 | wxy-zzz-k-Suffix | 5.4.42-android12-0-foo | Eindeutiger Bezeichner für eine GKI-Version. Dies ist der von uname zurückgegebene Wert. |
| KMI-Version | wx-zzz-k | 5.4-android12-0 | Beschreibt die Kernelmodulschnittstelle (KMI) zwischen GKI und dynamisch ladbaren Kernelmodulen (DLKM). |
| Unterebene | j | 42 | Beschreibt die Veröffentlichungsreihenfolge von Kernel-Releases innerhalb derselben KMI-Version. |
In der folgenden Tabelle sind weitere verwandte Begriffe als Referenz aufgeführt.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| wxy | wxy | 5.4.42 | Einzelheiten finden Sie unter Linux-Kernel-Makefiles (suchen Sie nach „KERNELRELEASE“). wxy wird in diesem Dokument direkt verwendet. Im Volksmund wird dies auch als dreiteilige Versionsnummer bezeichnet. Der in VINTF verwendete Begriff „Kernelversion“ könnte 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, verkleinert werden. |
| Kernel-Zweig | zzz-wx | android12-5.4 | Dieser Begriff wird in den allgemeinen Kernel-Zweigtypen verwendet. |
| Ausführung | w | 5 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird in libkver als Version bezeichnet. |
| Patch-Level | X | 4 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird in libkver als patch_level bezeichnet. |
| Android-Version | zzz | android12 | Dies ist die Android-(Dessert-)Versionsnummer, mit der der Kernel verknüpft ist. Beim Vergleich des Die Android-Release-Nummer darf durch keine Updates, einschließlich OTA oder Mainline, verringert werden. |
| KMI-Generation | k | 0 | Dies ist eine zusätzliche Zahl, die hinzugefügt wurde, um unwahrscheinliche Ereignisse zu bewältigen. Wenn eine Sicherheitslückenbehebung Änderungen am KMI innerhalb derselben Android-Version erfordert, wird eine KMI-Generation erhöht. Die KMI-Generierungsnummer beginnt mit 0. |
Versionierungsdesign
Kernel-Release
Definition
Für Geräte, die mit GKI ausgeliefert werden, ist die Kernel-Version wie folgt definiert:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Weitere Informationen finden Sie unter Bestimmen der Kernel-Version von einem Gerät .
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 dieselbe Kernel-Version haben, müssen sie byteweise identisch sein.
Eine Kernel-Version 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 ist wie folgt definiert:
KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w .x -zzz -k
Beachten Sie, dass die Unterebene y nicht Teil der KMI-Version ist. Für das Beispiel im Kernel-Release lautet die KMI-Version:
5.4-android12-0
Beschreibung
Die KMI-Version beschreibt die Kernelmodulschnittstelle (KMI) zwischen GKI und dynamisch ladbaren Kernelmodulen (DLKM).
Wenn zwei Kernel-Releases dieselbe KMI-Version haben, implementieren sie dieselbe Kernel-Modulschnittstelle. 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 Veröffentlichungsreihenfolge von Kernel-Releases innerhalb derselben KMI-Version.
Für zwei Kernel-Releases, die dieselbe KMI-Version haben, aber jeweils über die Unterebene Y1 und Y2 verfügen:
- Wenn Y1 kleiner oder gleich Y2 ist, kann ein Gerät, auf dem Y1 ausgeführt wird, ein Update auf Y2 erhalten.
- Wenn Y1 größer als Y2 ist, kann ein Gerät, auf dem Y1 ausgeführt wird, nicht auf Y2 aktualisiert werden.
Das heißt, wenn sich die KMI-Version nicht ändert, darf die Unterebene durch kein OTA-Update verringert werden.
Bestimmen der Kernel-Version von einem Gerät
Die vollständige Kernel-Version finden Sie durch Ausführen von uname -r oder uname(2) mit dem folgenden Codeausschnitt:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Eine Beispielausgabe ist:
5.4.42-android12-0-00544-ged21d463f856
Für die Zwecke dieses Dokuments wird alles nach der KMI-Generierung beim Extrahieren von Kernel-Informationen ignoriert. Formeller ausgedrückt wird die Ausgabe von uname -r mit dem folgenden regulären Ausdruck analysiert (vorausgesetzt, zzz beginnt immer mit „android“):
^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$
Zu den ignorierten Informationen können Informationen wie die Build-Nummer von ci.android.com , die Anzahl der Patches auf dem Basiskernel und SHA-Hashes des Git-Commits gehören.
libkver
Die Bibliothek libkver bietet eine C++-Schnittstelle zum Parsen der Kernel-Version oder einer KMI-Versionszeichenfolge. Eine Liste der APIs, die libkver verfügbar macht, finden Sie packages/modules/Gki/libkver/include/kver .
VINTF-Prüfungen
Für Android 11 oder niedriger wird der Android-Release-Teil der KMI-Version von den Geräteherstellern manuell im Gerätemanifest angegeben. Einzelheiten finden Sie unter VINTF-Kernel-Match-Regeln .
Ab Android S kann der Android-Release-Teil der KMI-Version aus dem Kernel extrahiert und zur Build-Zeit in das Gerätemanifest eingefügt werden.
Da sich die Anforderungen an die Kernel-Konfiguration im Allgemeinen nicht ändern, besteht keine Notwendigkeit, k innerhalb der Kompatibilitätsmatrix zu kodieren. Sollte jedoch der unwahrscheinliche Fall eintreten, dass die Kernel-Konfigurationsanforderung geändert werden muss, stellen Sie Folgendes sicher:
- Die entsprechende Anforderung aus der Kompatibilitätsmatrix wird entfernt.
- Zusätzliche VTS-Tests werden hinzugefügt, um die neuen Anforderungen abhängig von der KMI-Generierung zu überprüfen.
Boot-Image-Version in OTA-Metadaten
Auch wenn das Boot-Image über ein OTA-Update aktualisiert wird, muss es in das OTA-Nutzlastformat payload.bin verpackt werden. Die OTA-Payload codiert ein version für jede Partition. Wenn update_engine eine OTA-Nutzlast verarbeitet, vergleicht es dieses Feld, um sicherzustellen, dass die Partition nicht herabgestuft wird.
Um Verwirrung zu vermeiden, heißt das version für die Boot-Partition in den OTA-Metadaten boot image version .
Da die Ramdisk immer von Grund auf neu erstellt wird, reicht die Verwendung des Ramdisk-Zeitstempels aus, um das gesamte Boot-Image zu beschreiben. Es ist nicht erforderlich, die Kernel-Version in der Boot-Image-Version zu kodieren, es sei denn, Sie fügen in Zukunft ein altes Boot-Image in eine neue Kernel-Binärdatei ein.
Vor einem OTA-Update überprüft der OTA-Client die Boot-Image-Version auf die gleiche Weise wie jede andere Partition.