In diesem Dokument wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlicher, monatlicher und Out-of-Band-Notfallveröffentlichungen. Mit diesem Dokument möchten wir OEMs eine Richtlinie zur Verfügung stellen, wo sie die GKI finden und wie sie Out-of-Band-Notfallreparaturen verfahren. OEMs können auch den GKI-Entwicklungsleitfaden verwenden, um zu erfahren, wie sie zusammen mit dem Android-Kernel-Team den GKI-Kernel für ihre Produkte optimieren können.
GKI-Releaserhythmus
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-6.1.
| Monatlich zertifizierte GKI-Builds | Annahmeschluss für Check-in | Datum, an dem das GKI-Vorabladen bereit ist | Bestätigt? |
|---|---|---|---|
| Oktober | 14. Oktober 2022 | 31. Oktober 2022 | Ja |
| November | 14. November 2022 | 30. November 2022 | Ja |
| Dezember | 9. Dezember 2022 | 21. Dezember 2022 | Ja |
| Januar | 17. Januar 2023 | 31. Januar 2023 | Ja |
| Februar | 15. Februar 2023 | 28. Februar 2023 | Ja |
| März | 15. März 2023 | 31. März 2023 | Ja |
| April | 13. April 2023 | 28. April 2023 | Ja |
| Mai | 17. Mai 2023 | 31. Mai 2023 | Ja |
| Juni | 15. Juni 2023 | 30. Juni 2023 | Ja |
| Juli | 18. Juli 2023 | 31. Juli 2023 | Ja |
| August | 16. August 2023 | 31. August 2023 | Ja |
| September | 14. September 2023 | 29. September 2023 | Ja |
| Oktober | 18. Oktober 2023 | 31. Oktober 2023 | Ja |
| November | 10. November 2023 | 30. November 2023 | Ja |
| Dezember | 7. Dezember 2023 | 22. Dezember 2023 | Ja |
| Januar | 16. Januar 2024 | 31. Januar 2024 | Ja |
| Februar | 13. Februar 2024 | 29. Februar 2024 | Ja |
| März | 13. März 2024 | 29. März 2024 | Ja |
| April | 16. April 2024 | 30. April 2024 | Ja |
| Mai | 14. Mai 2024 | 31. Mai 2024 | Ja |
| Juni | 12. Juni 2024 | 28. Juni 2024 | Ja |
| Juli | 16. Juli 2024 | 31. Juli 2024 | Ja |
| August | 15. August 2024 | 30. August 2024 | Ja |
| September | 17. September 2024 | 30. September 2024 | Ja |
| Oktober | 15. Oktober 2024 | 31. Oktober 2024 | Ja |
| November | 11. November 2024 | 27. November 2024 | Ja |
| Dezember | 6. Dezember 2024 | 23. Dezember 2024 | Ja |
Ab Januar 2024 werden die monatlichen Releases von android14-5.15 gemäß dem in der folgenden Tabelle angegebenen monatlichen Rhythmus fortgesetzt.
Ab Juli 2024 folgt der Veröffentlichungsrhythmus von android15-6.6.
| Monatlich zertifizierte GKI-Builds | Annahmeschluss für Check-in | Datum, an dem das GKI-Vorabladen bereit ist | Bestätigt? |
|---|---|---|---|
| Januar | 16. Januar 2024 | 31. Januar 2024 | Ja |
| Februar | 13. Februar 2024 | 29. Februar 2024 | Ja |
| März | 4. März 2024 | 15. März 2024 | Ja |
| April | 1. April 2024 | 17. April 2024 | Ja |
| Mai | 1. Mai 2024 | 17. Mai 2024 | Ja |
| Juni | 3. Juni 2024 | 17. Juni 2024 | Ja |
| Juli | 1. Juli 2024 | 15. Juli 2024 | Ja |
| August | 1. August 2024 | 16. August 2024 | Ja |
| September | 2. September 2024 | 16. September 2024 | Ja |
| Oktober | 1. Oktober 2024 | 14. Oktober 2024 | Ja |
| November | 1. November 2024 | 15. November 2024 | Ja |
| Dezember | 2. Dezember 2024 | 16. Dezember 2024 | Ja |
GKI-Release für Android 12
Nach Mai 2024 werden die GKI-Releases android12-5.10 im vierteljährlichen Rhythmus und im Laufe des Monats veröffentlicht.
Die folgende Tabelle gilt nur für android12-5.10.
| Monatlich zertifizierte GKI-Builds | Annahmeschluss für Check-in | Datum, an dem das GKI-Vorabladen bereit ist | Bestätigt? |
|---|---|---|---|
| Juli | 3. Juli 2023 | 14. Juli 2023 | Ja |
| September | 1. September 2023 | 15. September 2023 | Ja |
| November | 3. November 2023 | 17. November 2023 | Ja |
| Januar | 5. Januar 2024 | 19. Januar 2024 | Ja |
| März | 4. März 2024 | 15. März 2024 | Ja |
| Mai | 1. Mai 2024 | 17. Mai 2024 | Ja |
| August | 1. August 2024 | 16. August 2024 | Ja |
| November | 1. November 2024 | 15. November 2024 | Ja |
| Februar | 3. Februar 2025 | 17. Februar 2025 | Ja |
GKI-Build-Gültigkeit für OEMs
OEMs können eine vor Kurzem veröffentlichte Android-KI nutzen. OEMs können GKI-zertifizierte Builds verwenden, sofern sie die LTS-Anforderungen im Android Security Bulletin (ASB) erfüllen.
Wöchentliche Entwicklungs-Releases
Releases werden mit Tintenfisch getestet, um sicherzustellen, dass sie die Mindestqualitätsanforderungen erfüllen.GKI-Binärdateien können von ci.android.com selbst verwaltet werden, wenn Änderungen zusammengeführt werden. 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
Monatliche GKI-Releases enthalten eine getestete boot.img mit einem von Google eingefügten Zertifikat, das bestätigt, dass die Binärdateien aus einer bekannten Quellcode-Referenz erstellt wurden.
Jeden Monat wird ein (nicht zertifizierter) monatlicher GKI-Releasekandidat nach dem Fälligkeitstermin für den Check-in ausgewählt. Das ist in der Regel der zweite wöchentliche Build dieses Monats. Nachdem der Kandidat für die monatliche Version ausgewählt wurde, werden neue Änderungen nicht in das Release dieses Monats übernommen. Während des geschlossenen Zeitfensters können nur Fehlerbehebungen für 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: GKI-Release-Zeitplan
Notfall-Respin-Prozess
respin bezieht sich auf den Vorgang, bei dem eine Binärdatei nach einem öffentlichen Release des GKI-Kernels wieder zusammengeführt, neu erstellt, noch einmal getestet und neu zertifizieren wird. 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 der Fehler, die bei der Genehmigung durch das Carrier Lab gefunden wurden.
- So fügen Sie einen Anbieter-Hook hinzu.
- Patch auf ein vorhandenes Feature anwenden.
- Anwendung eines Sicherheitspatchs (nach 6 Monaten)
Sicherheitspatches werden automatisch bis zu sechs Monate nach der Veröffentlichung des Zweigs in einem Release-Zweig zusammengeführt. Nach Ablauf der sechsmonatigen Frist müssen Sie eine neue PIN anfordern, um Sicherheitspatches auf einen Zweig anzuwenden.
Beachten Sie die folgenden Richtlinien, bevor Sie eine erneute Anpinnen anfordern:
Respins sind nur in Release-Zweigen zulässig, nachdem ein erster öffentlicher Release eines monatlichen Builds veröffentlicht wurde.
Respin-Anfragen werden nur für einen bestimmten Release-Zweig maximal sechs Monate nach dem ersten öffentlichen Release akzeptiert. Nach sechs Monaten können Zweige nur noch für Sicherheitspatches neu angepinnt 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. Respin-Anfragen für verworfene Branches werden nicht akzeptiert. Das Einstellungsdatum für einen bestimmten GKI-Release-Zweig finden Sie in den monatlichen GKI-Versionshinweisen unter Releases. Für die zukünftige Planung werden die Anforderungen für den Langzeitsupport jedes Jahr im Mai und November aktualisiert. Der
android12-5.10-2023-07-Zweig (5.10.177) wird nach dem 1. Mai 2024 für Respins nicht mehr unterstützt, da derandroid12-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 das Anwenden eines Patches zur Korrektur eines vorhandenen Features anwendbar.
Alle Patches, die in den Zweig der monatlichen Release-Version aufgenommen werden, müssen bereits mit dem GKI-Hauptentwicklungszweig zusammengeführt worden sein. Wenn beispielsweise ein Patch für eine Auflösung von
android12-5.10-2022-09erforderlich ist, muss er bereits mitandroid12-5.10zusammengeführt werden.Sie müssen Patches aus dem GKI-Hauptentwicklungszweig auswählen und in den Zweig mit monatlichen Releases hochladen.
In der „respin“-Anfrage müssen Sie ihr eine Priorität (Dringlichkeit) zuweisen. Mit dieser Priorität kann das GKI-Team Partner besser zeitnah unterstützen. Geben Sie bei kritischen oder zeitkritischen Anfragen die Priorität P0 an. Bei P0- und P1-Anfragen müssen Sie auch die Dringlichkeit begründen. Die folgende Tabelle enthält eine Zuordnung von Fehlerpriorität und Zeit zur Behebung (Time to Resolution, ESRT):
Priorität ESRT P0 2 Werktage P1 5 Werktage P2 10 Werktage P3 15 Geschäftstage
Du musst pro Release-Zweig eine separate Respin-Anfrage senden. Wenn beispielsweise eine Respin-Anfrage sowohl für
android12-5.10-2022-08als auch fürandroid12-5.10-2022-09erforderlich ist, müssen Sie zwei Respin-Anfragen erstellen.Nachdem ein Build bereitgestellt und eine Respin-Anfrage als behoben markiert wurde, sollten Sie die Respin-Anfrage nicht noch einmal öffnen, um zusätzliche CLs hinzuzufügen. Wenn weitere Patches zusammengeführt werden müssen, müssen Sie eine neue „respin“-Anfrage senden.
Fügen Sie für jeden in Betracht gezogenen CL die folgenden Tags hinzu. Ohne diese Informationen wird der Fortschritt bei der Anfrage für die Auflösung blockiert.
Bug: Die Fehler-ID muss der Commit-Nachricht für jede Änderungsliste hinzugefügt werden.Change-Id: muss mit der Änderungs-ID der Basiszweigänderung identisch sein.
Wenn eine Respin-Anfrage Ihre Antwort erfordert und Sie nicht innerhalb von drei Werktagen antworten, wird die Priorität um eine Stufe herabgestuft (z. B. wird P0 auf P1 herabgestuft). Wenn Sie zwei Wochen lang nicht reagieren, wird der Fehler als Won't Fix (Obsolete) gekennzeichnet.
Anfrage zur erneuten Überprüfung senden
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 Vorgang zum erneuten Anpinnen:
- Füllen Sie das Antragsformular für GKI Respin aus und wenden Sie sich umgehend an Ihren Technical Account Manager bei Google. Dieses Formular erstellt einen Fehler in der GKI-Respin-Anfrage. Fehler in Respin-Anfragen sind für Sie (den Anforderer), das GKI-Team und bestimmte Personen sichtbar, die Sie der CC-Liste des Programmfehlers hinzufügen.
- Wenn Sie bereits eine Lösung haben, sollte die Anfrage auf die Patchanfrage in AOSP verweisen, damit Google sie prüfen kann. Wenn das Senden des Patches nicht möglich ist, muss der Patch als Textdatei an die Anfrage 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.
- Das Google GKI-Team prüft die Anfrage und genehmigt sie oder weist sie Ihnen zu, falls weitere Informationen benötigt werden.
- Nachdem eine Lösung vereinbart wurde, überprüft das Google-GKI-Team die Änderung (CR+2). Die Überprüfung beginnt mit dem ESRT-Zeitraum. Das GKI-Team führt die Änderungen zusammen, erstellt sie, testet sie auf Regression und zertifiziert die Änderung.
- Die Binärdatei wird für ci.android.com veröffentlicht. Der ESRT-Zeitraum endet und das Google-KI-Team markiert die Anfrage als korrigiert 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
| Arten von GKI-Builds | Durchsetzung der Qualitätsstandards | Notizen |
|---|---|---|
| Wöchentlich | Tintenfischtests
|
|
| Monatlich (zertifiziert) | Tintenfischtests
|
|
| Respins (zertifiziert) | Tintenfischtests
|
|
Build-Artefakte erhalten
Die Artefakte für alle Releases sind unter ci.android.com verfügbar.
Weitere Informationen zum CI, einschließlich der Testergebnisse, finden Sie im Dashboard Android Continuous Integration.
Häufig gestellte Fragen
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-Prozess wird unterstützt, solange der veröffentlichte GKI-Build, bei dem die Respin angefordert wird, den Anforderungen für LTS im Android Security Bulletin (ASB) entspricht.
Ist es möglich, GKI-Binärdateien zu reproduzieren?
Ja, anhand des Beispiels unten.
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/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 die Kopie des GKI-Artefakts von out/.../dist abrufen.
Wurde die GKI-Binärdatei (einschließlich des Notfall-Spin-Patches) auf der neuesten Codebasis erstellt?
Nein. Respins enthalten nur Patches, die auf den monatlich zertifizierten Kerneln aufgestellt sind, die ausgewählt wurden. Diese Respins enthalten alle Fehlerkorrekturen, die den Start blockieren und die bis zu einem bestimmten Zeitpunkt von OEMs gemeldet wurden, die den entsprechenden monatlichen Basisrelease verwenden. Im folgenden Beispiel sehen Sie, wie diese Art von Szenario abläuft.
- OEM1 und OEM2 entscheiden sich ab November 2021 für den Binär-Release von GKI.
- OEM1 und OEM2 finden Probleme, die Patches für den Support erfordern. Diese Patches können unterschiedlich oder gleich sein.
- Für die Respins, die über das Binärprogramm vom November 2021 hinausgehen, wurden während des Respin-Fensters sowohl von OEM1 als auch von OEM2 gemeldete Korrekturen für Startblockierungen gemeldet, aber nicht mehr.
- Die im zweiten Punkt genannten Probleme sind auch in den nachfolgenden monatlichen GKI-Releases enthalten.
In der Oktober-Antwort wurden alle OEM-Patches eingereicht. Andere OEM-Patches betreffen uns jedoch, da sie nicht speziell mit unseren Produkten getestet wurden. Ist es möglich, nur unseren Patch hinzuzufügen?
Das ist nicht möglich. Ein Respin-Pfad pro OEM ist derzeit 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 OEM, Gerät oder Modell betrifft, kann es dafür sorgen, dass der durch die Änderung hinzugefügte Code nur auf dem betroffenen Gerät, Modell oder Modell ausgeführt wird.
Der große Vorteil von einheitlichen Respins besteht darin, dass jedes Gerät, das dieselbe Release-Basis verwendet, voneinander profitiert, insbesondere wenn die gefundenen Fehler allgemein und für alle Nutzer anwendbar sind. Kern-Kernel-Fehler, die bei Carrier-Tests gefunden wurden, sind ein spezifisches Beispiel für dieses Konzept.
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 mit ihren Produkten bewerten können?
Google fügt einem Repin-Build niemals Änderungen hinzu, bis das Problem verstanden und alle Details erfasst wurden. Dies ist im Änderungsprotokoll (Commit-Nachricht) zu sehen. Google gibt nicht preis, um welches Gerät es sich handelt, aber OEMs finden die Problembeschreibung und die Lösung jederzeit im Änderungsprotokoll.