Auf dieser Seite wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlicher, monatlicher und außerplanmäßiger 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 dem KMI-Freeze 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.
| Monatlich zertifizierte GKI-Builds | Check-in-Anmeldefrist | Datum der Verfügbarkeit der GKI-Vorabdaten | Ist das in Ordnung? |
|---|---|---|---|
| November | 11. November 2024 | 27. November 2024 | Ja |
| Januar | 14. Januar 2025 | 31. Januar 2025 | Ja |
| März | 14. März 2025 | 31. März 2025 | Ja |
Die folgende Tabelle gilt nur für android14-6.1 und android15-6.6.
| Monatlich zertifizierte GKI-Builds | Check-in-Anmeldefrist | Datum der Verfügbarkeit der GKI-Vorabdaten | Ist das in Ordnung? |
|---|---|---|---|
| Oktober | 1. Oktober 2024 | 14. Oktober 2024 | Ja |
| November | 1. November 2024 | 15. November 2024 | Ja |
| Dezember | 2. Dezember 2024 | 16. Dezember 2024 | Ja |
| Januar | 6. Januar 2025 | 22. Januar 2025 | Ja |
GKI-Release von Android 12
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.
| Monatlich zertifizierte GKI-Builds | Check-in-Anmeldefrist | Datum der Verfügbarkeit der GKI-Vorabdaten | Ist das in Ordnung? |
|---|---|---|---|
| November | 1. November 2024 | 15. November 2024 | Ja |
| Februar | 3. Februar 2025 | 17. Februar 2025 | Ja |
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
Releases werden mit Cuttlefish getestet, um sicherzustellen, dass sie einen Mindestqualitätsstandard erfüllen.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 Baseline 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.
Nach dem Check-in-Abschlussdatum, in der Regel der zweite Wochenbuild des Monats, wird jeden Monat ein monatlicher Release-Kandidat (nicht zertifiziert) für Google Kalender ausgewählt. 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 Release-Kandidat wird einer Qualitätssicherung unterzogen, wie im Abschnitt zur GKI-Qualifizierung beschrieben, um sicherzustellen, dass die Compliance-Tests für den GSI+GKI-Build mit einem Referenzgerät und Cuttlefish bestanden werden.
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. Sie können einen Respin eines zertifizierten Binärcodes in den folgenden Fällen anfordern:
- So aktualisieren Sie eine Symbolliste:
- Um einen Fehler zu beheben, einschließlich Fehler, die bei der Genehmigung durch das Mobilfunkanbieter-Lab gefunden wurden.
- Anbieter-Hook hinzufügen
- 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 nochmalige Überprüfung beantragen:
Neuveröffentlichungen sind nur in Release-Branches zulässig, nachdem eine erste öffentliche Veröffentlichung eines monatlichen Builds 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 aufgrund von Sicherheitspatches, die in einem Android-Sicherheitsbulletin aufgeführt sind, noch einmal eingereicht werden.
Wenn der Release wegen Nichteinhaltung der LTS-Anforderungen, die im Android Security Bulletin (ASB) definiert sind, nicht konform ist, wird er eingestellt. 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 derandroid12-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 Neuauslieferung von
android12-5.10-2022-09erforderlich ist, muss er bereits inandroid12-5.10zusammengeführt worden sein.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 außerdem 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 einreichen. Wenn beispielsweise sowohl für
android12-5.10-2022-08als auch fürandroid12-5.10-2022-09ein 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 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 Änderungs-ID der Änderung des Basiszweigs identisch sein.
Wenn eine Antwort 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 innerhalb von zwei Wochen nicht antworten, wird der Fehler als Nicht behoben (veraltet) gekennzeichnet.
Einspruch einlegen
Das folgende Diagramm zeigt den Respin-Prozess. Der Prozess beginnt, wenn der OEM-Partner (Sie) die Respin-Anfrage einreicht.
Abbildung 2. Ablehnung
So starten Sie den Respin-Vorgang:
- 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 haben, muss die Anfrage so viele Informationen wie möglich enthalten, einschließlich der Kernelversion und Protokollen, damit Google Ihnen bei der Fehlerbehebung helfen kann.
- Das Google GKI-Team prüft den Antrag und genehmigt ihn oder weist ihn Ihnen zurück, wenn weitere Informationen erforderlich sind.
- 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.
- Das Binärprogramm wird unter ci.android.com veröffentlicht. Der Zeitrahmen für die Erstreaktion 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 Release-Builds für generisches Kernel-Image (GKI) veröffentlicht.
GKI-Qualifikationen
| Arten von GKI-Builds | Durchsetzung der Qualitätsstandards | Notes |
|---|---|---|
| Wöchentlich | Tests mit Sepia
|
|
| Monatlich (zertifiziert) | Tests mit Sepia
|
|
| Respins (zertifiziert) | Tests mit Sepia
|
|
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 als Respin bezeichnet. 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
Wenn Sie das Beispiel reproduzieren möchten, laden Sie manifest_$id.xml herunter und führen Sie den folgenden Befehl aus:
repo init -u https://android.googlesource.com/kernel/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_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 Fehlerkorrekturen, die bis zu einem bestimmten Zeitpunkt von OEMs gemeldet wurden, die die entsprechende monatliche Basisversion verwenden. Im folgenden Beispiel wird veranschaulicht, wie ein solches 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 identisch 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 die Lösung jedoch immer im Änderungslog.