Respin anfordern

Ein Respin ist der Prozess des erneuten Zusammenführens, Neuerstellens, erneuten Testens und erneuten Zertifizierens einer Binärdatei nach einer öffentlichen Veröffentlichung des GKI-Kernels.

Beachten Sie vor dem Anfordern eines Respins die folgenden Richtlinien.

Berechtigung und Lebenszyklus

  • Zeitpunkt:Sie können Respins nur für Release-Zweige anfordern, nachdem eine erste öffentliche Veröffentlichung eines vierteljährlichen Builds erfolgt ist. Respin-Anfragen für Vendor-Hooks oder andere Funktionen können nur für einen bestimmten Release-Zweig und maximal sechs Monate nach der ersten öffentlichen Veröffentlichung angefordert werden.
  • Sicherheit und LTS:Nach sechs Monaten können Respins für Zweige nur für Sicherheitspatches, die in einem Sicherheitsbulletin für Android (Android Security Bulletin, ASB) genannt werden, oder für kritische Fehlerkorrekturen angefordert werden.
  • Einstellung:Wenn die LTS-Anforderungen, die im Sicherheitsbulletin für Android (Android Security Bulletin, ASB) definiert sind, dazu führen, dass der Zweig nicht mehr den Richtlinien entspricht, wird er eingestellt. Respin-Anfragen für eingestellte Zweige werden nicht akzeptiert.
    • Das Datum der Einstellung für einen bestimmten GKI-Release-Zweig ist in den vierteljährlichen Versionshinweisen für GKI-Release-Builds unter „Releases“ enthalten. Beispielsweise wird das Release vom September 2025 bis März 2027 für Respins unterstützt. Dieses Datum entspricht der Lebensdauer der LTS 2.0-Kernel-Version von 18 Monaten für Releases ab September 2025. Für Releases vor September 2025 galt eine Lebensdauer von 12 Monaten.
  • Umfang:Fordern Sie Respins nur für dringende Fehlerkorrekturen, Aktualisierungen der Symbolliste oder zum Anwenden eines Patches zur Behebung eines Fehlers in einer vorhandenen Funktion an.
  • 16-KB-GKI-Releases: On-Demand-Respins für unterstützte 16-KB-GKI-Zweige (android15-6.6, android16-6.12, und android17-6.18) folgen demselben Respin-Anfrageformular, denselben Standards für die Patch-Einreichung und demselben Qualifizierungsprozess wie 4-KB-Builds. Sie müssen 4-KB- und 16-KB-Kernel nicht zusammen aktualisieren, wir empfehlen es jedoch.

Standards für die Patch-Einreichung

Damit die erwartete Standardbearbeitungszeit (Expected Standard Resolution Time, ESRT) für die Bearbeitung von Respin-Anfragen eingehalten werden kann, müssen alle Patches, die für einen Release-Zweig eingereicht werden, die folgenden technischen Regeln einhalten.

Source of Truth und Cherry-Picks

  • Zuerst Entwicklungszweig:Alle Patches, die in den vierteljährlichen Release-Zweig aufgenommen werden, müssen bereits in den Hauptentwicklungszweig des GKI zusammengeführt worden sein. Wenn beispielsweise ein Patch für einen Respin von android15-6.6-2025-08 erforderlich ist, muss er bereits in android15-6.6 zusammengeführt worden sein.
  • Sauberer Cherry-Pick:Sie müssen Patches direkt aus dem Entwicklungszweig auswählen. Wählen Sie keine Patches aus anderen Release-Zweigen aus (z. B. nicht von 2025-08 nach 2025-09), da dies zu Informationen zu Autor oder Commit führen kann, die nicht mit der Version im Entwicklungszweig übereinstimmen. Patches mit inkonsistenten Informationen werden nicht akzeptiert.
  • Metadaten beibehalten:Behalten Sie die ursprünglichen Commit-Metadaten bei (z. B. Autor, ursprünglicher Zeitstempel). Verwenden Sie git cherry-pick -x, um die Metadaten beizubehalten.

Commit-Kette

  • Sequenzielle Kette:Wenn die Respin-Anfrage mehrere Patches umfasst, laden Sie sie als einzelne, sequenzielle Kette von Commits hoch.
  • ABI- und KMI-Platzierung:Wenn ein Respin mit mehreren Patches Aktualisierungen der Kernelmodul-Schnittstelle (KMI) und Application Binary Interface (ABI) umfasst (z. B. Änderungen der Symbolliste oder Aktualisierungen von XML-/STG-Dateien), platzieren Sie diese Commits ganz am Ende der Commit-Kette.
  • Rebasing:Wenn Sie einen übergeordneten Commit in der Kette bearbeiten, müssen Sie alle untergeordneten Patches auf die neueste Überarbeitung des übergeordneten Patches rebasen, um Build-Fehler zu vermeiden.
  • Konfliktlösung:Prüfen Sie, ob in einem Patch Konfliktmarker vorhanden sind.
  • Build-Überprüfung:Die gesamte Commit-Kette muss erfolgreich erstellt werden.

Erforderliche Tags

Ohne die folgenden Tags in der Commit-Nachricht kann die Respin-Anfrage nicht bearbeitet werden:

  • Change-Id: Muss mit der Change-Id der Änderung des Entwicklungszweigs identisch sein.
    • Ausnahme: Wenn der Patch im Rahmen eines LTS-Updates in den Entwicklungszweig zusammengeführt wurde, muss es sich um einen Cherry-Pick der LTS-Version handeln und als UPSTREAM-Patch formatiert sein. Weitere Informationen finden Sie unter Patches für Android Common Kernels einreichen.
  • Bug (vorhanden): Vorhandene Bug: XYZ Tags aus dem ursprünglichen Entwicklungs zweig-Commit dürfen nicht entfernt werden.
  • Bug (Respin): Sie müssen ein neues Bug: XYZ-Tag hinzufügen, wobei XYZ der Fehler-ID entspricht, die mit der aktuellen Respin-Anfrage verknüpft ist.
  • Aktualisieren Sie bei Bedarf das UPSTREAM-Commit-Tag: Wenn Sie einen CL aus dem Entwicklungszweig in den Release-Zweig auswählen und der CL als UPSTREAM getaggt ist, beachten Sie die folgenden Szenarien:
    • Wenn der CL sauber auf den Release-Zweig angewendet wird, müssen Sie nichts weiter tun.
    • Wenn der CL nicht sauber angewendet wird, beheben Sie die Konflikte, aktualisieren Sie das Tag auf BACKPORT, und dokumentieren Sie die im Rahmen der Konfliktlösung vorgenommenen Schritte. Weitere Informationen finden Sie unter Anforderungen für Backports aus dem Mainline-Linux-Kernel.

Priorität und ESRT

Weisen Sie der Respin-Anfrage eine Priorität (Dringlichkeit) zu, damit das GKI-Team sie priorisieren kann. So kann das GKI-Team Partner rechtzeitig besser unterstützen.

  • Markieren Sie die Priorität für kritische oder zeitkritische Anfragen als P0.
  • Bei P0 - und P1 -Anfragen müssen Sie die Dringlichkeit auch begründen.

In der folgenden Tabelle finden Sie eine Zuordnung der Fehlerpriorität und der Zeit bis zur Lösung (ESRT):

PrioritätESRT
P02 Arbeitstage
P15 Arbeitstage
P210 Arbeitstage
P315 Arbeitstage

SLA-Richtlinien

  • Reichen Sie für jeden Release-Zweig eine separate Respin-Anfrage ein.
  • Wenn Sie Änderungen an einer Respin-Anfrage haben, die als behoben markiert ist, reichen Sie eine neue Respin-Anfrage ein. Öffnen Sie die Anfrage nicht wieder, um zusätzliche Änderungslisten (Changelists, CLs) hinzuzufügen.
  • Wenn für eine Respin-Anfrage eine Antwort von Ihnen erforderlich ist und Sie nicht innerhalb von drei Arbeitstagen antworten, wird die Priorität um eine Stufe herabgestuft. P0 wird beispielsweise auf P1 herabgestuft.
  • Wenn Sie zwei Wochen lang nicht antworten, wird der Fehler als Nicht behebbar (veraltet) markiert.

Respin-Anfrage einreichen

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

Notfall-Respin-Prozess Abbildung 1.Notfall-Respin-Prozess

So reichen Sie eine Respin-Anfrage ein:

  1. Füllen Sie das Formular für die GKI-Respin-Anfrage aus und wenden Sie sich sofort an Ihren Google-Ansprechpartner.

    • Mit diesem Formular wird ein Fehler für die GKI-Respin-Anfrage erstellt.

  2. Patches vorbereiten :

    • Prüfen Sie, ob der Patch in den GKI-Entwicklungszweig zusammengeführt wurde.
    • Wenden Sie den Patch auf den entsprechenden GKI-Release-Zweig an.
    • Ändern Sie den ausgewählten Patch so, dass er ein Bug: XYZ-Tag enthält, das auf die ID der Respin-Anfrage verweist.

    Beispiel: So wählen Sie einen CL von android16-6.12 nach android16-6.12-2025-12 aus:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. Reichen Sie den Fehler ein. Nach dem Einreichen der Anfrage passiert Folgendes:

    • Überprüfungsprozess nach dem Einreichen :

      • Das Google GKI-Team prüft die Anfrage und genehmigt sie oder weist sie Ihnen zu, wenn weitere Informationen erforderlich sind.
      • Nachdem eine Korrektur vereinbart wurde, führt das Google GKI-Team eine Codeüberprüfung der Änderung durch. Die ESRT-Zeit läuft während dieser Überprüfung. Wenn der Patch jedoch abgelehnt wird oder überarbeitet werden muss, wird die ESRT-Zeit zurückgesetzt.
      • Das GKI-Team führt die Änderung zusammen, erstellt sie, testet sie auf Regressionen und zertifiziert sie.

    • Release :