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 einen kürzlich veröffentlichten Android GKI verwenden. Erstausrüster können GKI-zertifizierte Builds auf den Markt bringen, solange sie den LTS-Anforderungen im Sicherheitsbulletin für Android entsprechen.

Wöchentliche Entwickler-Releases

GKI-Binärdateien sind als Self-Service über Android CI verfügbar, sobald Änderungen zusammengeführt werden. Wöchentliche Builds sind nicht zertifiziert, können aber als Grundlage für Entwicklung und Tests verwendet werden. Wöchentliche Builds können nicht für Produktionsgeräte-Builds für Endnutzer verwendet werden.

Vierteljährliche zertifizierte Releases

Die vierteljährlichen GKI-Releases 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

Notfall-Respin-Prozess

Ein Respin bezieht sich auf den Prozess des erneuten Zusammenführens, Neuerstellens, erneuten Testens und erneuten Zertifizierens eines Binärprogramms nach einer öffentlichen Veröffentlichung des GKI-Kernels. Sie können in den folgenden Fällen eine erneute Überprüfung eines zertifizierten Binärprogramms beantragen:

• So aktualisieren Sie eine Symbolliste:
• So wenden Sie eine Korrektur auf einen Fehler an, einschließlich Fehler, die während der Genehmigung im Labor des Mobilfunkanbieters gefunden wurden:
• So fügen Sie einen Anbieter-Hook hinzu:
• So wenden Sie einen Patch auf ein vorhandenes Feature an:
• Einen Sicherheitspatch anwenden (nach 6 Monaten)

Sicherheitsupdates werden bis zu 6 Monate nach der Veröffentlichung des Release-Zweigs automatisch in einen Release-Zweig zusammengeführt. Nach Ablauf der 6-Monats-Frist müssen Sie einen Respin anfordern, um Sicherheitspatches auf einen Branch anzuwenden.

Richtlinien für erneute Spins

Beachten Sie vor dem Beantragen eines Respins die folgenden Richtlinien:

• Respins sind nur in Release-Branches nach der ersten öffentlichen Veröffentlichung eines vierteljährlichen Builds zulässig.

• Respin-Anfragen werden für einen bestimmten Release-Zweig nur bis zu sechs Monate nach der ersten öffentlichen Veröffentlichung akzeptiert. Nach sechs Monaten sind Branches nur für Respins mit Sicherheitspatches berechtigt, die in einem Sicherheitsbulletin für Android aufgeführt sind.

• Wenn die LTS-Anforderungen, die im Sicherheitsbulletin für Android definiert sind, dazu führen, dass der Zweig nicht mehr den Richtlinien entspricht, wird er eingestellt. Respin-Anfragen für eingestellte Zweige werden nicht akzeptiert. Das Einstellungsdatum für einen bestimmten GKI-Release-Zweig ist in den vierteljährlichen GKI-Release-Build-Hinweisen unter Releases enthalten. Für die zukünftige Planung werden die LTS-Anforderungen jährlich im Mai und November aktualisiert. Der android12-5.10-2023-07-Zweig (5.10.177) wird beispielsweise für Respins nach dem 1. Mai 2024 nicht unterstützt, da der android12-5.10-2023-07-Zweig (5.10.177) nicht den LTS-Anforderungen von ASB-2024-05 entspricht.

• Respins sind nur für dringende Fehlerkorrekturen, Aktualisierungen der Symbolliste oder zum Anwenden eines Patches zur Behebung eines Fehlers in einer vorhandenen Funktion zulässig.

• Alle Patches, die in den vierteljährlichen Release-Branch aufgenommen werden, müssen bereits in den Hauptentwicklungs-Branch des GKI zusammengeführt worden sein. Wenn beispielsweise ein Patch für einen Respin von android12-5.10-2022-09 erforderlich ist, muss er bereits in android12-5.10 zusammengeführt worden sein.

• Sie müssen Patches aus dem Hauptentwicklungszweig von GKI auswählen und in den vierteljährlichen Releasezweig hochladen.

• In der Anfrage für eine erneute Antwort müssen Sie der Anfrage eine Priorität (Dringlichkeit) zuweisen. Diese Priorität hilft dem GKI-Team, Partner rechtzeitig besser zu unterstützen. Markieren Sie kritische oder dringende Anfragen mit der Priorität P0. Bei P0- und P1-Anfragen müssen Sie die Dringlichkeit begründen. In der folgenden Tabelle finden Sie eine Zuordnung von Fehlerpriorität und Zeit bis zur Lösung (Estimated Time to Resolution, ESRT):

  Priorität	ESRT
  P0	2 Werktage
  P1	5 Werktage
  P2	10 Werktage
  P3	15 Geschäftstage

• Sie müssen für jeden Release-Zweig einen separaten Respin-Antrag einreichen. Wenn beispielsweise für android12-5.10-2022-08 und android12-5.10-2022-09 eine erneute Überprüfung erforderlich ist, müssen Sie zwei Anträge auf erneute Überprüfung erstellen.

• Nachdem ein Build bereitgestellt und eine Respin-Anfrage als behoben markiert wurde, sollten Sie die Respin-Anfrage nicht wieder öffnen, um zusätzliche CLs hinzuzufügen. Wenn zusätzliche Patches zusammengeführt werden müssen, müssen Sie eine neue Respin-Anfrage einreichen.

• Fügen Sie für jede infrage kommende CL die folgenden Tags hinzu.

  • Bug: Die Fehler-ID muss der Commit-Nachricht für jede CL hinzugefügt werden.
  • Change-Id: muss mit der Change-ID der Änderung des Basis-Branch übereinstimmen.

• Wenn für eine Anfrage zur erneuten Überprüfung eine Antwort von Ihnen erforderlich ist und Sie nicht innerhalb von drei Arbeitstagen antworten, wird die Priorität um eine Stufe herabgestuft (z. B. von P0 auf P1). Wenn Sie zwei Wochen lang nicht reagieren, wird der Fehler als Won't Fix (Obsolete) (Wird nicht behoben (Veraltet)) markiert.

Respin-Anfrage einreichen

Das folgende Diagramm zeigt den Respin-Prozess. Der Prozess beginnt, wenn der OEM-Partner (Sie) die Respin-Anfrage einreicht.

Abbildung 2: Der Respin-Prozess

So starten Sie den Respin-Prozess:

1. Füllen Sie das Formular für die erneute Überprüfung des GKI aus und wenden Sie sich umgehend an Ihren Google Technical Account Manager. Mit diesem Formular wird ein Fehler für eine GKI-Respin-Anfrage erstellt. Fehler bei Respin-Anfragen sind für Sie (den Antragsteller), das GKI-Team und bestimmte Personen sichtbar, die Sie der CC-Liste des Fehlers hinzufügen.
   • Wenn Sie bereits eine Korrektur haben, sollte der Antrag auf die Patch-Einreichung in AOSP verweisen, damit Google sie prüfen kann. Wenn das Einreichen des Patches nicht möglich ist, muss er als Textdatei an die Anfrage angehängt werden.
   • Wenn Sie keine Lösung haben, muss die Anfrage so viele Informationen wie möglich enthalten, einschließlich der Kernelversionsnummer und der Protokolle, damit Google bei der Fehlerbehebung helfen kann.
2. Das Google GKI-Team prüft die Anfrage und genehmigt sie oder weist sie Ihnen zu, wenn weitere Informationen erforderlich sind.
3. Nachdem eine Korrektur vereinbart wurde, führt das Google GKI-Team eine Code-Überprüfung (CR+2) der Änderung durch. Die Überprüfung beginnt mit dem ESRB-Zeitrahmen. Das GKI-Team führt die Änderung zusammen, erstellt sie, testet sie auf Regression und zertifiziert sie.
4. Das Binärprogramm wird auf ci.android.com veröffentlicht. Der ESRT-Zeitrahmen endet und das Google GKI-Team kennzeichnet die Anfrage als behoben und verweist auf den Respin-Build. Der Respin-Build wird auch auf der Seite Generic Kernel Image (GKI) release builds (GKI-Release-Builds) veröffentlicht.

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 binären GKI-Releases 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 Startblockierungsfehlerkorrekturen, 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 „pro OEM“-Respin-Pfad 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. Ein konkretes Beispiel für dieses Konzept sind schwerwiegende Kernel-Bugs, die bei Netzbetreibertests gefunden werden.

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 erst dann eine Änderung an einem Respin-Build vor, wenn das Problem verstanden und alle Details erfasst wurden. Das ist im Changelog (Commit-Nachricht) zu sehen. Google gibt nicht an, welches Gerät konkret betroffen ist, aber OEMs können die Problembeschreibung und die Lösung jederzeit im Changelog nachlesen.