Releaseprozess für generisches Kernel-Image (GKI)

Auf dieser Seite wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlicher, vierteljährlicher und außerplanmäßiger Notfall-Releases. Ziel dieses Dokuments ist es, OEMs eine Anleitung zu geben, wo sie den GKI abrufen können, sowie zum Prozess für Out-of-Band-Notfallkorrekturen. OEMs können auch die GKI-Entwicklung nutzen, um mehr darüber zu erfahren, wie sie mit dem Android-Kernel-Team zusammenarbeiten können, um den GKI-Kernel für ihre Produkte zu optimieren.

GKI-Release-Rhythmus

GKI wird vierteljährlich nach dem KMI-Freeze veröffentlicht.

GKI-Build-Gültigkeit für OEMs

OEMs können ein kürzlich veröffentlichtes Android GKI verwenden. Erstausrüster können GKI-zertifizierte Builds einführen, solange sie den LTS-Anforderungen im Sicherheitsbulletin für Android entsprechen.

Vierteljährliche zertifizierte Releases

GKI-Quartalsreleases enthalten einen getesteten boot.img, der ein von Google eingefügtes Zertifikat enthält, um zu bestätigen, dass die Binärdateien aus einer bekannten Quellcode-Baseline erstellt wurden.

Jedes Quartal wird nach dem Check-in-Stichtag ein vierteljährlicher GKI-Release-Kandidat (nicht zertifiziert) ausgewählt. Das ist in der Regel der zweite wöchentliche Build des jeweiligen Monats. Nachdem der vierteljährliche Release-Kandidat ausgewählt wurde, werden keine neuen Änderungen mehr für den Release dieses Monats akzeptiert. Während des geschlossenen Zeitraums können nur Fehler behoben werden, die zu einem Testfehler führen. Der Release-Kandidat wird einer Qualitätssicherung unterzogen, wie im Abschnitt zur GKI-Qualifizierung beschrieben. So wird sichergestellt, dass die Compliance-Tests für den GSI+GKI-Build mit einem Referenzgerät sowie mit Cuttlefish bestanden werden.

Abbildung 1: Zeitplan für GKI-Releases

GKI-Qualifikationen

Build-Artefakte abrufen

Artefakte für alle Releases sind unter ci.android.com verfügbar.

Weitere Informationen zur CI, einschließlich der Testergebnisse, finden Sie im Android Continuous Integration-Dashboard.

Häufig gestellte Fragen

Hier finden Sie einige häufig gestellte Fragen zum GKI-Releaseprozess.

Ist es möglich, ein neues GKI-Binärprogramm auf Grundlage eines bereits veröffentlichten GKI zu erstellen?

Ja, das wird als Respin bezeichnet. Der Respin-Prozess wird unterstützt, solange der veröffentlichte GKI-Build, für den der Respin angefordert wird, den LTS-Anforderungen im Sicherheitsbulletin für Android entspricht.

Ist es möglich, GKI-Binärdateien zu reproduzieren?

Ja, hier ein Beispiel:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Laden Sie manifest_$id.xml herunter und führen Sie den folgenden Befehl aus, um das Beispiel zu reproduzieren:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Sie können Ihre GKI-Artefaktkopie unter out/.../dist abrufen.

Wurde die GKI-Binärdatei (einschließlich des Notfall-Spin-Patches) auf der Grundlage des neuesten Quellcodes erstellt?

Nein. Respins enthalten nur Patches, die auf den ausgewählten vierteljährlich zertifizierten Kernels basieren. Diese Respins enthalten alle Fehlerkorrekturen, die bis zu einem bestimmten Zeitpunkt von OEMs mit dem entsprechenden vierteljährlichen Basisrelease gemeldet wurden und die den Start verhindern. Im folgenden Beispiel sehen Sie, wie ein solches Szenario aussehen kann.

• OEM1 und OEM2 entscheiden sich für die Verwendung des GKI-Binär-Release vom November 2021.
• OEM1 und OEM2 finden Probleme, für die Patches erforderlich sind. Diese Patches können unterschiedlich oder gleich sein.
• Die Respins über dem Binärprogramm vom November 2021 enthalten startverhindernde Fehlerkorrekturen, die sowohl von OEM1 als auch von OEM2 während des Respin-Zeitraums gemeldet wurden, aber nichts weiter.
• Die im zweiten Aufzählungszeichen genannten Probleme sind auch in den nachfolgenden vierteljährlichen GKI-Releases enthalten.

Der Respin vom Oktober enthält alle von OEMs eingereichten Patches. Andere OEM-Patches wirken sich jedoch auf uns aus, da sie nicht speziell mit unseren Produkten getestet wurden. Ist es möglich, nur unseren Patch einzubinden?

Das ist nicht möglich. Ein Respin-Pfad „pro OEM“ ist nicht skalierbar. Stattdessen prüft das GKI-Team jede einzelne Änderung, die in Respin-Builds einfließt, und testet die Änderungen mit allen verfügbaren Hardwarekomponenten, bevor ein neuer Build erstellt wird. Wenn das GKI-Team feststellt, dass das Problem spezifisch für einen OEM, ein Gerät oder ein Modell ist, kann es dafür sorgen, dass der durch die Änderung hinzugefügte Code nur auf dem betroffenen Gerät, Modell oder der betroffenen SKU ausgeführt wird.

Der Hauptvorteil von einheitlichen Respins besteht darin, dass jedes Gerät, das dieselbe Release-Basis verwendet, von den anderen profitiert, insbesondere wenn die gefundenen Fehler allgemein sind und für alle Nutzer gelten. Kern-Kernel-Bugs, die bei Carrier-Tests gefunden werden, sind ein konkretes Beispiel für dieses Konzept.

Gibt es Situationen, in denen Google bestimmte Informationen zu OEM-Patches und Problemszenarien bereitstellt, damit OEMs die Auswirkungen und das Risiko der Implementierung der Patches in ihren Produkten bewerten können?

Google nimmt keine Änderungen an einem Respin-Build vor, bevor das Problem verstanden und alle Details erfasst wurden. Das ist im Changelog (Commit-Nachricht) zu sehen. Google gibt nicht an, welches Gerät genau betroffen ist. OEMs können die Problembeschreibung und die Lösung jedoch jederzeit im Changelog nachlesen.