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

Na tej stronie opisujemy, jak wydawany jest GKI, w tym kwartalne i nadzwyczajne wydania awaryjne. Celem tej strony jest przedstawienie producentom OEM wskazówek dotyczących tego, skąd pobrać GKI, oraz procesu wprowadzania poprawek awaryjnych poza pasmem. Producenci OEM mogą też skorzystać z programowania GKI, aby dowiedzieć się więcej o tym, jak mogą współpracować z zespołem jądra Androida nad optymalizacją jądra GKI pod kątem swoich produktów.

Częstotliwość wydawania wersji GKI

GKI jest wydawany 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 dotyczącymi jądra z długoterminowym wsparciem (LTS) określonymi w Biuletynie bezpieczeństwa w Androidzie (ASB).

Wersje GKI 16 KB

Zespół ds. wersji GKI obsługuje wersje GKI 16 KB z taką samą kwartalną częstotliwością, testami kwalifikacyjnymi i procesem ponownego uruchamiania jak w przypadku wersji GKI 4 KB:

• Obsługiwane gałęzie:
  • android15-6.6 (od stycznia 2026 r.)
  • android16-6.12 (od marca 2026 r.)
  • android17-6.18 (od czerwca 2026 r.)
• Parzystość i certyfikacja kompilacji: pliki binarne GKI o rozmiarze 16 KB używają tego samego tagu źródłowego i identyfikatora kompilacji jądra co odpowiadająca im wersja GKI o rozmiarze 4 KB. Do 2027 r. karta Kompilacja do publikacji 16 KB na stronach kompilacji do publikacji android15-6.6, android16-6.12 i android17-6.18 będzie zawierać niecertyfikowane pliki binarne GKI 16 KB. Nie musisz aktualizować jąder systemu 4 KB i 16 KB jednocześnie, ale zalecamy to zrobić.
• Ponowne kompilacje na żądanie: możesz poprosić o ponowne kompilacje GKI o rozmiarze 16 KB, korzystając z tego samego procesu i formularza co w przypadku kompilacji 4 KB.

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.

Co kwartał po dacie granicznej przesyłania kodu wybierana jest wersja kandydująca do publikacji GKI (niecertyfikowana). Po wybraniu wersji kandydującej do publikacji kwartalnej nowe zmiany nie będą akceptowane w wydaniu z danego miesiąca. W tym okresie można wprowadzać tylko poprawki błędów, które powodują niepowodzenie testu. Wersja kandydująca do publikacji jest poddawana zapewnianiu jakości – zgodnie z opisem w sekcji dotyczącej kwalifikacji GKI – aby sprawdzić, czy testy zgodności są zaliczane w przypadku kompilacji GSI+GKI na urządzeniu referencyjnym i na platformie Cuttlefish.

Rysunek 1. Harmonogram wersji GKI

Kwalifikacje GKI

Gdzie można uzyskać artefakty kompilacji

Producenci OEM mogą uzyskać artefakty wszystkich wersji na stronie ci.android.com.

Więcej informacji o trybie ciągłej integracji, w tym wyniki testów, znajdziesz w panelu Android Continuous Integration.

Najczęstsze pytania

Oto odpowiedzi na najczęściej zadawane pytania dotyczące procesu wydawania GKI.

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

Tak, jest to tzw. ponowne uruchomienie. Proces respin jest obsługiwany, o ile opublikowana kompilacja GKI (w przypadku której żądany jest respin) jest zgodna z wymaganiami LTS określonymi w Biuletynie bezpieczeństwa w Androidzie (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 plik 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 najnowszej bazy kodu?

Nie. Respins zawierają tylko poprawki, które są nałożone na wybrane kwartalne certyfikowane jądra. Te wersje zawierają wszystkie poprawki błędów blokujących wprowadzenie na rynek, które zostały zgłoszone do danego momentu przez producentów OEM korzystających z odpowiedniej podstawowej wersji kwartalnej. Poniżej znajdziesz przykład takiego scenariusza.

• Producenci OEM1 i OEM2 decydują się na użycie wersji binarnej GKI z listopada 2021 r.
• OEM1 i OEM2 znajdują problemy, które wymagają poprawek. Te fragmenty mogą być różne lub takie same.
• Wersje z poprawkami na podstawie wersji binarnej z listopada 2021 r. zawierają poprawki blokujące uruchomienie zgłoszone przez OEM1 i OEM2 w okresie poprawek, ale nic więcej.
• Problemy wymienione w drugim punkcie są też uwzględniane w kolejnych kwartalnych wersjach GKI.

Wersja z października zawiera wszystkie poprawki przesłane przez producentów OEM, ale inne poprawki producentów OEM mają na nas wpływ, ponieważ nie zostały przetestowane z naszymi usługami. Czy można uwzględnić tylko naszą łatkę?

Nie jest to możliwe. Ścieżka ponownego uruchomienia dla poszczególnych producentów OEM nie jest skalowalna. Zespół GKI dokładnie sprawdza każdą zmianę, która trafia do wersji 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 sprawdzić, czy kod dodany przez zmianę jest wykonywany tylko na urządzeniu, modelu lub SKU, którego dotyczy problem.

Główną zaletą ujednoliconych wersji jest to, że każde urządzenie korzystające z tej samej wersji bazowej korzysta z innych, zwłaszcza jeśli wykryte błędy są ogólne i dotyczą wszystkich użytkowników. Przykładem tego są błędy w jądrze systemu znalezione podczas testów przeprowadzanych przez operatorów.

Czy zdarzają się sytuacje, w których Google udostępnia szczegółowe informacje o poprawkach OEM i scenariuszach problemów, aby producenci OEM mogli ocenić wpływ i ryzyko związane z wdrożeniem poprawek w swoich produktach?

Google nigdy nie wprowadzi zmiany w wersji ponownej kompilacji, dopóki zespół GKI nie zrozumie problemu i nie zbierze wszystkich szczegółów. Możesz to sprawdzić w dzienniku zmian (komunikat o zatwierdzeniu). Google nie ujawnia, których urządzeń dotyczy problem, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w liście zmian.