Releaseprozess für generisches Kernel-Image (GKI)

Auf dieser Seite wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlicher, monatlicher und Out-of-Band-Notfallveröffentlichungen. In diesem Dokument erfahren OEMs, wo sie die GKI abrufen können, und wie sie Out-of-Band-Notfallkorrekturen erhalten. 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 nach der Beendigung des KMI-Programms monatlich veröffentlicht.

GKI-Release für Android 13, 14 und 15

Die folgende Tabelle gilt nur für android13-5.10, android13-5.15 und android14-5.15.

Die folgende Tabelle gilt nur für android14-6.1 und android15-6.6.

Android 12 GKI-Release

Nach Mai 2024 werden die android12-5.10 GKI-Releases vierteljährlich veröffentlicht und Mitte des Monats veröffentlicht. Die folgende Tabelle gilt nur für android12-5.10.

Gültigkeit von GKI-Builds für OEMs

OEMs können eine kürzlich veröffentlichte Android-GKI verwenden. OEMs können GKI-zertifizierte Builds veröffentlichen, solange sie den LTS-Anforderungen im Android Security Bulletin (ASB) entsprechen.

Wöchentliche Entwicklungsversionen

GKI-Binärdateien sind im Rahmen des Self-Service über Android CI verfügbar, sobald Änderungen zusammengeführt wurden. Wöchentliche Builds werden 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.

Monatliche zertifizierte Releases

Die monatlichen GKI-Releases enthalten eine getestete boot.img mit einem von Google eingefügten Zertifikat, das bestätigt, dass die Binärprogramme aus einer bekannten Quellcode-Baseline erstellt wurden.

Jeden Monat wird ein (nicht zertifizierter) monatlicher GKI-Releasekandidat nach dem Stichtag für den Check-in ausgewählt. Dies ist in der Regel der zweite wöchentliche Build dieses Monats. Nachdem der Release-Kandidat für den Monat ausgewählt wurde, werden keine neuen Änderungen in den Release dieses Monats aufgenommen. Während des geschlossenen Zeitraums können nur Fehler behoben werden, die zu einem Testfehler führen. Der Releasekandidat wird einer Qualitätssicherung unterzogen, wie im Abschnitt zur GKI-Qualifikation beschrieben, um sicherzustellen, dass Compliancetests den GSI+GKI-Build mit einem Referenzgerät und Sepien bestanden haben.

Abbildung 1 Zeitplan für die GKI-Veröffentlichung

Notfall-Respin-Verfahren

Ein Respin bezieht sich auf das Zusammenführen, Neukompilieren, erneute Testen und erneute Zertifizierung eines Binärprogramms nach einer öffentlichen Veröffentlichung des GKI-Kernels. In folgenden Fällen können Sie eine erneute PIN-Abfrage einer zertifizierten Binärdatei anfordern:

• So aktualisieren Sie eine Symbolliste.
• Um einen Fehler zu beheben, einschließlich Fehler, die bei der Genehmigung durch das Mobilfunkanbieter-Lab gefunden wurden.
• So fügen Sie einen Anbieter-Hook hinzu.
• Um einen Patch auf ein vorhandenes Element anzuwenden.
• Sicherheitspatch anwenden (nach 6 Monaten)

Sicherheits-Patches werden bis zu sechs Monate nach der Veröffentlichung des Branches automatisch in einen Release-Branch zusammengeführt. Nach Ablauf der sechsmonatigen Frist müssen Sie eine Neubewertung beantragen, um Sicherheits-Patches auf einen Branch anzuwenden.

Richtlinien für Anfragen zur Neuausrichtung

Beachten Sie die folgenden Richtlinien, bevor Sie eine erneute Anpinnen anfordern:

• Neuveröffentlichungen sind nur in Release-Branches zulässig, nachdem eine erste öffentliche Veröffentlichung eines Monatsbuilds erfolgt ist.

• Respin-Anfragen werden nur für einen bestimmten Release-Branch maximal sechs Monate nach der ursprünglichen Veröffentlichung akzeptiert. Nach sechs Monaten können Branches nur noch für Sicherheitspatches neu eingereicht werden, die in einem Android-Sicherheitsbulletin aufgeführt sind.

• Wenn die LTS-Anforderungen, die im Android Security Bulletin (ASB) definiert sind, zu einem nicht konformen Zweig führen, wird der Zweig verworfen. Anfragen zum Respin für eingestellte Branches werden nicht akzeptiert. Das Datum der Einstellung für einen bestimmten GKI-Release-Branch ist in den monatlichen 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 nach dem 1. Mai 2024 nicht mehr für Respin-Builds unterstützt, da der android12-5.10-2023-07-Zweig (5.10.177) nicht den LTS-Anforderungen von ASB-2024-05 entspricht.

• Neuveröffentlichungen sind nur für dringende Fehlerkorrekturen, Aktualisierungen der Symbolliste oder zur Anwendung eines Patches zur Behebung eines Problems mit einer vorhandenen Funktion zulässig.

• Alle Patches, die in den monatlichen Release-Branch aufgenommen werden, müssen bereits in den Haupt-GKI-Entwicklungs-Branch zusammengeführt worden sein. Wenn beispielsweise ein Patch für eine Auflösung von android12-5.10-2022-09 erforderlich ist, muss er bereits mit android12-5.10 zusammengeführt werden.

• Sie müssen Patches aus dem Hauptentwicklungszweig von GKI auswählen und in den monatlichen Release-Zweig hochladen.

• In der Anfrage zur Neubearbeitung müssen Sie der Anfrage eine Priorität (Dringlichkeit) zuweisen. So kann das GKI-Team Partner zeitnah besser unterstützen. Markieren Sie kritische oder zeitkritische Anfragen mit der Priorität P0. Bei P0- und P1-Anfragen müssen Sie auch die Dringlichkeit begründen. In der folgenden Tabelle wird die Zuordnung von Fehlerpriorität und Zeit bis zur Lösung (ESRT) dargestellt:

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

• Sie müssen für jeden Release-Branch einen separaten Respin-Antrag stellen. Wenn beispielsweise sowohl für android12-5.10-2022-08 als auch für android12-5.10-2022-09 ein Respin erforderlich ist, müssen Sie zwei Respin-Anfragen erstellen.

• Nachdem ein Build bereitgestellt und ein Respin-Antrag als behoben markiert wurde, sollten Sie den Respin-Antrag nicht wieder öffnen, um weitere CLs hinzuzufügen. Sie müssen einen neuen Respin-Antrag einreichen, wenn es weitere Patches gibt, die zusammengeführt werden müssen.

• Fügen Sie für jeden in Betracht gezogenen 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 Änderungs-ID der Änderung des Basiszweigs identisch sein.

• Wenn eine Antwort von Ihnen auf eine Anfrage 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) gekennzeichnet.

Einspruch einlegen

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

Abbildung 2. Der Vorgang zum erneuten Anpinnen

So starten Sie den Respin-Vorgang:

1. Füllen Sie das Antragsformular für die GKI-Antwort aus und wenden Sie sich sofort an Ihren Technical Account Manager bei Google. Dieses Formular führt zu einem Fehler bei der GKI-Anfrage zum Ablehnen einer Anfrage. Bugs mit einer Respin-Anfrage sind für Sie (den Antragsteller), das GKI-Team und bestimmte Personen sichtbar, die Sie der CC-Liste des Bugs hinzufügen.
   • Wenn Sie bereits eine Fehlerbehebung haben, sollte der Antrag auf den Patch verweisen, der in AOSP eingereicht wurde, damit Google ihn prüfen kann. Wenn das Einreichen des Patches nicht möglich ist, muss er der Anfrage als Textdatei angehängt werden.
   • Wenn Sie keine Lösung gefunden haben, muss die Anfrage so viele Informationen wie möglich enthalten, einschließlich der Kernel-Versionsnummer und Logs, damit Google bei der Fehlerbehebung helfen kann.
2. Das Google GKI-Team prüft den Antrag und genehmigt ihn oder weist ihn Ihnen zurück, wenn weitere Informationen erforderlich sind.
3. Nachdem eine Fehlerbehebung vereinbart wurde, prüft das Google GKI-Team den Code (CR+2) der Änderung. Mit der Überprüfung beginnt der ESRT-Zeitraum. Das GKI-Team führt die Zusammenführung durch, erstellt die Änderung, testet sie auf Regression und zertifiziert sie.
4. Das Binary wird unter ci.android.com veröffentlicht. Der Zeitrahmen für die schnelle Fehlerbehebung endet und das Google GKI-Team kennzeichnet die Anfrage als behoben und verweist auf den Respin-Build. Der Respin-Build wird auch auf der Release-Seite für allgemeines Kernel-Image (GKI) veröffentlicht.

GKI-Qualifikationen

Build-Artefakte abrufen

Artefakte für alle Releases können unter ci.android.com abgerufen werden.

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

Häufig gestellte Fragen

Hier finden Sie einige häufig gestellte Fragen zum GKI-Veröffentlichungsprozess.

Ist es möglich, eine neue GKI-Binärdatei auf der Grundlage einer bereits veröffentlichten GKI zu erstellen?

Ja, das wird Respin genannt. Der Respin-Vorgang wird unterstützt, solange der veröffentlichte GKI-Build (für den der Respin angefordert wird) den LTS-Anforderungen im Android Security Bulletin (ASB) 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 neuesten Codebasis erstellt?

Nein. Respin-Kernel enthalten nur Patches, die auf den ausgewählten monatlichen zertifizierten Kerneln basieren. Diese Respin-Builds enthalten alle bis zu einem bestimmten Zeitpunkt von OEMs gemeldeten Fehlerkorrekturen, die die Markteinführung verhindern. Diese OEMs verwenden die entsprechende monatliche Basisversion. Im folgenden Beispiel sehen Sie, wie diese Art von Szenario abläuft.

• OEM1 und OEM2 entscheiden sich, die GKI-Binärversion ab November 2021 zu verwenden.
• OEM1 und OEM2 finden Probleme, für die Patches erforderlich sind. Diese Patches können unterschiedlich oder gleich sein.
• Die Respin-Versionen über der Binärdatei vom November 2021 enthalten Fehlerkorrekturen für Startblockierungen, die sowohl von OEM1 als auch von OEM2 während des Respin-Zeitfensters gemeldet wurden.
• Die in der zweiten Aufzählung genannten Probleme sind auch in den nachfolgenden monatlichen GKI-Releases enthalten.

Die Oktober-Respin 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 eingeht, und testet die Änderungen mit der gesamten verfügbaren Hardware, 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 Respin-Builds besteht darin, dass alle Geräte, die dieselbe Release-Basis verwenden, davon profitieren, insbesondere wenn die gefundenen Fehler allgemeingültig sind und für alle Nutzer gelten. Kern-Kernel-Fehler, die bei Tests durch Mobilfunkanbieter gefunden werden, sind ein konkretes Beispiel für dieses Konzept.

Gibt es Situationen, in denen Google bestimmte Informationen zu OEM-Patches und Problemszenarien zur Verfügung stellt, 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 Problem verstanden und alle Details erfasst wurden. Dies wird im Änderungslog (Commit-Nachricht) angezeigt. Google gibt nicht an, welches Gerät betroffen ist. OEMs finden die Problembeschreibung und Lösung jedoch immer im Änderungslog.