Releaseprozess für generisches Kernel-Image (GKI)

Auf dieser Seite wird beschrieben, wie GKI veröffentlicht wird, einschließlich vierteljährlicher und außerplanmäßiger Notfall-Releases. Auf dieser Seite finden OEMs eine Anleitung dazu, wo sie den GKI abrufen können und wie der Prozess für Out-of-Band-Notfallkorrekturen abläuft. 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. OEMs können Geräte mit GKI-zertifizierten Builds auf den Markt bringen, sofern diese den Anforderungen an LTS-Kernel (Long-Term Supported) 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ähriger GKI-Release-Kandidat (nicht zertifiziert) ausgewählt. 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 fehlgeschlagenen Test führen. Der Release-Kandidat wird einer Qualitätssicherung unterzogen, wie im Abschnitt zur GKI-Qualifizierung beschrieben. Dabei wird geprüft, ob die Compliance-Tests für einen GSI+GKI-Build mit einem Referenzgerät sowie mit Cuttlefish bestanden werden.

Abbildung 1: Zeitplan für GKI-Releases

GKI-Qualifikationen

Build-Artefakte abrufen

OEMs können Artefakte für alle Releases unter ci.android.com abrufen.

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 die Patches, die auf den ausgewählten vierteljährlich zertifizierten Kernels basieren. Diese Respins enthalten alle Launch-Blocking-Fehlerkorrekturen, die bis zu einem bestimmten Zeitpunkt von OEMs gemeldet wurden, die das entsprechende vierteljährliche Basisrelease verwenden. Das folgende Beispiel veranschaulicht, 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 stellen Probleme fest, für die Patches erforderlich sind. Diese Patches können unterschiedlich oder gleich sein.
• Die Respins des Binärprogramms vom November 2021 enthalten startblockierende Fehlerkorrekturen, die sowohl von OEM1 als auch von OEM2 während des Respin-Zeitraums gemeldet wurden.
• 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 für einzelne OEMs 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 bestätigen, 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, voneinander profitiert, insbesondere wenn die entdeckten Fehler allgemein sind und für alle Nutzer gelten. Ein konkretes Beispiel für dieses Konzept sind schwerwiegende Kernel-Bugs, die bei Carrier-Tests gefunden wurden.

Gibt es Situationen, in denen Google spezifische 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 GKI-Team das Problem verstanden und alle Details erfasst hat. Sie können dies im Changelog (Commit-Nachricht) sehen. Google gibt nicht an, welches Gerät betroffen ist, aber OEMs können die Problembeschreibung und die Lösung jederzeit im Changelog nachlesen.