Respin anfordern

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

Beachten Sie die folgenden Richtlinien, bevor Sie eine erneute Überprüfung beantragen.

Voraussetzungen und Lebenszyklus

  • Zeitpunkt:Sie können Respins nur für Release-Branches anfordern, nachdem ein erster öffentlicher Release eines vierteljährlichen Builds gestartet wurde. Sie können Respin-Anfragen für Vendor-Hooks oder andere Funktionen nur für einen bestimmten Release-Branch und maximal sechs Monate nach der ersten öffentlichen Veröffentlichung stellen.
  • Sicherheit und LTS:Nach sechs Monaten sind Zweige nur für Respins für Sicherheitspatches, die in einem Sicherheitsbulletin für Android aufgeführt sind, oder für kritische Fehlerkorrekturen geeignet.
  • 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 Einstellungsdatum für einen bestimmten GKI-Release-Zweig ist in den vierteljährlichen GKI-Release-Build-Hinweisen unter „Releases“ enthalten. Das Release vom September 2025 wird beispielsweise bis März 2027 für Respins unterstützt. Dieses Datum entspricht der Lebensdauer der LTS 2.0-Kernelversion von 18 Monaten für Releases ab September 2025 (Releases vor September 2025 hatten 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.

Standards für das Einreichen von Patches

Damit die erwartete Standardbearbeitungszeit (Expected Standard Resolution Time, ESRT) für die Verarbeitung von Respin-Anfragen eingehalten werden kann, müssen alle Patches, die für einen Release-Branch 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 von GKI gemergt 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.
  • Clean Cherry-Pick:Sie müssen Patches direkt aus dem Entwicklungszweig cherry-picken. Wählen Sie nicht nur bestimmte Commits aus anderen Release-Branches aus (z. B. von 2025-08 nach 2025-09), da dies zu Autor- oder Commit-Informationen führen kann, die nicht mit der Version im Entwicklungsbranch übereinstimmen. Patches mit inkonsistenten Informationen werden nicht akzeptiert.
  • Metadaten beibehalten:Die ursprünglichen Commit-Metadaten (z. B. Autor, ursprünglicher Zeitstempel) werden beibehalten. Verwenden Sie git cherry-pick -x, um die Metadaten beizubehalten.

Commit-Kette

  • Sequenzielle Kette:Wenn die erneute Einreichung mehrere Patches umfasst, laden Sie sie als einzelne, sequenzielle Kette von Commits hoch.
  • ABI- und KMI-Platzierung:Wenn ein Respin mit mehreren Patches KMI- (Kernel Module Interface) und ABI-Updates (Application Binary Interface) enthält (z. B. Änderungen an der Symbolliste oder XML-/STG-Datei-Updates), 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 der Grundlage der neuesten Überarbeitung des übergeordneten Patches neu basieren, um Build-Fehler zu vermeiden.
  • Konfliktlösung:Prüfen Sie, ob in einem Patch Konfliktmarkierungen vorhanden sind.
  • Build-Überprüfung:Die gesamte Commit-Kette muss erfolgreich erstellt werden.

Erforderliche Tags

Der Fortschritt bei der erneuten Überprüfung wird blockiert, wenn die folgenden Tags in der Commit-Nachricht fehlen:

  • Change-Id: Muss mit der Change-Id der Änderung des Entwicklungszweigs übereinstimmen.
    • Ausnahme: Wenn der Patch im Rahmen eines LTS-Updates in den Entwicklungszweig gemergt wurde, sollte es sich um einen Cherry-Pick der LTS-Version handeln und er sollte als UPSTREAM-Patch formatiert sein. Weitere Informationen finden Sie unter Wie reiche ich Patches für Android Common Kernels ein?.
  • Bug (vorhanden): Vorhandene Bug: XYZ-Tags aus dem Commit des ursprünglichen Entwicklungszweigs 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 Anfrage für die erneute Überprüfung verknüpft ist.
  • Aktualisieren Sie bei Bedarf das Commit-Tag UPSTREAM: Wenn Sie eine CL aus dem Entwicklungs- in den Release-Branch übertragen und die CL mit UPSTREAM getaggt ist, sollten Sie die folgenden Szenarien berücksichtigen:
    • Wenn die Änderung problemlos auf den Release-Branch 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 Änderungen. Weitere Informationen finden Sie unter Anforderungen für Backports aus dem Mainline-Linux-Kernel.

Priorität und ESRT

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

  • Markieren Sie kritische oder dringende Anfragen mit der Priorität P0.
  • Bei P0- und P1-Anfragen müssen Sie die Dringlichkeit begründen.

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

PrioritätESRT
P02 Werktage
P15 Werktage
P210 Werktage
P315 Geschäftstage

SLA-Richtlinien

  • Reichen Sie für jeden Release-Zweig eine separate Anfrage für einen Respin ein.
  • Wenn Sie Änderungen an einer Anfrage für einen erneuten Spin haben, die als behoben markiert ist, senden Sie eine neue Anfrage für einen erneuten Spin. Öffnen Sie die Anfrage nicht noch einmal, um weitere Änderungslisten hinzuzufügen.
  • Wenn für eine Anfrage zur erneuten Bearbeitung eine Antwort von Ihnen 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 zwei Wochen lang nicht reagieren, wird der Fehler als Won't Fix (Obsolete) (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: Prozess für die erneute Überprüfung im Notfall.

So reichen Sie einen Antrag auf erneute Generierung ein:

  1. Füllen Sie das Formular für die GKI-Neuerstellung aus und wenden Sie sich umgehend an Ihren Ansprechpartner bei Google.

    • Mit diesem Formular wird ein Fehler für eine 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.
    • Fügen Sie dem ausgewählten Patch ein Bug: XYZ-Tag mit der ID der erneuten Überprüfung hinzu.

    Beispiel:So wählen Sie einen CL von android16-6.12 bis 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. Senden Sie den Fehler. Nachdem Sie den Antrag eingereicht haben, passiert Folgendes:

    • Ablauf der Überprüfung nach der Einreichung:

      • 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. Der ESRT-Timer ist während dieser Überprüfung aktiv. Wenn der Patch jedoch abgelehnt wird oder überarbeitet werden muss, wird der ESRT-Timer zurückgesetzt.
      • Das GKI-Team führt die Änderung zusammen, erstellt sie, testet sie auf Regressionen und zertifiziert sie.

    • Release:

      • Das Binärprogramm wird auf ci.android.com veröffentlicht.
      • Der ESRT-Zeitrahmen 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 Generic Kernel Image (GKI) Release Builds veröffentlicht.