Na tej stronie opisaliśmy sposób publikowania GKI, w tym cotygodniowych, miesięcznych i awaryjnych publikacji 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 rozwoju 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
Poniższa tabela dotyczy tylko kolumn android13-5.10, android13-5.15 i android14-5.15.
| Comiesięczne kompilacje z certyfikatem GKI | Termin zameldowania | Data gotowości do wstępnego wczytania GKI | Czy to się zgadza? |
|---|---|---|---|
| Listopad | 11 listopada 2024 r. | 27 listopada 2024 r. | Tak |
| Styczeń | 14 stycznia 2025 r. | 31 stycznia 2025 r. | Tak |
| Marzec | 14 marca 2025 r. | 31 marca 2025 r. | Tak |
Poniższa tabela dotyczy tylko tych wersji:
android14-6.1
i
android15-6.6.
| Comiesięczne kompilacje z certyfikatem GKI | Termin zameldowania | Data gotowości do wstępnego wczytania GKI | Czy to się zgadza? |
|---|---|---|---|
| Październik | 1 października 2024 r. | 14 października 2024 r. | Tak |
| Listopad | 1 listopada 2024 roku | 15 listopada 2024 r. | Tak |
| Grudzień | 2 grudnia 2024 r. | 16 grudnia 2024 r. | Tak |
| Styczeń | 6 stycznia 2025 r. | 22 stycznia 2025 r. | Tak |
Wersja GKI Androida 12
Po maju 2024 r. wersje android12-5.10 GKI będą wydawane co kwartał i publikowane w połowie miesiąca.
Poniższa tabela dotyczy tylko android12-5.10.
| Comiesięczne kompilacje z certyfikatem GKI | Termin zameldowania | Data gotowości do wstępnego wczytania GKI | Czy to się zgadza? |
|---|---|---|---|
| Listopad | 1 listopada 2024 roku | 15 listopada 2024 r. | Tak |
| Luty | 3 lutego 2025 r. | 17 lutego 2025 r. | Tak |
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 wersje deweloperskie
Wersje są testowane za pomocą Cuttlefish, aby zapewnić minimalną jakość.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.
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 kandydata do wydania miesięcznego nowe zmiany nie będą akceptowane w przypadku tej wersji miesięcznej. 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 użyciem urządzenia referencyjnego i testów cuttlefish.
Rysunek 1. Harmonogram wersji interfejsu GKI
Proces ponownego losowania
Respin to proces ponownego wygenerowania, ponownego skompilowania, ponownego przetestowania i ponownego certyfikowania pliku 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 w laboratorium 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ą wydania 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:
Ponownie przypiętym wersjom można przypisać tylko gałęzie wersji po pierwotnym publicznym wydaniu wersji miesięcznej.
Prośby o ponowne opublikowanie 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 gałęzi wycofanych 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 ponownych wysyłek po 1 maja 2024 r., ponieważ gałąźandroid12-5.10-2023-07(5.10.177) nie spełnia wymagań LTS opisanych w dokumencie 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 do ponownego uruchomienia
android12-5.10-2022-09wymagana jest poprawka, musi ona zostać scalona zandroid12-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 potrzebna jest ponowna próba w przypadku zarówno
android12-5.10-2022-08, jak iandroid12-5.10-2022-09, musisz utworzyć 2 żądania ponownej próby.Po przesłaniu wersji i oznaczeniu 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 kompetencji dodaj te tagi.
Bug: identyfikator błędu musi zostać dodany do wiadomości o zapisu dla każdego CL.Change-Id: musi być identyczny z identyfikatorem zmiany w gałęzi podstawowej.
Jeśli prośba o ponowne przesłanie wymaga odpowiedzi, a nie odpowiesz w ciągu 3 dni roboczych, priorytet zostanie obniżony o 1 poziom (np. z P0 na P1). Jeśli nie odpowiesz w ciągu 2 tygodni, błąd zostanie oznaczony jako Nie naprawimy (nieaktualny).
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:
- 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 roztoczenie 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śmy mogli pomóc w rozwiązywaniu problemu.
- Zespół Google GKI sprawdza prośbę i zatwierdza ją lub zwraca ją do Ciebie, jeśli potrzebuje więcej informacji.
- Po uzgodnieniu rozwiązania zespół Google ds. interfejsów graficznych (CR+2) sprawdza zmiany. Sprawdzenie rozpoczyna okres ESRT. Zespół GKI łączy, tworzy, testuje regresję i certyfikuje zmiany.
- 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 respin. Kompilacja respin zostanie również opublikowana na stronie kompilacji wersji obrazu Generic Kernel Image (GKI).
Kwalifikacje GKI
| Typy wersji GKI | Egzekwowanie jakości | Notes |
|---|---|---|
| Co tydzień | Testowanie Mątwy
|
|
| Miesięcznie (certyfikowane) | Testowanie Mątwy
|
|
| Respins (certyfikowane) | Testowanie Mątwy
|
|
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 kodu 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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_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. 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ż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ą poprawek. 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 2 pkt. są również uwzględniane w kolejnych miesięcznych wersjach GKI.
W październiczym respinie są wszystkie łaty, które przesłał 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 pakiet poprawek?
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, a przed utworzeniem nowej kompilacji testuje ją na wszystkich dostępnych urządzeniach. 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 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 to widoczne w changelogu (wiadomości 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 historii zmian.