Prośba o ponowne losowanie

A respin to proces ponownego scalania, kompilowania, testowania i certyfikowania pliku binarnego po publicznym udostępnieniu jądra GKI.

Zanim poprosisz o respin, zapoznaj się z tymi wytycznymi.

Kwalifikacje i cykl życia

  • Termin: o respin możesz poprosić tylko w przypadku gałęzi wersji po początkowym publicznym udostępnieniu kwartalnej kompilacji. Prośby o respin dotyczące vendor-hooks lub innych funkcji możesz przesyłać tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od początkowego publicznego udostępnienia.
  • Zabezpieczenia i LTS: po 6 miesiącach gałęzie kwalifikują się do respinów tylko w przypadku poprawek zabezpieczeń wymienionych w Biuletynie bezpieczeństwa w Androidzie lub krytycznych poprawek błędów.
  • Wycofanie: jeśli wymagania LTS określone w Biuletynie bezpieczeństwa w Androidzie powodują, że gałąź jest niezgodna, zostaje ona wycofana. Prośby o respin w przypadku wycofanych gałęzi nie są akceptowane.
    • Data wycofania danej gałęzi wersji GKI jest podana w kwartalnych informacjach o kompilacji do publikacji GKI w sekcji Wersje. Na przykład wersja z września 2025 r. jest obsługiwana w przypadku respinów do marca 2027 r. Ta data odzwierciedla 18-miesięczny okres eksploatacji jądra LTS 2.0 w przypadku wersji wydanych od września 2025 r. (wersje wydane przed wrześniem 2025 r. miały 12-miesięczny okres eksploatacji).
  • Zakres: o respin możesz poprosić tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki w celu naprawienia istniejącej funkcji.
  • Wersje GKI 16 KB: respiny na żądanie w przypadku obsługiwanych gałęzi GKI 16 KB (android15-6.6, android16-6.12, i android17-6.18) są realizowane na podstawie tego samego formularza prośby o respin, tych samych standardów przesyłania poprawek i tego samego procesu kwalifikacji co w przypadku kompilacji 4 KB. Nie musisz aktualizować jądra 4 KB i 16 KB jednocześnie, ale zalecamy to.

Standardy przesyłania poprawek

Aby spełnić oczekiwany standardowy czas rozwiązania problemu (ESRT) w przypadku przetwarzania prośby o respin, wszystkie poprawki przesłane do gałęzi wersji muszą być zgodne z tymi regułami technicznymi.

Nadrzędne źródło danych i cherry-pick

  • Najpierw gałąź programistyczna: wszystkie poprawki, które mają zostać uwzględnione w kwartalnej gałęzi wersji, muszą być już scalone z główną gałęzią programistyczną GKI. Jeśli na przykład poprawka jest wymagana w przypadku respinu android15-6.6-2025-08, musi być już scalona z android15-6.6.
  • Czysty cherry-pick: musisz cherry-pickować poprawki bezpośrednio z gałęzi programistycznej. Nie cherry-pickuj z innych gałęzi wersji (np. nie wybieraj z 2025-08 do 2025-09), ponieważ może to spowodować, że informacje o autorze lub zatwierdzeniu będą niezgodne z wersją w gałęzi programistycznej. Poprawki z niespójnymi informacjami nie będą akceptowane.
  • Zachowaj metadane: zachowaj oryginalne metadane zatwierdzenia (np. autora, oryginalny sygnaturę czasową). Aby zachować metadane, użyj polecenia git cherry-pick -x.

Łańcuch zatwierdzeń

  • Łańcuch sekwencyjny: jeśli prośba o respin obejmuje kilka poprawek, prześlij je jako jeden sekwencyjny łańcuch zatwierdzeń.
  • Umieszczenie ABI i KMI: jeśli respin obejmujący wiele łatek zawiera aktualizacje interfejsu modułu jądra systemu (KMI) i interfejsu binarnego aplikacji (ABI) (np. zmiany na liście symboli lub aktualizacje plików XML/STG), umieść te zatwierdzenia na samym końcu łańcucha zatwierdzeń.
  • Rebasing: jeśli edytujesz zatwierdzenie nadrzędne w łańcuchu, musisz ponownie zastosować wszystkie poprawki podrzędne na najnowszej wersji poprawki nadrzędnej, aby uniknąć błędów kompilacji.
  • Rozwiązywanie konfliktów: sprawdź, czy w żadnej poprawce nie ma znaczników konfliktów.
  • Weryfikacja kompilacji: cały łańcuch zatwierdzeń musi zostać skompilowany.

Tagi wymagane

Bez tych tagów w wiadomości zatwierdzenia nie można kontynuować realizacji prośby o respin:

  • Change-Id: musi być identyczny z Change-Id zmiany w gałęzi programistycznej.
  • Bug (istniejący): nie można usuwać istniejących tagów Bug: XYZ z oryginalnego zatwierdzenia w gałęzi programistycznej.
  • Bug (respin): musisz dodać nowy tag Bug: XYZ, gdzie XYZ odpowiada identyfikatorowi błędu powiązanemu z bieżącą prośbą o respin.
  • W razie potrzeby zaktualizuj tag zatwierdzenia UPSTREAM: podczas cherry-pickowania CL z gałęzi programistycznej do gałęzi wersji, jeśli CL jest oznaczony tagiem UPSTREAM, rozważ te scenariusze:
    • Jeśli CL można bez problemu zastosować w gałęzi wersji, nie musisz podejmować żadnych dodatkowych działań.
    • Jeśli CL nie można bez problemu zastosować, rozwiąż konflikty, zaktualizuj tag do BACKPORT i opisz, co zostało zrobione w ramach rozwiązywania konfliktów. Zobacz Wymagania dotyczące przenoszenia poprawek z głównej gałęzi Linuksa.

Priorytet i ESRT

Aby pomóc zespołowi GKI w ustalaniu priorytetów, przypisz priorytet (pilność) do prośby o respin. Ten priorytet pomaga zespołowi GKI szybciej udzielać pomocy partnerom.

  • W przypadku krytycznych lub pilnych próśb ustaw priorytet na P0.
  • W przypadku próśb P0 i P1 musisz też uzasadnić pilność.

W tabeli poniżej znajdziesz mapowanie priorytetu błędu i czasu rozwiązania problemu (ESRT):

PriorytetESRT
P02 dni robocze
P15 dni roboczych
P210 dni roboczych
P315 dni roboczych

Zasady SLA

  • W przypadku każdej gałęzi wersji prześlij osobną prośbę o respin.
  • Jeśli masz zmiany w prośbie o respin, która jest oznaczona jako naprawiona, prześlij nową prośbę o respin. Nie otwieraj ponownie prośby, aby dodać dodatkowe listy zmian (CL).
  • Jeśli prośba o respin wymaga Twojej odpowiedzi, a nie odpowiesz w ciągu 3 dni roboczych, priorytet zostanie obniżony o 1 poziom, np. P0 zostanie obniżony do P1.
  • Jeśli nie odpowiesz przez 2 tygodnie, błąd zostanie oznaczony jako Nie do naprawienia (przestarzały).

Prześlij prośbę o respin

Na diagramie poniżej przedstawiono proces respinu. Proces rozpoczyna się, gdy partner OEM (Ty) prześle prośbę o respin.

Proces ponownego przesyłania w sytuacjach awaryjnych Rysunek 1.Proces respinu w sytuacjach awaryjnych.

Aby przesłać prośbę o respin:

  1. Wypełnij formularz prośby o respin GKI i natychmiast skontaktuj się z osobą kontaktową w Google.

    • Ten formularz tworzy błąd w prośbie o respin GKI.

  2. Przygotuj poprawki:

    • Sprawdź, czy poprawka została scalona z gałęzią programistyczną GKI.
    • Zastosuj poprawkę do odpowiedniej gałęzi wersji GKI.
    • Zmodyfikuj cherry-pickowaną poprawkę, aby zawierała tag Bug: XYZ z odwołaniem do identyfikatora prośby o respin.

    Przykład: Aby cherry-pickować CL z android16-6.12 do android16-6.12-2025-12:

    # 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. Prześlij błąd. Po przesłaniu prośby nastąpią te działania:

    • Proces weryfikacji po przesłaniu:

      • Zespół GKI Google sprawdza prośbę i zatwierdza ją lub przypisuje ją z powrotem do Ciebie, jeśli potrzebne są dodatkowe informacje.
      • Po uzgodnieniu poprawki zespół GKI Google przeprowadza weryfikację kodu zmiany. Podczas tego przeglądu aktywny jest licznik ESRT. Jeśli jednak poprawka zostanie odrzucona lub będzie wymagać przeróbki, licznik ESRT zostanie zresetowany.
      • Zespół GKI scala, kompiluje, testuje regresję i certyfikuje zmianę.

    • Wersja: