In diesem Dokument wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlicher, monatlicher und Out-of-Band-Notfallversionen. Das Ziel dieses Dokuments besteht darin, OEMs eine Richtlinie dafür zu geben, wo sie das GKI abholen können, sowie den Prozess für Out-of-Band-Notfallkorrekturen. OEMs können auch den GKI-Entwicklungsleitfaden 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-Veröffentlichungsrhythmus
GKI wird im monatlichen Rhythmus nach dem KMI-Einfrieren veröffentlicht.
GKI-Version für Android 13 und 14
Die folgende Tabelle gilt nur für android13-5.10 , android13-5.15 und android14-6.1 .
| Monatlich von GKI zertifizierte Builds | Check-in-Datum | GKI-Vorladebereitschaftsdatum | 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 |
| Marsch | 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 |
| Marsch | 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 wir die monatlichen Veröffentlichungen von android14-5.15 gemäß dem in der folgenden Tabelle angegebenen monatlichen Rhythmus wieder aufnehmen.
| Monatlich von GKI zertifizierte Builds | Check-in-Datum | GKI-Vorladebereitschaftsdatum | Bestätigt? |
|---|---|---|---|
| Januar | 16. Januar 2024 | 31. Januar 2024 | Ja |
| Februar | 13. Februar 2024 | 29. Februar 2024 | Ja |
| Marsch | 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 |
Android 12 GKI-Release
Nach Mai 2023 werden die GKI-Releases android12-5.10 alle zwei Monate veröffentlicht und zur Monatsmitte veröffentlicht. Die folgende Tabelle gilt nur für android12-5.10 .
| Monatlich von GKI zertifizierte Builds | Check-in-Datum | GKI-Vorladebereitschaftsdatum | 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 |
| Marsch | 4. März 2024 | 15. März 2024 | Ja |
| Mai | 1. Mai 2024 | 17. Mai 2024 | Ja |
GKI-Build-Gültigkeit für OEMs
OEMs können ein kürzlich veröffentlichtes Android GKI verwenden. OEMs können mit GKI-zertifizierten Builds starten, solange sie den LTS-Anforderungen im Android Security Bulletin (ASB) entsprechen.
Wöchentliche Entwicklungsversionen
Veröffentlichungen werden mit Tintenfischen getestet, um sicherzustellen, dass sie eine Mindestqualitätsgrenze erfüllen.GKI-Binärdateien stehen zur Selbstbedienung auf ci.android.com zur Verfügung, wenn Änderungen zusammengeführt werden. Wöchentliche Builds werden nicht zertifiziert, können jedoch als Grundlage für Entwicklung und Tests verwendet werden. Wöchentliche Builds können nicht für Produktionsgeräte-Builds für Endbenutzer verwendet werden.
Monatlich zertifizierte Veröffentlichungen
Monatliche GKI-Versionen enthalten eine getestete boot.img , die ein von Google eingefügtes Zertifikat enthält, um zu bestätigen, dass die Binärdateien auf einer bekannten Quellcode-Basislinie erstellt wurden.
Jeden Monat wird ein monatlicher GKI-Release-Kandidat (nicht zertifiziert) nach dem Check-in-Cut-Off-Datum ausgewählt, bei dem es sich normalerweise um den zweiten wöchentlichen Build dieses Monats handelt. Nachdem der Kandidat für die monatliche Veröffentlichung ausgewählt wurde, werden neue Änderungen nicht mehr in die Veröffentlichung dieses Monats übernommen. Während des Zeitraums des geschlossenen Fensters können nur Fehlerbehebungen für Fehler behoben werden, die zu Testfehlern führen. Der Release Candidate durchläuft eine Qualitätssicherung – wie im Abschnitt zur GKI-Qualifizierung beschrieben –, um sicherzustellen, dass die Konformitätstests für GSI+GKI-Builds mit einem Referenzgerät sowie Tintenfisch bestanden werden.
Abbildung 1. Zeitleiste der GKI-Veröffentlichung
Notfall-Respin-Prozess
Ein Respin bezieht sich auf den Prozess des erneuten Zusammenführens, Neuerstellens, erneuten Testens und erneuten Zertifizierens einer Binärdatei nach einer öffentlichen Veröffentlichung des GKI-Kernels . Sie können unter folgenden Umständen einen Respin einer zertifizierten Binärdatei anfordern:
- Um eine Symbolliste zu aktualisieren.
- So wenden Sie einen Fix für einen Fehler an, einschließlich Fehlern, die bei der Genehmigung durch das Carrier-Labor gefunden wurden.
- So fügen Sie einen Anbieter-Hook hinzu.
- So wenden Sie einen Patch auf eine vorhandene Funktion an.
- Um einen Sicherheitspatch anzuwenden (nach 6 Monaten).
Sicherheitspatches werden bis zu 6 Monate nach der Veröffentlichung des Zweigs automatisch in einen Release-Zweig integriert. Nach Ablauf der 6-Monats-Frist müssen Sie einen Respin anfordern, um Sicherheitspatches auf eine Zweigstelle anzuwenden.
Beachten Sie die folgenden Richtlinien, bevor Sie einen Respin anfordern:
Respins sind nur in Release-Zweigen zulässig, nachdem eine erste öffentliche Veröffentlichung eines monatlichen Builds veröffentlicht wurde.
Respin-Anfragen werden maximal sechs Monate nach der ersten öffentlichen Veröffentlichung nur für einen bestimmten Release-Zweig akzeptiert. Nach sechs Monaten haben Zweigstellen nur Anspruch auf Respin für Sicherheitspatches, die in einem Android-Sicherheitsbulletin aufgeführt sind.
Wenn die im Android Security Bulletin (ASB) definierten LTS-Anforderungen dazu führen, dass der Zweig nicht konform ist, wird der Zweig nicht mehr unterstützt. Respin-Anfragen für veraltete Zweige werden nicht akzeptiert. Das Verfallsdatum für einen bestimmten GKI-Release-Zweig 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. Beispielsweise wird der Zweig
android12-5.10-2023-07“ (5.10.177) für Respins nach dem 1. Mai 2024 nicht mehr unterstützt, da der Zweig „android12-5.10-2023-07“ (5.10.177) nicht mit dem übereinstimmt LTS-Anforderungen von ASB-2024-05.Respins gelten nur für dringende Fehlerbehebungen, Aktualisierungen der Symbolliste oder zum Anwenden eines Patches zur Behebung einer vorhandenen Funktion.
Alle Patches, die in den monatlichen Release-Zweig gelangen, müssen bereits in den Haupt-GKI-Entwicklungszweig eingebunden sein. Wenn beispielsweise ein Patch für einen Respin von
android12-5.10-2022-09erforderlich ist, muss dieser bereits inandroid12-5.10eingebunden sein.Sie müssen Patches aus dem Haupt-GKI-Entwicklungszweig auswählen und den Patch in den monatlichen Release-Zweig hochladen.
In der Respin-Anfrage 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 für kritische oder zeitkritische Anfragen die Priorität als P0 . Bei P0- und P1-Anfragen müssen Sie zusätzlich die Dringlichkeit begründen. Die folgende Tabelle bietet eine Zuordnung der Fehlerpriorität und der Zeit bis zur Lösung (ESRT):
Priorität ESRT P0 2 Werktage P1 5 Werktage P2 10 Werktage P3 15 Werktage
Sie müssen pro Release-Zweig eine separate Respin-Anfrage einreichen. Wenn beispielsweise ein Respin sowohl für
android12-5.10-2022-08als auch fürandroid12-5.10-2022-09benötigt wird, 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 erneut öffnen, um weitere CLs hinzuzufügen. Sie müssen eine neue Respin-Anfrage einreichen, wenn zusätzliche Patches zusammengeführt werden müssen.
Fügen Sie für jeden betrachteten CL die folgenden Tags hinzu. Ohne diese Informationen wird der Fortschritt der Respin-Anfrage blockiert.
-
Bug: Die Fehler-ID muss der Commit-Nachricht für jeden CL hinzugefügt werden. -
Change-Id: muss mit der Change-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. P0 wird auf P1 herabgestuft). Wenn Sie zwei Wochen lang nicht antworten, wird der Fehler als „Kann nicht behoben (veraltet)“ markiert.
Senden Sie eine Respin-Anfrage
Das folgende Diagramm zeigt den Respin-Prozess. Der Prozess beginnt, wenn der OEM-Partner (Sie) die Respin-Anfrage übermittelt.
Abbildung 2. Der Respin-Prozess
Um in den Respin-Prozess einzusteigen:
- Füllen Sie das GKI Respin-Anfrageformular aus . und wenden Sie sich umgehend an Ihren technischen Account Manager bei Google. Dieses Formular erzeugt einen GKI-Respin-Anfragefehler. Fehler bei Respin-Anfragen sind für Sie (den Anforderer), das GKI-Team und bestimmte Personen sichtbar, die Sie der CC-Liste des Fehlers hinzufügen.
- Wenn Sie bereits über einen Fix verfügen, sollte die Anfrage auf die Patch-Übermittlung in AOSP verweisen, damit Google ihn überprüfen kann. Wenn das Einreichen des Patches nicht möglich ist, muss der Patch als Textdatei an die Anfrage angehängt werden.
- Wenn Sie keinen Fix haben, muss die Anfrage so viele Informationen wie möglich enthalten, einschließlich der Kernel-Versionsnummer und Protokolle, damit Google bei der Behebung des Problems helfen kann.
- Das Google GKI-Team prüft die Anfrage und genehmigt sie oder weist sie Ihnen zurück, wenn weitere Informationen benötigt werden.
- Nachdem eine Lösung vereinbart wurde, überprüft das Google GKI-Team die Änderung im Code (CR+2). Mit der Überprüfung beginnt der ESRT-Zeitrahmen. Das GKI-Team führt Zusammenführungen durch, erstellt, testet die Regression und zertifiziert die Änderung.
- Die Binärdatei wird auf ci.android.com veröffentlicht. Der ESRT-Zeitrahmen endet und das Google GKI-Team markiert die Anfrage als behoben und verweist auf den Respin-Build. Der Respin-Build wird auch auf der Generic Kernel Image (GKI)-Release-Builds-Seite veröffentlicht.
GKI-Qualifikationen
| Arten von GKI-Builds | Qualitätsdurchsetzung | Anmerkungen |
|---|---|---|
| Wöchentlich | Tintenfischtest
|
|
| Monatlich (zertifiziert) | Tintenfischtest
| |
| Respins (zertifiziert) | Tintenfischtest
|
|
Wo man Build-Artefakte erhält
Artefakte für alle Veröffentlichungen können unter ci.android.com bezogen werden.
Weitere Informationen zum CI, einschließlich der Testergebnisse, finden Sie im Android Continuous Integration- Dashboard.
FAQs
Ist es möglich, eine neue GKI-Binärdatei basierend auf einem bereits veröffentlichten GKI zu erstellen?
Ja, dies wird als Respin bezeichnet. Der Respin-Prozess wird unterstützt, solange der veröffentlichte GKI-Build (auf dem der Respin angefordert wird) den LTS-Anforderungen im Android Security Bulletin (ASB) entspricht.
Ist es möglich, GKI-Binärdateien zu reproduzieren?
Ja, beziehen Sie sich auf das Beispiel unten.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Um das Beispiel zu reproduzieren, 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 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 zusätzlich zu den ausgewählten monatlich zertifizierten Kerneln verfügbar sind. Diese Respins enthalten alle Fehlerbehebungen, die den Start blockieren, bis zu einem bestimmten Zeitpunkt von OEMs, die die entsprechende monatliche Basisversion verwenden. Sehen Sie sich das folgende Beispiel an, wie ein solches Szenario abläuft.
- OEM1 und OEM2 entscheiden sich für die Nutzung der GKI-Binärversion ab November 2021.
- OEM1 und OEM2 finden Probleme, für deren Support Patches erforderlich sind. Diese Patches können unterschiedlich oder gleich sein.
- Die Respins über der Binärdatei vom November 2021 weisen Startblockierungskorrekturen auf, die sowohl von OEM1 als auch von OEM2 während des Respin-Fensters gemeldet wurden, mehr jedoch nicht.
- Die im zweiten Aufzählungspunkt erwähnten Probleme sind auch in nachfolgenden monatlichen GKI-Veröffentlichungen enthalten.
Beim Respin im Oktober sind alle vom OEM eingereichten Patches enthalten, 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 derzeit nicht skalierbar. Stattdessen prüft das GKI-Team jede einzelne Änderung, die in Respin-Builds einfließt, 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/ein Modell ist, kann das GKI-Team sicherstellen, dass der durch die Änderung hinzugefügte Code nur auf dem betroffenen Gerät/Modell/der betroffenen SKU ausgeführt wird.
Der Hauptvorteil von Unified Respins besteht darin, dass alle Geräte, die dieselbe Release-Basis verwenden, voneinander profitieren, insbesondere wenn die entdeckten Fehler allgemeiner Natur sind und auf alle Benutzer anwendbar sind. Ein konkretes Beispiel für dieses Konzept sind Kernel-Bugs, die bei Carrier-Tests gefunden wurden.
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 ihre Produkte bewerten können?
Google wird niemals eine Änderung an einem Respin-Build vornehmen, bis das Problem verstanden und alle Details erfasst wurden. Dies ist im Changelog (Commit-Nachricht) zu sehen. Google gibt nicht bekannt, um welches konkrete Gerät es sich handelt, aber OEMs können die Problembeschreibung und Lösung jederzeit im Änderungsprotokoll finden.