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

Na tej stronie opisujemy sposób publikowania GKI, w tym cotygodniowych, kwartalnych i awaryjnych wersji poza harmonogramem. Celem tego dokumentu jest przedstawienie OEM-om informacji o tym, gdzie można pobrać GKI, oraz procesu wprowadzania poprawek awaryjnych poza pasmem. 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 kwartał po zamrożeniu KMI.

Ważność kompilacji GKI dla OEM

Producenci OEM mogą korzystać z niedawno wydanej wersji 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 wersje deweloperskie

Pliki binarne GKI są dostępne do samodzielnego pobrania z Androida CI, gdy zmiany zostaną scalone. Kompilacje tygodniowe nie będą certyfikowane, ale można ich używać jako podstawy do tworzenia i testowania. Wersje tygodniowe nie mogą być używane do tworzenia wersji na urządzenia produkcyjne dla użytkowników końcowych.

Kwartalne certyfikowane wersje

Co 3 miesiące GKI udostępnia testowane wersje boot.img, które zawierają certyfikat wstawiony przez Google, potwierdzający, że pliki binarne zostały utworzone na podstawie znanego podstawowego kodu źródłowego.

Co kwartał wybieramy kandydata do kwartalnego wydania GKI (bez certyfikatu) po dacie granicznej sprawdzania, która zwykle jest drugim cotygodniowym kompilacją w danym miesiącu. Po wybraniu kandydata do wydania kwartalnego nowe zmiany nie będą akceptowane w przypadku wydania w danym miesiącu. W okresie testów zamkniętych można wprowadzać tylko poprawki błędów, które powodują niepowodzenie testu. Wersja kandydata do wydania przechodzi kontrolę jakości (opisaną w sekcji kwalifikacji GKI), aby zapewnić pozytywne wyniki testów zgodności na kompilacji GSI+GKI z urządzeniem referencyjnym i w systemie Cuttlyfish.

Rysunek 1. Harmonogram wersji interfejsu GKI

Proces ponownego losowania

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

• Aby zaktualizować listę symboli:
• Aby zastosować poprawkę błędu, w tym błędów znalezionych podczas zatwierdzenia testów laboratoryjnych 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 żądania ponownego losowania

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

• Ponownie przypiętym wersjom można nadawać priorytet tylko w gałęziach wersji po tym, jak pierwsza publiczna wersja kwartalnego kompilacji została opublikowana.

• 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 komunikatach o błędach dotyczących bezpieczeństwa Androida (ASB) powodują, że gałąź nie jest zgodna, zostaje ona wycofana. Prośby o ponowne losowanie w przypadku gałęzi wycofanych nie są akceptowane. Data wycofania danej gałęzi wersji GKI jest podana w kwartalnych 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 ponownych testów po 1 maja 2024 r., ponieważ gałąź android12-5.10-2023-07 (5.10.177) nie spełnia wymagań LTS z ASB-2024-05.

• Ponownie przypięte pliki dotyczą tylko pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki do istniejącej funkcji.

• Wszystkie poprawki wprowadzane do gałęzi comiesięcznych wersji muszą zostać scalone z główną gałęzią rozwoju GKI. Jeśli na przykład do ponownego opublikowania wersji android12-5.10-2022-09 wymagana jest poprawka, musi ona zostać scalona z wersją android12-5.10.

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

• 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ć oddzielną prośbę o ponowne rozpatrzenie w przypadku każdej gałęzi wersji. Jeśli na przykład potrzebna jest ponowna próba w przypadku zarówno android12-5.10-2022-08, jak i android12-5.10-2022-09, musisz utworzyć 2 żądania ponownej próby.

• Po przesłaniu wersji i oznaczysz prośbę o ponowne przesłanie jako rozwiązaną, nie otwieraj ponownie prośby o ponowne przesłanie, aby dodać dodatkowe poziomy testów. 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 kompetencji dodaj te tagi.

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

• Jeśli prośba o ponowne przesłanie wymaga Twojej odpowiedzi, a nie odpowiesz w ciągu trzech dni roboczych, priorytet zostanie obniżony o jeden 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 przesłania

Aby rozpocząć proces ponownego losowania:

1. Wypełnij formularz prośby o rezygnację z Google KI 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 rozpatrzy prośbę i zatwierdzi ją lub przekaże ją z powrotem do Ciebie, jeśli będzie potrzebować dodatkowych informacji.
3. Po uzgodnieniu poprawki zespół Google ds. interfejsów graficznych sprawdza kod (CR+2) pod kątem zmian. Sprawdzanie rozpoczyna okres ESRT. Zespół GKI łączy, tworzy, testuje regresję i certyfikuje zmiany.
4. Plik binarny jest udostępniany na stronie ci.android.com. Okres czasu spełnienia wymagań specyfikacji kończy się, a zespół Google GKI oznacza prośbę jako rozwiązaną i odwołuje się do kompilacji respin. 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 uruchomienia jest obsługiwany, o ile opublikowana wersja GKI (w której przypadku żąda się ponownego uruchomienia) 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 binarny plik GKI (w tym poprawka do wersji awaryjnej) został utworzony na podstawie najnowszej wersji kodu źródłowego?

Nie. Respins zawierają tylko łaty, które zostały dodane do wybranych kwartalnych certyfikowanych jąder. Te wersje zawierają wszystkie poprawki błędów uniemożliwiających wdrożenie, które zostały zgłoszone przez producentów OEM do tej pory i które korzystają z odpowiedniej podstawowej wersji kwartalnej. Poniżej znajdziesz przykład tego typu scenariusza.

• OEM1 i OEM2 decydują się na użycie wersji binarnej GKI z listopada 2021 r.
• OEM1 i OEM2 znajdują problemy, które wymagają łatek. Te łatki mogą być różne lub takie same.
• W wersjach z respinu 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 2. punkcie są również uwzględniane w kolejnych kwartalnych wersjach GKI.

W październikowej wersji rozwojowej są wszystkie łaty, które zostały przesłane przez OEM, ale inne łaty OEM mają na nas wpływ, ponieważ nie zostały przetestowane pod kątem naszych produktów. Czy można uwzględnić tylko naszą łatkę?

Nie jest to możliwe. Ścieżka ponownego testowania „na podstawie OEM” nie jest skalowalna. Zamiast tego zespół GKI dokładnie sprawdza każdą zmianę wprowadzoną w wersji ponownego uruchomienia kompilacji i testuje ją na wszystkich dostępnych urządzeniach, zanim utworzy nową kompilację. Jeśli zespół GKI stwierdzi, że problem dotyczy konkretnego OEM, 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 respin jest 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. Przykładem tego są błędy w jądrze znalezione podczas testów operatora.

Czy są sytuacje, w których Google udostępnia konkretne informacje o łatkach OEM i scenariuszach problemów, aby producenci OEM mogli 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 to widoczne w changelogu (wiadomość commit). Google nie ujawnia, na które urządzenia ma wpływ dany problem, ale producenci OEM mogą zawsze znaleźć opis problemu i jego rozwiązanie w zmianach w wersji.