Na tej stronie opisujemy sposób udostępniania GKI, w tym cotygodniowe, kwartalne i awaryjne wersje poza pasmem. Celem tego dokumentu jest przekazanie producentom OEM wskazówek dotyczących tego, gdzie można pobrać GKI, oraz 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.
Harmonogram wydań GKI
GKI jest udostępniany co kwartał po zamrożeniu KMI.
| Miesiąc premiery | a12-5.10 | a13-5.10 | a13-5.15 | a14-5.15 | a14-6.1 | a15-6.6 | a16-6.12 | |
|---|---|---|---|---|---|---|---|---|
| Czerwiec 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
16–30 czerwca |
2 czerwca 16 czerwca |
2 czerwca 16 czerwca |
2–18 czerwca |
|||
| Lipiec 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
16–31 lipca |
16–31 lipca |
16–31 lipca |
1–15 lipca |
1–15 lipca |
1–15 lipca |
|
| Sierpień 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
1–15 sierpnia |
1–15 sierpnia |
1–15 sierpnia |
||||
| Wrzesień 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
16 września* 30 września* |
16–30 września |
1 września 15 września |
1 września 15 września |
1 września 15 września |
||
| Październik 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
16–31 października |
1–15 października |
1–15 października |
||||
| Listopad 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
|||||||
| Grudzień 2025 |
Odprawa zakończona Wstępne wczytywanie GKI gotowe |
1 grudnia 15 grudnia |
1 grudnia* 15 grudnia* |
1 grudnia 15 grudnia |
1 grudnia 15 grudnia |
|||
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.
Cotygodniowe wersje deweloperskie
Wersje są testowane za pomocą Cuttlefish, aby upewnić się, że spełniają minimalne wymagania jakościowe.Pliki binarne GKI są dostępne w ramach samoobsługi w Android CI po scaleniu zmian. Kompilacje tygodniowe nie będą certyfikowane, ale można ich używać jako punktu odniesienia do programowania i testowania. Wersji tygodniowych nie można używać w przypadku wersji produkcyjnych na urządzenia użytkowników.
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 kodu źródłowego.
Co kwartał wybierana jest kandydacka wersja 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 tego 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 opisaną 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
Proces ponownego sprawdzania w sytuacji awaryjnej
Ponowne kompilowanie to proces ponownego scalania, kompilowania, testowania i ponownego certyfikowania pliku binarnego po publicznym udostępnieniu jądra GKI. Możesz poprosić o ponowne wygenerowanie certyfikowanego pliku binarnego w jednej z tych sytuacji:
- Aby zaktualizować listę symboli:
- Aby zastosować poprawkę błędu, w tym błędów wykrytych podczas zatwierdzania przez laboratorium operatora.
- Aby dodać element dostawcy:
- Aby zastosować poprawkę do istniejącej funkcji.
- Aby zastosować poprawkę zabezpieczeń (po 6 miesiącach).
Poprawki zabezpieczeń są automatycznie scalane z gałęzią wersji przez maksymalnie 6 miesięcy od jej wydania. Po upływie 6 miesięcy musisz poprosić o ponowne przesłanie, aby zastosować poprawki zabezpieczeń w gałęzi.
Wytyczne dotyczące żądań ponownego wygenerowania
Zanim poprosisz o ponowne sprawdzenie, zapoznaj się z tymi wytycznymi:
Ponowne kompilacje są dozwolone tylko w przypadku gałęzi wersji po początkowym udostępnieniu publicznym kwartalnej kompilacji.
Prośby o ponowne przesłanie są akceptowane tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od pierwszej publicznej wersji. Po 6 miesiącach gałęzie kwalifikują się do ponownego przesłania tylko w przypadku poprawek zabezpieczeń wymienionych w Biuletynie bezpieczeństwa w Androidzie.
Jeśli wymagania LTS określone w Biuletynie bezpieczeństwa w Androidzie sprawiają, że gałąź jest niezgodna, zostaje ona wycofana. Prośby o ponowne sprawdzenie w przypadku wycofanych gałęzi nie są akceptowane. Data wycofania danej gałęzi wersji GKI jest podana w kwartalnych informacjach o wersji GKI w sekcji Wersje. Wymagania dotyczące długoterminowego wsparcia są aktualizowane w maju i listopadzie każdego roku. Na przykład gałąź
android12-5.10-2023-07(5.10.177) nie jest obsługiwana w przypadku ponownych kompilacji po 1 maja 2024 r., ponieważ gałąźandroid12-5.10-2023-07(5.10.177) nie spełnia wymagań LTS określonych w ASB-2024-05.Ponowne przesłanie jest możliwe tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki do istniejącej funkcji.
Wszystkie poprawki, które mają trafić do gałęzi wersji kwartalnej, muszą być już scalone z główną gałęzią rozwoju GKI. Jeśli na przykład poprawka jest wymagana w przypadku ponownego przesłania
android12-5.10-2022-09, musi być już scalona zandroid12-5.10.Musisz wybrać poprawki z głównej gałęzi deweloperskiej GKI i przesłać je do gałęzi wersji kwartalnej.
W prośbie o ponowne sprawdzenie musisz przypisać jej priorytet (pilność). Ten priorytet pomaga zespołowi GKI w terminowym udzielaniu pomocy partnerom. W przypadku zgłoszeń o znaczeniu krytycznym lub pilnych oznacz priorytet jako P0. W przypadku zgłoszeń o priorytecie P0 i P1 musisz też uzasadnić pilność sprawy. W tabeli poniżej znajdziesz przyporządkowanie priorytetu błędu do czasu rozwiązania problemu (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 przesłanie w przypadku każdego oddziału. Jeśli na przykład ponowne losowanie jest potrzebne w przypadku obu symboli –
android12-5.10-2022-08iandroid12-5.10-2022-09– musisz utworzyć 2 żądania ponownego losowania.Po udostępnieniu kompilacji i oznaczeniu prośby o ponowne utworzenie jako rozwiązanej nie należy ponownie otwierać prośby o ponowne utworzenie, aby dodać dodatkowe listy zmian. Jeśli są dodatkowe poprawki, które należy scalić, musisz przesłać nową prośbę o ponowne sprawdzenie.
W przypadku każdego rozpatrywanego CL dodaj te tagi:
Bug: identyfikator błędu musi być dodany do wiadomości o zatwierdzeniu dla każdego CL.Change-Id: musi być identyczny z identyfikatorem zmiany w gałęzi podstawowej.
Jeśli prośba o ponowne sprawdzenie wymaga Twojej odpowiedzi, a 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 do naprawienia (nieaktualny).
Przesyłanie prośby o ponowne sprawdzenie
Ten diagram przedstawia proces ponownego losowania. Proces rozpoczyna się, gdy partner OEM (Ty) przesyła prośbę o ponowne wygenerowanie.
Rysunek 2. Proces ponownego sprawdzania
Aby rozpocząć proces ponownego losowania:
- Wypełnij formularz prośby o ponowne wydanie GKI i natychmiast skontaktuj się z Technicznym menedżerem konta Google. Ten formularz
tworzy zgłoszenie błędu dotyczące ponownego generowania GKI. Błędy związane z prośbami o ponowne utworzenie kompilacji są widoczne dla Ciebie (osoby, która zgłosiła błąd), zespołu GKI i określonych osób, które dodasz do listy kopii zgłoszenia błędu.
- Jeśli masz już poprawkę, w prośbie wskaż przesłany w AOSP patch, abyśmy mogli go sprawdzić. Jeśli przesłanie poprawki nie jest możliwe, musi ona zostać dołączona do zgłoszenia jako plik tekstowy.
- Jeśli nie masz rozwiązania, w zgłoszeniu musisz podać jak najwięcej informacji, w tym numer wersji jądra i dzienniki, aby Google mogło pomóc w rozwiązaniu problemu.
- Zespół Google GKI sprawdza prośbę i zatwierdza ją lub odsyła do Ciebie, jeśli potrzebuje więcej informacji.
- Po uzgodnieniu poprawki zespół Google GKI przeprowadza weryfikację kodu (CR+2). Rozpoczyna się okres ESRT. Zespół GKI scala, kompiluje, testuje pod kątem regresji i certyfikuje zmianę.
- Plik binarny jest publikowany na stronie ci.android.com. Kończy się okres ESRT, a zespół Google GKI oznacza żądanie jako rozwiązane i odwołuje się do wersji respin. Kompilacja ponowna zostanie też opublikowana na stronie kompilacji wersji obrazu jądra ogólnego (GKI).
Wymagania dotyczące GKI
| Rodzaje kompilacji GKI | Egzekwowanie jakości | Notes |
|---|---|---|
| Co tydzień | Testowanie na urządzeniu Cuttlefish
|
|
| Kwartalny (certyfikowany) | Testowanie na urządzeniu Cuttlefish
|
|
| Ponowne spiny (certyfikowane) | Testowanie na urządzeniu Cuttlefish
|
|
Gdzie uzyskać artefakty kompilacji
Artefakty wszystkich wersji można uzyskać na stronie 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 modyfikacji kompilacji jest obsługiwany, dopóki wydana kompilacja GKI (na podstawie której zgłaszana jest prośba o modyfikację) 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 plik 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 plik binarny GKI (w tym poprawka awaryjna) został utworzony na podstawie najnowszego kodu?
Nie. Ponowne kompilacje zawierają tylko poprawki, które są dodawane do wybranych kwartalnych certyfikowanych jąder. Te ponowne wersje zawierają wszystkie poprawki błędów blokujących uruchamianie zgłoszone do danego momentu przez producentów OEM, którzy korzystają z odpowiedniej podstawowej wersji kwartalnej. Poniżej znajdziesz przykład takiej sytuacji.
- 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 przesyłania, 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 przesyłania „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 zyskuje na tym, co odkryją inne urządzenia, 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 znalezione 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 o zatwierdzeniu). Google nie ujawnia, jakiego konkretnie urządzenia dotyczy ten problem, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w dzienniku zmian.