Proces publikowania ogólnego obrazu jądra (GKI)

Na tej stronie opisujemy, jak udostępniany jest GKI, w tym cotygodniowe, kwartalne i nadzwyczajne wersje. Celem tego dokumentu jest przekazanie producentom OEM wskazówek dotyczących tego, gdzie można pobrać GKI, a także procesu wprowadzania poprawek awaryjnych poza pasmem. Producenci OEM mogą też skorzystać z dokumentacji GKI, aby dowiedzieć się więcej o tym, jak współpracować z zespołem Android Kernel w celu optymalizacji jądra GKI pod kątem swoich produktów.

Częstotliwość publikowania wersji GKI

GKI jest udostępniany co kwartał po zamrożeniu KMI.

Ważność kompilacji GKI dla producentów OEM

Producenci OEM mogą używać niedawno opublikowanego jądra GKI Androida. Producenci OEM mogą wprowadzać na rynek kompilacje z certyfikatem GKI, o ile są one zgodne z wymaganiami LTS określonymi w Biuletynie bezpieczeństwa w Androidzie.

Kwartalne certyfikowane wersje

Kwartalne wersje GKI zawierają przetestowany boot.img, który zawiera certyfikat wstawiony przez Google, potwierdzający, że pliki binarne zostały utworzone na podstawie znanego źródła kodu.

W każdym kwartale wybierana jest kandydacka wersja kwartalna GKI (niecertyfikowana) po dacie odcięcia, która zwykle przypada na drugą kompilację tygodniową w danym miesiącu. Po wybraniu wersji kandydującej do wydania kwartalnego nowe zmiany nie będą akceptowane w wydaniu z tego miesiąca. W okresie zamkniętym można wprowadzać tylko poprawki błędów, które powodują niepowodzenie testu. Wersja kandydująca przechodzi kontrolę jakości opisaną w sekcji dotyczącej kwalifikacji GKI, aby zapewnić pomyślne przejście testów zgodności na kompilacji GSI+GKI na urządzeniu referencyjnym i na platformie Cuttlefish.

Rysunek 1. Harmonogram wersji GKI

Proces ponownego przesyłania w sytuacji awaryjnej

Ponowne kompilowanie to proces ponownego scalania, ponownego kompilowania, ponownego testowania i ponownego certyfikowania pliku binarnego po publicznym udostępnieniu jądra GKI. Możesz poprosić o ponowne wygenerowanie certyfikowanego pliku binarnego w jednej z tych sytuacji:

• Aby zaktualizować listę symboli:
• Aby zastosować poprawkę do błędu, w tym błędów wykrytych podczas zatwierdzania w laboratorium operatora.
• Aby dodać element dostawcy:
• Aby zastosować poprawkę do istniejącej funkcji.
• Aby zastosować poprawkę zabezpieczeń (po 6 miesiącach).

Poprawki zabezpieczeń są automatycznie scalane z gałęzią wersji przez maksymalnie 6 miesięcy od jej wydania. Po upływie 6 miesięcy musisz poprosić o respin, aby zastosować poprawki zabezpieczeń w gałęzi.

Wytyczne dotyczące ponownego wysyłania żądań

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

• Ponowne kompilacje są dozwolone tylko w przypadku gałęzi wersji po początkowym udostępnieniu publicznym kwartalnej kompilacji.

• Prośby o respin są akceptowane tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od pierwszej publicznej wersji. Po 6 miesiącach gałęzie kwalifikują się do respinów tylko w przypadku poprawek zabezpieczeń wymienionych w Biuletynie bezpieczeństwa w Androidzie.

• 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 notatkach do wersji GKI w sekcji Wersje. W celu planowania przyszłych działań wymagania dotyczące długoterminowego wsparcia są aktualizowane co roku w maju i listopadzie. Na przykład gałąź android12-5.10-2023-07 (5.10.177) nie jest obsługiwana w przypadku ponownych kompilacji po 1 maja 2024 r., ponieważ gałąź android12-5.10-2023-07 (5.10.177) nie spełnia wymagań LTS określonych w ASB-2024-05.

• Ponowne przesłanie jest możliwe tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki do istniejącej funkcji.

• Wszystkie poprawki, które mają trafić do gałęzi wersji kwartalnej, muszą być już scalone z główną gałęzią deweloperską GKI. Jeśli na przykład poprawka jest wymagana w przypadku ponownego przesłania android12-5.10-2022-09, musi być już scalona z android12-5.10.

• Musisz wybrać poprawki z głównej gałęzi deweloperskiej GKI i przesłać je do gałęzi wersji kwartalnej.

• W prośbie o ponowne sprawdzenie musisz przypisać jej priorytet (pilność). 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 przyporządkowanie priorytetu błędu do czasu rozwiązania problemu (ESRT):

  Priorytet	ESRT
  P0	2 dni robocze
  P1S	5 dni roboczych
  P2	10 dni roboczych
  P3	15 dni roboczych

• Musisz przesłać oddzielną prośbę o ponowne przesłanie w przypadku każdego oddziału. Jeśli na przykład ponowne losowanie jest potrzebne w przypadku obu symboli – android12-5.10-2022-08 i android12-5.10-2022-09 – musisz utworzyć 2 żądania ponownego losowania.

• Po udostępnieniu kompilacji i oznaczeniu prośby o ponowne utworzenie jako rozwiązanej nie należy ponownie otwierać prośby o ponowne utworzenie, aby dodać dodatkowe listy zmian. Jeśli są dodatkowe poprawki, które należy scalić, musisz przesłać nową prośbę o ponowne sprawdzenie.

• W przypadku każdego rozważanego CL dodaj te tagi:

  • Bug: identyfikator błędu musi być dodany do wiadomości o zatwierdzeniu dla każdego CL.
  • Change-Id: musi być identyczny z identyfikatorem zmiany w gałęzi podstawowej.

• Jeśli prośba o ponowne sprawdzenie 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 w ciągu 2 tygodni, błąd zostanie oznaczony jako Nie do naprawienia (nieaktualny).

Przesyłanie prośby o ponowne wygenerowanie

Ten diagram przedstawia proces ponownego losowania. Proces rozpoczyna się, gdy partner OEM (Ty) przesyła prośbę o ponowne wygenerowanie.

Rysunek 2. Proces ponownego sprawdzania

Aby rozpocząć proces respinu:

1. Wypełnij formularz prośby o ponowne wydanie GKI i natychmiast skontaktuj się z Technicznym menedżerem konta Google. Ten formularz tworzy zgłoszenie błędu dotyczące ponownego wydania GKI. Błędy związane z prośbami o ponowne utworzenie kompilacji są widoczne dla Ciebie (osoby, która zgłosiła błąd), zespołu GKI i określonych osób, które dodasz do listy kopii zgłoszenia błędu.
   • Jeśli masz już poprawkę, w prośbie wskaż przesłany w AOSP patch, abyśmy mogli go sprawdzić. Jeśli przesłanie poprawki nie jest możliwe, musi ona zostać dołączona do zgłoszenia jako plik tekstowy.
   • Jeśli nie masz rozwiązania, w zgłoszeniu musisz podać jak najwięcej informacji, w tym numer wersji jądra i dzienniki, aby Google mogło pomóc w rozwiązaniu problemu.
2. Zespół Google GKI sprawdza prośbę i zatwierdza ją lub odsyła do Ciebie, jeśli potrzebuje więcej informacji.
3. Po uzgodnieniu poprawki zespół Google GKI przeprowadza weryfikację kodu (CR+2). Rozpoczyna się okres ESRT. Zespół GKI scala, kompiluje, testuje pod kątem regresji i certyfikuje zmianę.
4. Plik binarny jest publikowany na stronie ci.android.com. Kończy się okres ESRT, a zespół Google GKI oznacza żądanie jako rozwiązane i odwołuje się do wersji respin. Kompilacja respin zostanie też opublikowana na stronie kompilacji wersji podstawowego obrazu jądra (GKI).

Wymagania dotyczące GKI

Gdzie uzyskać artefakty kompilacji

Artefakty wszystkich wersji można uzyskać na stronie ci.android.com.

Więcej informacji o CI, w tym wyniki testów, znajdziesz na panelu Android Continuous Integration.

Najczęstsze pytania

Oto odpowiedzi na najczęstsze pytania dotyczące procesu wydawania GKI.

Czy można utworzyć nowy plik binarny GKI na podstawie już opublikowanego GKI?

Tak, jest to tzw. ponowne losowanie. Proces tworzenia respinów jest obsługiwany, o ile wydana kompilacja GKI (na podstawie której zgłaszane jest żądanie respinu) jest zgodna z wymaganiami LTS w biuletynie bezpieczeństwa Androida (ASB).

Czy można odtworzyć pliki binarne GKI?

Tak, oto przykład:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Aby odtworzyć przykład, pobierz manifest_$id.xml i uruchom to polecenie:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Kopię artefaktu GKI możesz pobrać z out/.../dist.

Czy plik binarny GKI (w tym poprawka awaryjna) został utworzony na podstawie najnowszego kodu?

Nie. Ponowne kompilacje zawierają tylko poprawki, które są dodawane do wybranych kwartalnych certyfikowanych jąder. Te ponowne kompilacje zawierają wszystkie poprawki błędów blokujących uruchomienie zgłoszone do danego momentu przez producentów OEM korzystających z odpowiedniej podstawowej wersji kwartalnej. Poniżej znajdziesz przykład takiej sytuacji.

• OEM1 i OEM2 decydują się na użycie binarnej wersji GKI z listopada 2021 r.
• OEM1 i OEM2 wykrywają problemy, które wymagają poprawek. Te poprawki mogą się różnić lub być takie same.
• Wersje ponowne nałożone na plik binarny z listopada 2021 r. zawierają poprawki blokujące uruchamianie zgłoszone przez OEM1 i OEM2 w okresie ponownego przesyłania, ale nic więcej.
• Problemy wymienione w drugim punkcie są też uwzględniane w kolejnych kwartalnych wersjach GKI.

W październikowej wersji poprawionej znajdują się wszystkie poprawki przesłane przez producentów OEM, ale inne poprawki OEM mają na nas wpływ, ponieważ nie zostały specjalnie przetestowane na naszych produktach. Czy można uwzględnić tylko naszą poprawkę?

Nie jest to możliwe. Ścieżka ponownego przesyłania „dla każdego producenta OEM” nie jest skalowalna. Zespół GKI dokładnie sprawdza każdą zmianę wprowadzaną w wersjach respin i testuje ją na wszystkich dostępnych urządzeniach, zanim utworzy nową wersję. Jeśli zespół GKI stwierdzi, że problem dotyczy konkretnego producenta OEM, urządzenia lub modelu, może zadbać o to, aby kod dodany w ramach zmiany był wykonywany tylko na urządzeniu, modelu lub SKU, których dotyczy problem.

Główną zaletą ujednoliconych ponownych kompilacji jest to, że każde urządzenie korzystające z tej samej wersji bazowej może korzystać z poprawek wprowadzonych na innym urządzeniu, zwłaszcza jeśli wykryte błędy są ogólne i mają zastosowanie do wszystkich użytkowników. Przykładem tego są błędy w jądrze systemu wykryte podczas testów przeprowadzanych przez operatorów.

Czy w określonych sytuacjach Google udostępnia konkretne informacje o łatkach OEM i scenariuszach problemów, aby producenci OEM mogli ocenić wpływ i ryzyko wdrożenia tych łatek w swoich produktach?

Google nigdy nie wprowadzi zmiany w wersji ponownej, dopóki nie zrozumie problemu i nie zbierze wszystkich szczegółów. Jest to widoczne w dzienniku zmian (komunikat zatwierdzenia). Google nie ujawnia, jakiego konkretnie urządzenia dotyczy ten problem, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w dzienniku zmian.