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

Na tej stronie opisaliśmy sposób publikowania GKI, w tym cotygodniowych, miesięcznych i awaryjnych publikacji poza harmonogramem. Celem tego dokumentu jest przekazanie producentom OEM instrukcji, gdzie mogą uzyskać GKI, a także procedury wprowadzania pozapasmowych poprawek. Producenci OEM mogą też korzystać z oprogramowania GKI, aby dowiedzieć się więcej o tym, jak współpracować z zespołem odpowiedzialnym za jądro Androida w celu optymalizacji jądra GKI pod kątem ich produktów.

Częstotliwość publikowania GKI

GKI jest publikowany co miesiąc po zamrożeniu KMI.

GKI w Androidzie 13, 14 i 15

Ta tabela ma zastosowanie tylko do android13-5.10, android13-5.15 i android14-5.15.

Poniższa tabela dotyczy tylko tych wersji: android14-6.1 i android15-6.6.

Wersja GKI w Androidzie 12

Od maja 2024 r. wersje GKI w systemie android12-5.10 są publikowane co kwartał i publikowane w połowie miesiąca. Ta tabela ma zastosowanie tylko do android12-5.10.

Ważność kompilacji GKI dla OEM

Producenci OEM mogą korzystać z niedawno wydanej wersji interfejsu GKI na Androida. Producenci OEM mogą uruchamiać wersje z certyfikatem GKI, o ile są zgodne z wymaganiami LTS określonymi w biuletynie bezpieczeństwa Androida (ASB).

Cotygodniowe informacje o wersjach rozwojowych

Pliki binarne GKI są dostępne do samodzielnego pobrania z Androida CI, gdy tylko zmiany zostaną scalone. Kompilacje tygodniowe nie będą certyfikowane, ale można ich używać jako podstawy do tworzenia i testowania. Tygodniowych kompilacji nie można używać w przypadku kompilacji na urządzenia produkcyjne przeznaczone dla użytkowników.

Miesięczne certyfikowane wersje

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

Co miesiąc po dacie granicznej sprawdzania (zwykle jest to drugi cotygodniowy kompilowany pakiet) wybierany jest kandydat na miesięczną wersję GKI (niecertyfikowany). Po wybraniu wersji miesięcznej, która kandyduje do publikacji w danym miesiącu, nowe zmiany nie zostaną zaakceptowane w wersji w danym miesiącu. W okresie testów zamkniętych można wprowadzać tylko poprawki błędów, które powodują niepowodzenie testu. Kandydat do wydania przechodzi kontrolę jakości (opisaną w sekcji dotyczącej kwalifikacji GKI), by mieć pewność, że testy zgodności GSI+GKI kompilują kompilację z urządzeniem referencyjnym i mątwą.

Rysunek 1. Harmonogram wersji GKI

Proces odzyskiwania w sytuacjach awaryjnych

Respin to proces ponownego wygenerowania, ponownego skompilowania, ponownego przetestowania i ponownego certyfikowania pliku binarnego po publicznej wersji jądra GKI. Możesz poprosić o ponowne przesłanie certyfikowanego binarnego pliku wykonywalnego w jednym z tych przypadków:

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

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

Wytyczne dotyczące żądań ponownego losowania

Zanim poprosisz o ponowne przetworzenie, pamiętaj o tych wytycznych:

• Przypinania są dozwolone tylko w gałęziach wersji po opublikowaniu pierwszej publicznej wersji miesięcznej kompilacji.

• Prośby o ponowne wydanie są przyjmowane tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od pierwotnego publicznego wydania. Po upływie 6 miesięcy gałęzie mogą być ponownie opublikowane tylko w przypadku poprawek zabezpieczeń wymienionych w Informacjach o bezpieczeństwie Androida.

• Jeśli wymagania LTS określone w biuletynie bezpieczeństwa Androida (ASB) powodują, że gałąź nie jest zgodna, zostaje ona wycofana. Prośby o ponowne losowanie w przypadku odrzuconych gałęzi nie są akceptowane. Data wycofania danej gałęzi wersji GKI jest podana w miesięcznych informacjach o kompilacji wersji GKI w sekcji Wersje. Aby ułatwić planowanie na przyszłość, wymagania dotyczące LTS 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 odinstalowań po 1 maja 2024 r., ponieważ gałąź android12-5.10-2023-07 (5.10.177) nie jest zgodna z wymaganiami LTS zawartymi w standardzie ASB-2024-05.

• Ponownie opublikowane wersje są przeznaczone tylko do pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki do istniejącej funkcji.

• Wszystkie poprawki trafiające do gałęzi miesięcznego wydania muszą zostać scalone z główną gałęzią rozwoju GKI. Jeśli na przykład poprawka jest wymagana do kodu odpowiedzi android12-5.10-2022-09, musi zostać już scalona z elementem android12-5.10.

• Musisz wybrać poprawki z głównej gałęzi GKI i przesłać je do gałęzi miesięcznego wydania.

• W prośbie o ponowne przesłanie musisz przypisać priorytet (pilność) do prośby. Dzięki temu zespół GKI może lepiej i szybciej pomagać partnerom. W przypadku zgłoszeń o charakterze krytycznym lub pilnych oznacz je priorytetem P0. W przypadku zgłoszeń P0 i P1 musisz też uzasadnić pilność. W tabeli poniżej znajdziesz powiązanie priorytetu błędu z czasem rozwiązania (ESRT):

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

• Musisz przesłać osobną prośbę o ponowne rozpatrzenie dla każdej gałęzi wersji. Jeśli na przykład odwrotność jest potrzebna zarówno dla android12-5.10-2022-08, jak i android12-5.10-2022-09, musisz utworzyć 2 żądania respin.

• Po przesłaniu wersji i oznaczyniu prośby o ponowne przesłanie jako rozwiązanej nie należy ponownie otwierać prośby o ponowne przesłanie, aby dodać dodatkowe CL. Jeśli są dodatkowe łaty, które trzeba scalić, musisz przesłać nową prośbę o przesłanie.

• Do każdego z rozważanych poziomów świadczeń dodaj te tagi.

  • Bug: identyfikator błędu musi zostać dodany do wiadomości o zapisu dla każdego CL.
  • Change-Id: musi być taki sam jak identyfikator zmiany zmiany gałęzi podstawowej.

• Jeśli żądanie odpowiedzi wymaga odpowiedzi i 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 naprawimy (nieaktualne).

Przesyłanie prośby o ponowne przeanalizowanie

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

Rysunek 2. Proces ponownego przesyłania

Aby rozpocząć proces ponownego losowania:

1. Wypełnij formularz prośby o przesłanie GKI i natychmiast skontaktuj się ze swoim opiekunem klienta w Google. Ten formularz tworzy błąd prośby o ponowne przesłanie danych GKI. Błędy dotyczące prośby o ponowne rozdanie są widoczne dla Ciebie (osoby przesyłającej prośbę), zespołu GKI i określonych osób, które dodasz do listy CC błędu.
   • Jeśli masz już poprawkę, prośba powinna wskazywać na przesłanie poprawki w AOSP, aby Google mogło ją sprawdzić. Jeśli nie można przesłać poprawki, należy ją załączyć do prośby jako plik tekstowy.
   • Jeśli nie masz rozwiązania, zgłoszenie musi zawierać jak najwięcej informacji, w tym numer wersji jądra i logi, aby zespół Google mógł pomóc w rozwiązywaniu problemu.
2. Zespół Google GKI sprawdza prośbę i zatwierdza ją lub przypisuje ją Tobie, jeśli potrzebne są dodatkowe informacje.
3. Po uzgodnieniu poprawki zespół Google ds. interfejsów graficznych sprawdza kod (CR+2) pod kątem zmian. Sprawdzenie rozpoczyna okres ESRT. Zespół GKI łączy, tworzy, testuje regresję i certyfikuje zmiany.
4. Binarny plik jest udostępniany na stronie ci.android.com. Okres czasu spełnienia wymagań specyfikacji kończy się, a zespół Google GKI oznacza zgłoszenie jako rozwiązane i odwołuje się do kompilacji ponownego przesłania. Kompilacja respin zostanie również opublikowana na stronie kompilacji wersji obrazu Generic Kernel Image (GKI).

Kwalifikacje GKI

Gdzie można uzyskać artefakty kompilacji

Artefakty wszystkich wersji można pobrać ze strony ci.android.com.

Więcej informacji o CI, w tym wyniki testów, znajdziesz na panelu ciągłego integrowania aplikacji na Androida.

Najczęstsze pytania

Oto kilka najczęstszych pytań dotyczących procesu publikowania GKI.

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

Tak, nazywa się to ponownym losowaniem. Proces ponownego przesłania jest obsługiwany, o ile opublikowana wersja GKI (w której przypadku żąda się ponownego przesłania) jest zgodna z wymaganiami LTS określonymi w komunikatach o błędach dotyczących 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 awaryjnego spinania) został utworzony na podstawie najnowszej bazy kodu?

Nie. Ponownie opublikowane wersje zawierają tylko łaty, które zostały dodane do wybranych miesięcznych certyfikowanych jąder. Te wersje zawierają wszystkie poprawki błędów blokujących uruchomienie, które zostały zgłoszone przez producentów OEM do tej pory i które korzystają z odpowiedniej podstawowej wersji miesięcznej. Poniższy przykład ilustruje przebieg tego typu scenariuszy.

• OEM1 i OEM2 decydują się na użycie wersji binarnej GKI z listopada 2021 r.
• OEM1 i OEM2 znajdują problemy, które wymagają poprawek do pomocy. Te łatki mogą być różne lub takie same.
• W wersjach z respinem na podstawie binarnej wersji z listopada 2021 r. znajdują się naprawki blokujące uruchomienie zgłoszone przez OEM1 i OEM2 w okresie respinu, ale nic więcej.
• Problemy wymienione w drugim punkcie są również uwzględniane w kolejnych miesięcznych wersjach GKI.

W październiku wszystkie poprawki OEM zostały zgłoszone, ale dotyczy to też innych łatek OEM, ponieważ nie zostały one specjalnie przetestowane z naszymi produktami. Czy można uwzględnić tylko nasz pakiet poprawek?

Nie jest to możliwe. Ścieżka ponownego testowania „na podstawie OEM” nie jest skalowalna. Zamiast tego zespół GKI przed utworzeniem nowej kompilacji sprawdza każdą zmianę, która wchodzi w skład kompilacji, i testuje je na całym dostępnym sprzęcie. Jeśli zespół GKI stwierdzi, że problem dotyczy konkretnego OEM-u, urządzenia lub modelu, może zadbać o to, aby kod dodany przez zmianę był wykonywany tylko na urządzeniu, modelu lub SKU, którego dotyczy.

Główną zaletą jednolitej wersji to, że każde urządzenie korzystające z tej samej bazy wersji korzysta z zalet innych urządzeń, zwłaszcza jeśli znalezione błędy są ogólne i dotyczą wszystkich użytkowników. Błędy w rdzeniu jądra wykrywane podczas testów operatora są konkretnym przykładem tej koncepcji.

Czy są sytuacje, w których Google udostępnia konkretne informacje o łatkach OEM i scenariuszach problemów, aby OEM mógł ocenić wpływ i ryzyko wdrożenia łatek w swoich produktach?

Google nigdy nie doda zmiany do wersji respin, dopóki nie zrozumiemy problemu i nie zbierzemy wszystkich szczegółów. Jest on widoczny w changelogu (wiadomości commit). Google nie podaje, jakiego konkretnie urządzenia to dotyczy, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w dzienniku zmian.