Prośba o ponowne losowanie

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

Zanim poprosisz o ponowne sprawdzenie, zapoznaj się z tymi wytycznymi.

Wymagania i cykl życia

  • Czas: prośby o ponowne przesłanie można przesyłać tylko w przypadku gałęzi wersji po wprowadzeniu pierwszej publicznej wersji kompilacji kwartalnej. Żądania ponownego przesłania odpowiedzi w przypadku funkcji vendor-hooks lub innych funkcji można przesyłać tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od pierwszej publicznej wersji.
  • 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 wersji GKI w sekcji Wersje. Na przykład wersja z września 2025 r. jest obsługiwana w przypadku ponownych wersji do marca 2027 r. Ta data odzwierciedla okres 18 miesięcy, w którym wersja jądra LTS 2.0 jest obsługiwana w przypadku wersji wydanych od września 2025 r. (wersje wydane przed wrześniem 2025 r. były obsługiwane przez 12 miesięcy).
  • Zakres: proś o ponowne sprawdzenie tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki w celu naprawienia istniejącej funkcji.

Standardy przesyłania poprawek

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

Źródło informacji i wybiórcze wybieranie danych

  • Najpierw gałąź deweloperska: wszystkie poprawki, które mają trafić do gałęzi wydania kwartalnego, muszą być już scalone z główną gałęzią deweloperską GKI. Jeśli na przykład poprawka jest wymagana w przypadku ponownego wydania wersji android15-6.6-2025-08, musi być już scalona z wersją android15-6.6.
  • Czyste wybiórcze zastosowanie zmian: musisz wybiórczo zastosować poprawki bezpośrednio z gałęzi deweloperskiej. Nie wybieraj zmian z innych gałęzi wersji (np. nie wybieraj zmian 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 deweloperskiej. Patche z niespójnymi informacjami nie będą akceptowane.
  • Zachowaj metadane: zachowaj oryginalne metadane zatwierdzenia (np. autora, oryginalną sygnaturę czasową). Użyj git cherry-pick -x, aby zachować metadane.

Łańcuch zatwierdzeń

  • Łańcuch sekwencyjny: jeśli prośba o ponowne przesłanie dotyczy wielu poprawek, prześlij je jako pojedynczy łańcuch sekwencyjny zatwierdzeń.
  • Umieszczanie interfejsów ABI i KMI: jeśli ponowne przesłanie wielu poprawek obejmuje aktualizacje interfejsu modułu jądra (KMI) i interfejsu binarnego aplikacji (ABI) (np. zmiany listy symboli lub aktualizacje plików XML/STG), umieść te zmiany na samym końcu łańcucha zmian.
  • Zmiana bazy: jeśli edytujesz zatwierdzenie nadrzędne w łańcuchu, musisz zmienić bazę wszystkich poprawek podrzędnych na najnowszą wersję poprawki nadrzędnej, aby uniknąć błędów kompilacji.
  • Rozwiązywanie konfliktów: sprawdź, czy w żadnej poprawce nie ma znaczników konfliktu.
  • Weryfikacja kompilacji: cała sekwencja zatwierdzeń musi zostać skompilowana.

Wymagane tagi

Postęp w rozpatrywaniu prośby o ponowne sprawdzenie jest blokowany, jeśli w komunikacie zatwierdzenia nie ma tych tagów:

  • Change-Id: musi być identyczny z Change-Id zmiany w gałęzi deweloperskiej.
  • Bug (istniejące): nie można usuwać istniejących tagów Bug: XYZ z pierwotnego zatwierdzenia gałęzi deweloperskiej.
  • Bug (respin): musisz dodać nowy tag Bug: XYZ, gdzie XYZ odpowiada identyfikatorowi błędu powiązanemu z bieżącą prośbą o ponowne przesłanie.
  • W razie potrzeby zaktualizuj tag zatwierdzenia UPSTREAM: podczas przenoszenia wybranego CL z gałęzi deweloperskiej do gałęzi wersji i gdy CL jest oznaczony tagiem UPSTREAM, rozważ następujące scenariusze:
    • Jeśli lista zmian zostanie bez problemu zastosowana do gałęzi wersji, nie musisz podejmować żadnych dodatkowych działań.
    • Jeśli lista zmian nie pasuje, rozwiąż konflikty, zaktualizuj tag do BACKPORT i udokumentuj wykonane czynności w ramach rozwiązywania konfliktów. Więcej informacji znajdziesz w artykule Wymagania dotyczące przenoszenia zmian z głównej gałęzi Linuxa.

Priorytet i ESRT

Przypisz priorytet (pilność) prośbie o ponowne przesłanie, aby pomóc zespołowi GKI w określeniu priorytetów. Ten priorytet pomaga zespołowi GKI w terminowym udzielaniu pomocy partnerom.

  • W przypadku pilnych zgłoszeń oznacz priorytet jako P0.
  • W przypadku zgłoszeń o priorytecie P0 i P1 musisz też uzasadnić pilność sprawy.

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

PriorytetESRT
P02 dni robocze
P1S5 dni roboczych
P210 dni roboczych
P315 dni roboczych

Zasady SLA

  • Prześlij osobne prośby o ponowne sprawdzenie dla każdej gałęzi wydania.
  • Jeśli chcesz wprowadzić zmiany w prośbie o ponowne sprawdzenie, która została oznaczona jako rozwiązana, prześlij nową prośbę. Nie otwieraj ponownie prośby o dodanie kolejnych list zmian.
  • Jeśli prośba o ponowne przesłanie wymaga Twojej odpowiedzi, a nie odpowiesz w ciągu 3 dni roboczych, priorytet zostanie obniżony o 1 poziom, np. z P0 na P1.
  • Jeśli nie odpowiesz w ciągu 2 tygodni, błąd zostanie oznaczony jako Nie do naprawienia (przestarzały).

Przesyłanie prośby o ponowne sprawdzenie

Na tym diagramie przedstawiono proces ponownego losowania. Proces rozpoczyna się, gdy partner OEM (Ty) prześle prośbę o ponowne wygenerowanie.

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

Aby przesłać prośbę o ponowne sprawdzenie:

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

    • Ten formularz tworzy zgłoszenie błędu dotyczące ponownego utworzenia GKI.

  2. Przygotuj łatki:

    • Sprawdź, czy poprawka została scalona z gałęzią deweloperską GKI.
    • Zastosuj poprawkę do odpowiedniej gałęzi wersji GKI.
    • Zmodyfikuj wybraną poprawkę, aby zawierała tag Bug: XYZ z identyfikatorem prośby o ponowne przesłanie.

    Przykład: Aby wybrać 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:

    • Proces sprawdzania po przesłaniu zgłoszenia:

      • Zespół Google GKI sprawdza prośbę i zatwierdza ją lub odsyła do Ciebie, jeśli potrzebuje więcej informacji.
      • Po uzgodnieniu poprawki zespół Google GKI przeprowadza weryfikację kodu zmiany. Podczas tego sprawdzania timer ESRT jest aktywny. Jeśli jednak poprawka zostanie odrzucona lub będzie wymagać ponownego opracowania, licznik ESRT zostanie zresetowany.
      • Zespół GKI scala, kompiluje, testuje pod kątem regresji i certyfikuje zmianę.

    • Wersja:

      • Plik binarny jest publikowany na stronie ci.android.com.
      • Okres ESRT dobiega końca, a zespół Google GKI oznacza prośbę jako rozwiązaną i odwołuje się do wersji respin.
      • Wersja ponowna jest też publikowana na stronie wersji GKI.