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 danego 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 – zgodnie z opisem 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

Wymagania dotyczące GKI

Gdzie 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 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 binarny plik GKI (w tym poprawka awaryjna) został utworzony na podstawie najnowszego kodu?

Nie. W przypadku ponownego wydania uwzględniane są 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, jak może wyglądać taka sytuacja.

• 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 wydania, 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 wydania „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.