In diesem Dokument wird beschrieben, wie GKI veröffentlicht wird, einschließlich wöchentlich, monatlich und nach außen. von Band-Notfallveröffentlichungen. Mit diesem Dokument möchten wir OEMs Leitfaden dazu, wo Google Workspace erworben werden kann und wie das Out-of-Band-Verfahren abläuft im Notfall behoben werden. OEMs können auch den GKI-Entwicklungsleitfaden verwenden. um mehr darüber zu erfahren, wie sie gemeinsam mit dem Android Kernel-Team den GKI-Kernel für ihre Produkte.
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 setzen wir die monatlichen Releases von android14-5.15 fort
gemäß dem angegebenen monatlichen Rhythmus, der in der Tabelle unten angegeben ist.
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 finden die GKI-Releases für 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 mit GKI-zertifizierte Builds, die den LTS-Anforderungen im Android-Sicherheitsbulletin (ASB):
Wöchentliche Entwicklungsreleases
Releases werden mit Tintenfisch getestet damit sie einen Mindestwert für die Qualität erreichen.GKI-Binärprogramme sind unter ci.android.com eigenständig verfügbar. wenn Änderungen zusammengeführt werden. Wöchentliche Builds sind nicht zertifiziert, können aber als für Entwicklung und Tests. Wöchentliche Builds können nicht verwendet werden für Geräte-Builds für Endnutzer in der Produktionsumgebung.
Monatliche zertifizierte Releases
Monatliche GKI-Releases enthalten eine getestete boot.img mit einem
Zertifikat eingefügt, um zu bestätigen, dass die Binärdateien aus einer bekannten Quelle erstellt wurden
Code-Basiscode.
Jeden Monat wird ein Kandidat für die monatliche GKI-Version (nicht zertifiziert) ausgewählt nach dem Fälligkeitsdatum des Check-ins, in der Regel der zweite wöchentliche Build diesen Monat. Nachdem der Kandidat für die monatliche Version ausgewählt wurde, neu werden in der Version dieses Monats nicht übernommen. Während des geschlossenen Zeitfensters behoben werden, können nur Fehler behoben werden, die zu einem Testfehler führen. Die Releasekandidat einer Qualitätssicherung unterzogen wird, wie in der GKI beschrieben. im Abschnitt zur Qualifizierung, um sicherzustellen, dass die Compliance-Tests bestanden werden. GSI+GKI-Build mit einem Referenzgerät und Tintenfisch
Abbildung 1: GKI-Release-Zeitplan
Notfall-Respin-Prozess
Erneutes Erstellen bezieht sich auf den Vorgang des erneuten Zusammenführens, Neuerstellens, erneuten Testens und eine Binärdatei neu zertifizieren, nachdem eine öffentliche Version des GKI-Kernels. Sie können eine erneute PIN-Abfrage einer zertifizierten Binärdatei für Folgendes anfordern: Gegebenheiten:
- 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)
Sicherheits-Patches werden automatisch für bis zu Sechs Monate nach der Veröffentlichung des Zweigs. Nach Ablauf der sechsmonatigen Frist müssen Sie fordert eine Respin an, um Sicherheitspatches auf einen Zweig anzuwenden.
Richtlinien für Respin-Anfragen
Beachten Sie die folgenden Richtlinien, bevor Sie eine erneute Anpinnen anfordern:
Respins sind nur in Release-Zweigen nach einer ersten öffentlichen Version zulässig eines monatlichen Builds eingeführt.
Respin-Anfragen werden nur für einen bestimmten Release-Zweig für eine maximal sechs Monate nach der Veröffentlichung. Nach sechs Monaten Zweigstellen dürfen nur für die in den folgenden Artikeln genannten Sicherheitspatches neu angepinnt werden. ein Android-Sicherheitsbulletin
Wenn die Anforderungen für die automatische Gebotseinstellung , definiert im Sicherheitsbulletin für Android (ASB) nicht konform ist, wird der Zweig verworfen. Respin-Anfragen für verworfene Branches werden nicht akzeptiert. Das Einstellungsdatum für eine bestimmte GKI Der Release-Zweig ist in den monatlichen GKI-Versionshinweisen unter Releases. Die Anforderungen für den Langzeitsupport werden im Mai und November aktualisiert jährlich. Beispiel: Der
android12-5.10-2023-07Branch (5.10.177) wird nach dem 1. Mai 2024 nicht mehr für Respins unterstützt, da derandroid12-5.10-2023-07Branch (5.10.177) nicht den LTS-Anforderungen von ASB-2024-05 entspricht.Respins sind nur für dringende Fehlerkorrekturen, Aktualisierungen der Symbolliste oder um ein vorhandenes Feature mit einem Patch zu korrigieren.
Alle Patches, die in den Zweig der monatlichen Release-Version aufgenommen werden, müssen bereits in Hauptzweig der GKI-Entwicklung. Wenn zum Beispiel ein Patch für eine respin von
android12-5.10-2022-09muss bereits zusammengeführt sein inandroid12-5.10.Sie müssen Patches aus dem GKI-Hauptentwicklungszweig auswählen und Laden Sie den Patch in den Zweig der monatlichen Version hoch.
In der „respin“-Anfrage müssen Sie ihr eine Priorität (Dringlichkeit) zuweisen. Diese Priorität hilft dem GKI-Team, Partner besser zeitnah zu unterstützen. Geben Sie bei kritischen oder zeitkritischen Anfragen die Priorität P0 an. Für P0 und P1 auch die Dringlichkeit begründen. Die folgende Tabelle enthält eine Zuordnung von Fehlerpriorität und Zeit zur Behebung (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. Beispiel: Für
android12-5.10-2022-08undandroid12-5.10-2022-09, müssen Sie zwei Respin-Anfragen erstellen.Nachdem ein Build bereitgestellt und eine respin-Anfrage als behoben markiert wurde, sollte die „respin“-Anfrage zum Hinzufügen zusätzlicher CLs nicht noch einmal öffnen. Sie müssen eine neue respin-Anfrage, wenn zusätzliche Patches vorhanden sind, 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 Änderungsliste hinzugefügt werden.Change-Id: muss mit der Änderungs-ID der Basiszweigänderung identisch sein.
Wenn eine Antwort erforderlich ist und Sie nicht innerhalb wird die Priorität um eine Stufe herabgestuft (z. B. P0 wird auf P1 heruntergestuft. Wenn Sie zwei Wochen lang nicht reagieren, ist der Fehler als Won't Fix (Obsolete) (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) reicht die Respin-Anfrage ein.
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 bei Respin-Anfragen sind für dich sichtbar
(der Antragsteller), das GKI-Team und bestimmte Personen, die Sie dem
CC-Liste des Programmfehlers.
- Wenn du bereits eine Fehlerkorrektur hast, sollte die Anfrage auf den Patch verweisen. in AOSP, damit Google sie überprüfen kann. Wenn das Einreichen des Patches möglich ist, muss der Patch als Textdatei an die Anfrage angehängt werden.
- Wenn Sie das Problem nicht beheben können, muss die Anfrage so viel Informationen wie möglich, einschließlich der Kernel-Versionsnummer und Protokollen, damit Google um das Problem zu beheben.
- Das Google GKI-Team prüft die Anfrage und genehmigt sie oder weist sie wieder zu wenn Sie weitere Informationen benötigen.
- Nachdem eine Lösung vereinbart wurde, überprüft das Google-GKI-Team den Code (CR+2) ändern können. Die Überprüfung beginnt mit dem ESRT-Zeitraum. Das GKI-Team führt Zusammenführungen, Builds und Tests durch. für Regression und bestätigt die Änderung.
- Das Binärprogramm wird freigegeben an ci.android.com zur Verfügung stehen. Die Der ESRT-Zeitraum endet und das Google-Team für KI markiert die Anfrage als behoben und auf den Respin-Build verweisen. Der Respin-Build wird auch im Seite für allgemeine Kernel-Images (GKI):
GKI-Qualifikationen
| Arten von GKI-Builds | Durchsetzung der Qualitätsstandards | Notes |
|---|---|---|
| Wöchentlich | Tintenfischtests
|
|
| Monatlich (zertifiziert) | Tintenfischtests
<ph type="x-smartling-placeholder">
|
|
| Respins (zertifiziert) | Tintenfischtests
<ph type="x-smartling-placeholder">
|
|
Build-Artefakte erhalten
Die Artefakte für alle Veröffentlichungen sind hier erhältlich: ci.android.com zur Verfügung stehen. .
Weitere Informationen zum CI, einschließlich des Tests, Ergebnisse zur kontinuierlichen Integration von Android Dashboard.
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 Vorgang zum erneuten Anpinnen wird unterstützt, solange das Veröffentlichter GKI-Build (auf dem die Neuerstellung angefordert wird) ist mit der Version „Langzeitsupport“ kompatibel im Android-Sicherheitsbulletin (ASB).
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 Folgendes aus, um das Beispiel zu reproduzieren
Befehl:
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 die monatlich zertifizierte ausgewählten Kerneln. Diese Respins enthalten alle Programmfehler, die den Start blockieren. Fehlerbehebungen, die bis zu einem bestimmten Zeitpunkt von den OEMs anhand der entsprechenden Basis gemeldet werden monatliches Release. Im folgenden Beispiel sehen Sie, wie diese Art von Szenario abläuft.
- OEM1 und OEM2 entscheiden sich ab November 2021 für den Binärrelease von GKI.
- OEM1 und OEM2 finden Probleme, die Patches für den Support erfordern. Diese Patches unterschiedlich oder gleich sein können.
- Für die Respins des Binärprogramms für November 2021 werden Starts blockiert. Fehlerbehebungen, die sowohl von OEM1 als auch von OEM2 während des Fensters mit der Auflösung gemeldet wurden, aber nichts mehr.
- Die im zweiten Punkt genannten Probleme sind auch in nachfolgenden GKI enthalten. monatliche Releases.
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 „pro OEM“ Respin-Pfad ist derzeit nicht skalierbar. Stattdessen unterzieht das GKI-Team jede einzelne Änderung, die in die Respin-Phase führt. erstellt und testet die Änderungen mit der gesamten verfügbaren Hardware, bevor Sie eine neue erstellen. Wenn das GKI-Team feststellt, dass das Problem auf einen OEM, ein Gerät oder ein Modell zurückzuführen ist, kann das GKI-Team sicherstellen, dass der durch die Änderung hinzugefügte Code nur auf dem Gerät, Modell oder Artikelnummer.
Der große Vorteil dieser Funktion besteht darin, dass jedes Gerät, die dieselbe Versionsbasis verwenden, voneinander profitieren, insbesondere wenn die Programmfehler allgemeine und für alle Nutzenden anwendbar sind. Wichtige Kernel-Fehler gefunden bei Mobilfunkbetreibertests ist ein konkretes 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 nimmt keine Änderungen an einem Repin-Build vor, bis das Problem verstanden wurde. und alle Details wurden gesammelt. Dies ist im Änderungsprotokoll zu sehen. (Commit-Nachricht). Google gibt zwar nicht preis, um welches Gerät es sich handelt, OEMs finden die Problembeschreibung und die Lösung jederzeit im Änderungsprotokoll.