Auf dieser Seite wird das Versionsverwaltungsschema für generische Kernel-Images (GKIs) beschrieben. A Generisches Kernel-Image (GKI) eine eindeutige Kennung hat, die als Kernel-Release bezeichnet wird. Der Kernel-Release besteht aus der KMI-Version (Kernel Module Interface) und der Unterebene. Der Kernel Release ist spezifisch für das veröffentlichte Image, während die KMI-Version steht für die Schnittstelle, auf der ein Release erstellt wird. Eine KMI-Version kann mehrere Kernel-Releases. Ein Kernel-Release ist nur an eine KMI-Version gebunden. In den unwahrscheinlichen Fall, bei dem die Benutzeroberfläche des Kernel-Moduls geändert werden muss, wird iteriert, um die Änderung der KMI-Version widerzuspiegeln.
Zusammenfassung der Begriffe
In der folgenden Tabelle sind die wichtigsten Begriffe zusammengefasst, die auf dieser Seite verwendet werden, und für GKI-Updates.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| Kernel-Release | Suffix w.x.y-zzz-k | 5.4.42-android12-0-foo | Eindeutige Kennung für einen GKI-Release. Dies ist der Wert
zurückgegeben von uname. |
| KMI-Version | W.X-ZZ-K | 5,4-Android12-0 | Beschreibt die Kernel-Modulschnittstelle (KMI) zwischen GKI und DLKM (Dynamic Loadable Kernel Modules) |
| Unterebene | y | 42 | Beschreibt die Releasereihenfolge der Kernel-Releases innerhalb der mit derselben KMI-Version. |
In der folgenden Tabelle sind weitere verwandte Begriffe als Referenz aufgeführt.
| Name | Symbol | Beispiel | Beschreibung |
|---|---|---|---|
| B.x.y | B.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 ist auch auch als dreiteilige Versionsnummer bezeichnet. Der verwendete Begriff in VINTF, Kernel-Version, kann zu Verwechslungen mit anderen Begriffen, insbesondere W. Diese Variable wird in libkver als kernel_version_tuple bezeichnet. Dieses Tupel darf durch Updates nicht verringert werden, einschließlich OTA- oder Mainline. |
| Kernel-Branch | zzz-w.x | android12–5.4 | Dieser Begriff wird in folgenden Sprachen verwendet: <ph type="x-smartling-placeholder"></ph> Gängige Kernel-Branch-Typen. |
| Version | w | 5 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird als version in libkver |
| Patch-Level | x | 4 | Dieser Begriff wird in diesem Dokument nicht verwendet. Diese Variable wird als patch_level in libkver |
| Android-Release | Zzz | Android 12 |
Dies ist die mit dem Kernel verknüpfte Android-Releasenummer (Dessert) mit.
Beim Vergleich des Felds Die Android-Release-Nummer darf nicht durch Updates herabgesetzt werden. Dazu gehören Onlinereisebüro oder Mainline. |
| KMI-Generierung | k | 0 |
Dies ist eine zusätzliche Zahl, die für Ereignisse. Wenn eine Fehlerkorrektur zur Sicherheit Änderungen an der KMI innerhalb derselben Android-Version, eine KMI-Generation wurde erhöht. Die KMI-Generierungsnummer beginnt mit 0. |
Versionsverwaltungsdesign
Kernel-Release
Definition
Für Geräte, die mit GKI ausgeliefert werden, ist der Kernel-Release so definiert:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Weitere Informationen finden Sie unter Kernel-Release von einem Gerät.
Das folgende Beispiel zeigt eine Kernel-Version.
5.4.42-android12-0-00544-ged21d463f856
Beschreibung
Der Kernel-Release ist die eindeutige ID einer GKI-Version. Wenn zwei GKI-Binärdateien desselben Kernel-Release müssen sie byteweise identisch sein.
Ein Kernel-Release besteht aus einer KMI-Version, einer Unterebene und einem Suffix. Für 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. Für das Beispiel
Im Kernel-Release ist die KMI-Version:
5.4-android12-0
Beschreibung
Die KMI-Version beschreibt die Kernel Module Interface (KMI) zwischen GKI und DLKM (Dynamic Loadable Kernel Modules) verfügbar.
Wenn zwei Kernel-Releases dieselbe KMI-Version haben, implementieren sie denselben Kernel Module. Die mit einem der DLKMs kompatiblen mit der anderen.
Die KMI-Version darf nicht durch OTA-Updates herabgesetzt werden.
Unterebene
Die Unterebene y beschreibt die Releasereihenfolge der Kernel-Releases innerhalb der
mit derselben KMI-Version.
Für zwei Kernel-Releases mit derselben KMI-Version, aber mit der Unterebene Y1 und bzw. Y2:
- Wenn Y1 kleiner oder gleich Y2 ist, kann ein Gerät mit Y1 ein auf Y2 aktualisieren.
- 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 untergeordnete Ebene nicht verringert werden durch OTA-Updates behoben werden.
Kernel-Release von einem Gerät ermitteln
Den vollständigen Kernel-Release finden Sie, indem Sie uname -r ausführen oder
uname(2)
mit dem folgenden Code-Snippet:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Hier ist eine Beispielausgabe:
5.4.42-android12-0-00544-ged21d463f856
In diesem Dokument wird nach der KMI-Generierung alles ignoriert.
wenn Sie Kernel-Informationen extrahieren. Formaler lautet die Ausgabe von uname -r:
mit dem 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 das ci.android.com-Build-Nummer, Anzahl der Patches auf dem Referenzkernel und SHA-Hashes des Git-Commits.
Libkver
Die Bibliothek libkver bietet eine C++-Schnittstelle zum Parsen des Kernel-Release oder eines
KMI-Versionsstring. 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 ist der Android-Release-Teil der KMI-Version manuell im Gerätemanifest durch den Gerätehersteller angegeben. Weitere Informationen Siehe VINTF-Kernel-Abgleichregeln.
Aus Android S kann der Android-Release-Teil der KMI-Version extrahiert werden. aus dem Kernel gesendet und bei der Build-Erstellung in das Gerätemanifest eingefügt werden.
Da sich die Kernel-Konfigurationsanforderungen in der Regel nicht ändern, gibt es keine
k innerhalb der Kompatibilitätsmatrix codieren müssen. Im unwahrscheinlichen
in denen die Kernel-Konfiguration
geändert werden muss,
Folgendes:
- Die entsprechende Anforderung aus der Kompatibilitätsmatrix wird entfernt.
- Es werden zusätzliche VTS-Tests hinzugefügt, um die neuen Anforderungen zu prüfen zur KMI-Generierung.
Boot-Image-Version in OTA-Metadaten
Auch wenn das Boot-Image über ein OTA-Update aktualisiert wird, muss es
im OTA-Nutzlastformat payload.bin eingebunden. Die OTA-Nutzlast codiert eine
version für jede Partition. Wenn update_engine eine OTA-Nutzlast verarbeitet,
wird dieses Feld verglichen, um sicherzustellen, dass die Partition nicht herabgestuft wird.
Zur Vermeidung von Verwechslungen enthält das Feld version für die Bootpartition im OTA
Metadaten heißt boot image version.
Da die RAM-Disk immer von Grund auf neu erstellt wird, wird ramdisk Der Zeitstempel reicht aus, um das gesamte Boot-Image zu beschreiben. Es ist nicht notwendig, Codieren Sie den Kernel-Release in der Boot-Image-Version, es sei denn, Sie fügen einen alten einem neuen Kernel-Binärprogramm hinzufügen.
Vor einem OTA-Update prüft der OTA-Client die Boot-Image-Version. genau wie jede andere Partition.