GKI-Versionsschema

Auf dieser Seite wird das Versionierungsschema für generische Kernel-Images (GKIs) beschrieben. Ein Generic Kernel Image (GKI) hat eine eindeutige Kennung, 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. Eine Kernelversion ist nur mit einer KMI-Version verknüpft. 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. Das ist der Wert, der von uname zurückgegeben wird.
KMI-Version w.x-zzz-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 ähnliche Begriffe aufgeführt.

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. Diese wird 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. In libkver wird diese Variable als patch_level bezeichnet.
Android-Release Zzz android12

Dies ist die Android-Versionsnummer (dessert), mit der der Kernel verknüpft ist.

Beim Vergleichen des Felds AndroidRelease wird der numerische Teil zum Vergleich aus dem String extrahiert.

Die Android-Release-Nummer darf durch Updates nicht niedriger werden, einschließlich OTA- oder Mainline-Updates.

KMI-Generierung k 0

Dies ist eine zusätzliche Zahl, die für unwahrscheinliche 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.

Versionsdesign

Kernel-Release

Definition

Für Geräte, die mit GKI ausgeliefert werden, ist die Kernelversion so definiert:

KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w      .x         .y       -zzz           -k            -something

Weitere Informationen finden Sie unter Kernelversion von einem Gerät ermitteln.

Das folgende Beispiel zeigt eine Kernelversion.

5.4.42-android12-0-00544-ged21d463f856

Beschreibung

Der Kernel-Release ist die eindeutige ID einer GKI-Version. Wenn zwei GKI-Binärdateien dieselbe Kernelversion haben, müssen sie byteweise identisch sein.

Ein Kernelrelease 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-Modul-Schnittstelle (Kernel Module Interface, KMI) zwischen der GKI und dynamisch ladbaren Kernelmodulen (Dynamically Loadable Kernel Modules, DLKM).

Wenn zwei Kernelversionen dieselbe KMI-Version haben, implementieren sie dieselbe Kernelmodul-Schnittstelle. 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 Unterebene durch ein Over-the-air-Update nicht herabgesetzt werden.

Kernel-Release von einem Gerät ermitteln

Die vollständige Kernelversion 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 : "";
}

Hier ist eine Beispielausgabe:

5.4.42-android12-0-00544-ged21d463f856

Im Rahmen dieses Dokuments wird beim Extrahieren von Kernelinformationen alles nach der KMI-Generierung ignoriert. 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+).*$

Zu den ignorierten Informationen gehören unter anderem die Build-Nummer von ci.android.com, die Anzahl der Patches auf dem Basiskernel und die 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

Bei Android 11 oder niedriger wird der Android-Release-Teil der KMI-Version manuell im Gerätemanifest vom 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 Anforderungen an die Kernelkonfiguration in der Regel nicht ändern, muss k nicht in die Kompatibilitätsmatrix codiert werden. Für den unwahrscheinlichen Fall, dass die Kernelkonfiguration geändert werden muss, beachten Sie 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, die sich auf die KMI-Generierung beziehen.

Version des Boot-Images in den OTA-Metadaten

Auch wenn das Boot-Image über ein OTA-Update aktualisiert wird, muss es im OTA-Nutzlastformat payload.bin verpackt sein. Die OTA-Nutzlast codiert ein version für jede Partition. Wenn update_engine eine OTA-Nutzlast verarbeitet, wird dieses Feld verglichen, um sicherzustellen, dass die Partition nicht heruntergestuft wird.

Zur Vermeidung von Verwechslungen enthält das Feld version für die Bootpartition im OTA Metadaten heißt boot image version.

Da das RAM-Disk immer von Grund auf neu erstellt wird, reicht der RAM-Disk-Zeitstempel aus, um das gesamte Boot-Image zu beschreiben. Es ist nicht nötig, 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.