Auf dieser Seite wird das Versionierungsschema für generische Kernel-Images (GKIs) beschrieben. Ein generisches Kernel-Image (GKI) hat eine eindeutige Kennung, die Kernel-Version genannt wird. Das Kernel-Release besteht aus der Version der Kernel-Modul-Schnittstelle (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 eine Version erstellt wird. Eine KMI-Version kann mehrere Kernel-Releases unterstützen. Ein Kernel-Release ist nur an eine KMI-Version gebunden. In dem unwahrscheinlichen Fall, dass die Schnittstelle des Kernelmoduls geändert werden muss, wird die KMI-Generierung wiederholt, um die Änderung der KMI-Version widerzuspiegeln.
Zusammenfassung der Begriffe
Die folgende Tabelle fasst wichtige Begriffe zusammen, die auf dieser Seite und für GKI-Updates verwendet werden.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| Kernel-Veröffentlichung | 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 Release-Reihenfolge 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. Dies wird allgemein 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 nicht durch Updates, einschließlich OTA oder Mainline, verringert werden. |
| Kernel-Zweig | zzz-wx | android12-5.4 | Dieser Begriff wird in 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 Versionsnummer von Android (Dessert), mit der der Kernel verknüpft ist. Beim Vergleich des Die Android-Versionsnummer darf nicht durch Updates verringert werden, einschließlich OTA oder Mainline. |
| KMI-Generation | k | 0 | Dies ist eine zusätzliche Zahl, die hinzugefügt wird, um mit unwahrscheinlichen Ereignissen umzugehen. Wenn eine Sicherheitsfehlerbehebung Änderungen am KMI innerhalb derselben Android-Version erfordert, wird eine KMI-Generation erhöht. Die KMI-Generierungsnummer beginnt mit 0. |
Versionierungsdesign
Kernel-Veröffentlichung
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 Ermitteln 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 in Kernel-Release lautet die KMI-Version:
5.4-android12-0
Beschreibung
Die KMI-Version beschreibt die Kernel-Modul-Schnittstelle (KMI) zwischen GKI und dynamisch ladbaren Kernel-Modulen (DLKM).
Wenn zwei Kernel-Releases dieselbe KMI-Version haben, implementieren sie dieselbe Kernel-Modulschnittstelle. Die mit dem einen kompatiblen DLKMs sind auch mit dem anderen kompatibel.
Die KMI-Version darf durch keine OTA-Updates verringert werden.
Unterebene
Die Unterebene y beschreibt die Release-Reihenfolge von Kernel-Releases innerhalb derselben KMI-Version.
Für zwei Kernel-Versionen, die dieselbe KMI-Version haben, aber die Unterebenen Y1 bzw. Y2 haben:
- 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.
Kernel-Release von einem Gerät bestimmen
Die vollständige Kernel-Version 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 : "";
}
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. Formaler wird die Ausgabe von uname -r mit der folgenden Regex 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 über dem Basiskernel und SHA-Hashes des Git-Commits enthalten.
libkver
Die Bibliothek libkver bietet eine C++-Schnittstelle zum Analysieren der Kernel-Version oder einer KMI-Versionszeichenfolge. Eine Liste der von libkver bereitgestellten APIs finden Sie unter packages/modules/Gki/libkver/include/kver .
VINTF-Prüfungen
Für Android 11 oder niedriger wird der Android-Release-Teil der KMI-Version manuell im Gerätemanifest von den Geräteherstellern angegeben. Einzelheiten finden Sie unter VINTF-Kernel-Match-Regeln .
Von 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 Kernel-Konfigurationsanforderungen im Allgemeinen nicht ändern, ist es nicht erforderlich, k innerhalb der Kompatibilitätsmatrix zu codieren. Stellen Sie jedoch in dem unwahrscheinlichen Fall, dass die Kernel-Konfigurationsanforderung geändert werden muss, Folgendes sicher:
- Die entsprechende Anforderung aus der Kompatibilitätsmatrix wird entfernt.
- Zusätzliche VTS-Tests werden hinzugefügt, um die neuen Anforderungen in Abhängigkeit von der KMI-Generierung zu überprüfen.
Boot-Image-Version in OTA-Metadaten
Selbst wenn das Boot-Image über OTA aktualisiert wird, muss es in das OTA-Payload-Format payload.bin . Die OTA-Nutzdaten kodieren 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 codieren, es sei denn, Sie heften in Zukunft ein altes Boot-Image an eine neue Kernel-Binärdatei.
Vor einem OTA-Update überprüft der OTA-Client die Boot-Image-Version auf die gleiche Weise wie jede andere Partition.