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 Notfallveröffentlichungen. Auf dieser Seite finden OEMs eine Anleitung dazu, wo sie den GKI erhalten, sowie Informationen 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

Das GKI wird nach dem KMI-Freeze vierteljährlich 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 (Langzeitsupport) im Sicherheitsbulletin für Android entsprechen.

16‑KB-GKI-Releases

Das GKI-Release-Team behandelt 16‑KB-GKI-Releases mit demselben vierteljährlichen Release-Rhythmus, denselben Qualifizierungstests und demselben Respin-Prozess wie 4‑KB-GKI-Releases:

• Unterstützte Zweige:
  • android15-6.6 (ab Januar 2026)
  • android16-6.12 (ab März 2026)
  • android17-6.18 (ab Juni 2026)
• Parität und Zertifizierung:16 KB-GKI-Binärdateien verwenden dasselbe Quell-Tag und dieselbe Kernel-Build-ID wie die entsprechende 4 KB-GKI-Version. Bis 2027 finden Sie auf dem Tab 16-KB-Release-Build auf den Release-Build-Seiten android15-6.6, android16-6.12 und android17-6.18 nicht zertifizierte 16-KB-GKI-Release-Binärdateien. Du musst 4‑KB- und 16‑KB-Kernel nicht zusammen aktualisieren, wir empfehlen es jedoch.
• On-Demand-Respins: Fordern Sie 16‑KB-GKI-Respins mit demselben Respin-Anfrageprozess und ‑Formular wie für 4‑KB-Builds an.

Vierteljährliche zertifizierte Releases

Die vierteljährlichen GKI-Releases enthalten ein getestetes boot.img mit einem von Google eingefügten Zertifikat, das bestätigt, dass die Binärdateien aus einer bekannten Quellcode-Baseline erstellt wurden.

In jedem Quartal wird nach dem Stichtag für die Einreichung ein GKI-Releasekandidat (nicht zertifiziert) ausgewählt. Nachdem der vierteljährliche Releasekandidat ausgewählt wurde, werden keine neuen Änderungen mehr in den Release dieses Monats aufgenommen. Während des geschlossenen Zeitfensters können nur Fehler behoben werden, die zu einem Testfehler führen. Der Releasekandidat wird einer Qualitätssicherung unterzogen, wie im Abschnitt zur GKI-Qualifizierung beschrieben. Dabei wird geprüft, ob die Konformitätstests auf einem GSI+GKI-Build mit einem Referenzgerät sowie Cuttlefish erfolgreich sind.

Abbildung 1: GKI-Releasezeitachse

GKI-Anforderungen

Wo Build-Artefakte abgerufen werden können

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

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

Häufig gestellte Fragen

Hier findest du 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 von out/.../dist abrufen.

Wurde die GKI-Binärdatei (einschließlich des Notfall-Spin-Patches) auf der neuesten Codebasis 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. Im folgenden Beispiel sehen Sie, wie ein solches Szenario aussehen kann.

• OEM1 und OEM2 entscheiden sich für die GKI-Binärversion von November 2021.
• OEM1 und OEM2 finden Probleme, für die Patches für den Support erforderlich sind. Diese Patches können unterschiedlich oder gleich sein.
• Die Respins des Binärprogramms vom November 2021 enthalten startverhindernde Fehlerkorrekturen, die sowohl von OEM1 als auch von OEM2 während des Respin-Zeitraums gemeldet wurden.
• Die im zweiten Aufzählungspunkt 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 betreffen uns jedoch, 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 überprüfen, ob 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 gefundenen Fehler allgemein sind und für alle Nutzer gelten. Ein konkretes Beispiel für dieses Konzept sind Fehler im Kern des Kernels, die bei Tests von Mobilfunkanbietern gefunden werden.

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

Google fügt einem Respin-Build erst dann eine Änderung hinzu, wenn das GKI-Team das Problem verstanden und alle Details erfasst hat. Das können Sie im Changelog (Commit-Nachricht) sehen. Google gibt nicht an, welches Gerät genau betroffen ist. OEMs finden die Problembeschreibung und die Lösung jedoch immer im Änderungsprotokoll.