W tym dokumencie opisano sposób wydawania GKI, w tym wydania cotygodniowe, miesięczne i pozapasmowe wydania awaryjne. Celem tego dokumentu jest dostarczenie producentom OEM wskazówek dotyczących tego, gdzie można odebrać GKI, a także procesu rozwiązywania sytuacji awaryjnych poza pasmem. Producenci OEM mogą również skorzystać z przewodnika rozwoju GKI, aby dowiedzieć się więcej o tym, jak mogą współpracować z zespołem jądra systemu Android w celu optymalizacji jądra GKI dla swoich produktów.
Tempo wydawania GKI
GKI jest wydawane co miesiąc po zamrożeniu KMI.
Wersja Androida 13 i 14 GKI
Poniższa tabela dotyczy tylko systemów android13-5.10 , android13-5.15 i android14-6.1 .
| Kompilacje certyfikowane co miesiąc przez GKI | Ostateczny termin zameldowania | Data gotowości GKI do wstępnego załadowania | Potwierdzony? |
|---|---|---|---|
| Październik | 14 października 2022 r | 31 października 2022 r | Tak |
| Listopad | 14 listopada 2022 r | 30 listopada 2022 r | Tak |
| Grudzień | 9 grudnia 2022 r | 21 grudnia 2022 r | Tak |
| Styczeń | 17 stycznia 2023 r | 31 stycznia 2023 r | Tak |
| Luty | 15 lutego 2023 r | 28 lutego 2023 r | Tak |
| Marsz | 15 marca 2023 r | 31 marca 2023 r | Tak |
| Kwiecień | 13 kwietnia 2023 r | 28 kwietnia 2023 r | Tak |
| Móc | 17 maja 2023 r | 31 maja 2023 r | Tak |
| Czerwiec | 15 czerwca 2023 r | 30 czerwca 2023 r | Tak |
| Lipiec | 18 lipca 2023 r | 31 lipca 2023 r | Tak |
| Sierpień | 16 sierpnia 2023 r | 31 sierpnia 2023 r | Tak |
| Wrzesień | 14 września 2023 r | 29 września 2023 r | Tak |
| Październik | 18 października 2023 r | 31 października 2023 r | Tak |
| Listopad | 10 listopada 2023 r | 30 listopada 2023 r | Tak |
| Grudzień | 7 grudnia 2023 r | 22 grudnia 2023 r | Tak |
| Styczeń | 16 stycznia 2024 r | 31 stycznia 2024 r | Tak |
| Luty | 13 lutego 2024 r | 29 lutego 2024 r | Tak |
| Marsz | 13 marca 2024 r | 29 marca 2024 r | Tak |
| Kwiecień | 16 kwietnia 2024 r | 30 kwietnia 2024 r | Tak |
| Móc | 14 maja 2024 r | 31 maja 2024 r | Tak |
| Czerwiec | 12 czerwca 2024 r | 28 czerwca 2024 r | Tak |
| Lipiec | 16 lipca 2024 r | 31 lipca 2024 r | Tak |
| Sierpień | 15 sierpnia 2024 r | 30 sierpnia 2024 r | Tak |
| Wrzesień | 17 września 2024 r | 30 września 2024 r | Tak |
| Październik | 15 października 2024 r | 31 października 2024 r | Tak |
| Listopad | 11 listopada 2024 r | 27 listopada 2024 r | Tak |
| Grudzień | 6 grudnia 2024 r | 23 grudnia 2024 r | Tak |
Począwszy od stycznia 2024 r. wznowimy comiesięczne wydawanie wersji android14-5.15 zgodnie z określoną miesięczną częstotliwością przedstawioną w poniższej tabeli.
| Kompilacje certyfikowane co miesiąc przez GKI | Ostateczny termin zameldowania | Data gotowości GKI do wstępnego załadowania | Potwierdzony? |
|---|---|---|---|
| Styczeń | 16 stycznia 2024 r | 31 stycznia 2024 r | Tak |
| Luty | 13 lutego 2024 r | 29 lutego 2024 r | Tak |
| Marsz | 4 marca 2024 r | 15 marca 2024 r | Tak |
| Kwiecień | 1 kwietnia 2024 r | 17 kwietnia 2024 r | Tak |
| Móc | 1 maja 2024 r | 17 maja 2024 r | Tak |
| Czerwiec | 3 czerwca 2024 r | 17 czerwca 2024 r | Tak |
| Lipiec | 1 lipca 2024 r | 15 lipca 2024 r | Tak |
| Sierpień | 1 sierpnia 2024 r | 16 sierpnia 2024 r | Tak |
| Wrzesień | 2 września 2024 r | 16 września 2024 r | Tak |
| Październik | 1 października 2024 r | 14 października 2024 r | Tak |
| Listopad | 1 listopada 2024 r | 15 listopada 2024 r | Tak |
| Grudzień | 2 grudnia 2024 r | 16 grudnia 2024 r | Tak |
Wersja Androida 12 GKI
Po maju 2023 r. wydania android12-5.10 GKI będą wydawane co 2 miesiące i publikowane w połowie miesiąca. Poniższa tabela dotyczy tylko android12-5.10 .
| Kompilacje certyfikowane co miesiąc przez GKI | Ostateczny termin zameldowania | Data gotowości GKI do wstępnego załadowania | Potwierdzony? |
|---|---|---|---|
| Lipiec | 3 lipca 2023 r | 14 lipca 2023 r | Tak |
| Wrzesień | 1 września 2023 r | 15 września 2023 r | Tak |
| Listopad | 3 listopada 2023 r | 17 listopada 2023 r | Tak |
| Styczeń | 5 stycznia 2024 r | 19 stycznia 2024 r | Tak |
| Marsz | 4 marca 2024 r | 15 marca 2024 r | Tak |
| Móc | 1 maja 2024 r | 17 maja 2024 r | Tak |
Ważność kompilacji GKI dla producentów OEM
Producenci OEM mogą korzystać z niedawno wydanego Androida GKI. Producenci OEM mogą wprowadzać na rynek kompilacje z certyfikatem GKI, o ile są one zgodne z wymaganiami LTS określonymi w Biuletynie zabezpieczeń systemu Android (ASB).
Cotygodniowe wydania rozwojowe
Wydania są testowane z mątwą , aby mieć pewność, że przeszły minimalny próg jakości .Pliki binarne GKI są dostępne do samoobsługi na stronie ci.android.com po połączeniu zmian. Kompilacje cotygodniowe nie będą certyfikowane, ale można je wykorzystać jako podstawę do programowania i testowania. Kompilacji cotygodniowych nie można używać do kompilacji urządzeń produkcyjnych dla użytkowników końcowych.
Comiesięczne certyfikowane wydania
Comiesięczne wydania GKI zawierają przetestowany boot.img , który zawiera wstawiony certyfikat Google potwierdzający, że pliki binarne zostały zbudowane na podstawie znanego kodu źródłowego.
Co miesiąc wybierany jest kandydat do miesięcznej wersji GKI (niecertyfikowany) po ostatecznej dacie rejestracji, która zwykle jest drugą cotygodniową kompilacją w tym miesiącu. Po wybraniu kandydata do wydania miesięcznego nowe zmiany nie zostaną zaakceptowane w wydaniu z tego miesiąca. W okresie zamkniętego okna można zająć się jedynie poprawkami błędów powodujących niepowodzenie testu. Kandydat do wydania przechodzi kontrolę jakości — zgodnie z opisem w sekcji dotyczącej kwalifikacji GKI — aby mieć pewność, że kompilacja GSI+GKI przejdzie pomyślnie testy zgodności z urządzeniem referencyjnym oraz mątwą.
Rysunek 1. Harmonogram wydania GKI
Proces reagowania awaryjnego
Respin odnosi się do procesu ponownego łączenia, odbudowy, ponownego testowania i ponownej certyfikacji pliku binarnego po publicznym wydaniu jądra GKI . Możesz poprosić o ponowne zakręcenie certyfikowanego pliku binarnego w jednej z następujących okoliczności:
- Aby zaktualizować listę symboli.
- Aby zastosować poprawkę do błędu, w tym błędów wykrytych podczas zatwierdzania laboratorium przewoźnika.
- Aby dodać hak dostawcy .
- Aby zastosować poprawkę do istniejącej funkcji.
- Aby zastosować poprawkę zabezpieczeń (po 6 miesiącach).
Poprawki zabezpieczeń są automatycznie łączone w gałęzi wydania przez okres do 6 miesięcy od wydania gałęzi. Po upływie 6 miesięcy musisz poprosić o ponowne zatwierdzenie, aby zastosować poprawki zabezpieczeń w oddziale.
Zanim poprosisz o ponowne zakręcenie, zwróć uwagę na następujące wskazówki:
Respiny są dozwolone tylko w gałęziach wydań po uruchomieniu pierwszej publicznej wersji comiesięcznej kompilacji .
Żądania ponownego wydania są akceptowane tylko dla danej gałęzi wydania przez maksymalnie sześć miesięcy od pierwszego publicznego wydania. Po sześciu miesiącach oddziały kwalifikują się do zwrotu tylko w przypadku poprawek bezpieczeństwa wymienionych w Biuletynie zabezpieczeń systemu Android .
Jeśli wymagania LTS określone w Biuletynie zabezpieczeń systemu Android (ASB) spowodują, że gałąź będzie niezgodna, zostanie ona przestarzała. Żądania odpowiedzi na przestarzałe gałęzie nie są akceptowane. Data wycofania danej gałęzi wydania GKI jest podana w miesięcznych uwagach dotyczących kompilacji wydania GKI w sekcji Wersje . Na potrzeby przyszłego planowania wymagania LTS są aktualizowane corocznie w maju i listopadzie. Na przykład gałąź
android12-5.10-2023-07(5.10.177) nie jest obsługiwana dla respinów po 1 maja 2024 r., ponieważ gałąźandroid12-5.10-2023-07(5.10.177) nie jest zgodna z Wymagania LTS normy ASB-2024-05.Respiny mają zastosowanie tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania łatki naprawiającej istniejącą funkcję.
Wszystkie łatki trafiające do gałęzi wydań miesięcznych muszą już zostać włączone do głównej gałęzi rozwojowej GKI. Na przykład, jeśli wymagana jest łatka do ponownego uruchomienia
android12-5.10-2022-09, musi ona być już scalona zandroid12-5.10.Musisz wybrać łatki z głównej gałęzi rozwojowej GKI i przesłać łatkę do gałęzi wydań miesięcznych.
W żądaniu odpowiedzi musisz przypisać priorytet (pilność) żądaniu. Priorytet ten pomaga zespołowi GKI lepiej i terminowo pomagać partnerom. W przypadku żądań krytycznych lub wrażliwych na czas oznacz priorytet jako P0 . W przypadku wniosków P0 i P1 należy również uzasadnić pilność. Poniższa tabela przedstawia mapowanie priorytetu błędu i czasu jego rozwiązania (ESRT):
Priorytet ESRT P0 2 dni robocze P1 5 dni roboczych P2 10 dni roboczych P3 15 dni roboczych
Musisz złożyć oddzielny wniosek o respin dla każdej gałęzi wydania. Na przykład, jeśli potrzebne jest respin zarówno dla
android12-5.10-2022-08iandroid12-5.10-2022-09, musisz utworzyć dwa żądania respin.Po udostępnieniu kompilacji i oznaczeniu żądania ponownego uruchomienia jako naprawione nie należy ponownie otwierać żądania ponownego otwarcia w celu dodania dodatkowych licencji CL. Jeśli istnieją dodatkowe łaty, które wymagają połączenia, musisz przesłać nową prośbę o respin.
Dla każdego rozważanego CL dodaj następujące tagi. Bez tej informacji postęp w realizacji żądania ponownego uruchomienia zostanie zablokowany.
-
Bug: identyfikator błędu musi zostać dodany do komunikatu zatwierdzenia dla każdego CL. -
Change-Id: musi być identyczny z identyfikatorem zmiany zmiany gałęzi podstawowej.
-
Jeśli prośba o odpowiedź wymaga Twojej odpowiedzi, a Ty nie odpowiesz w ciągu trzech dni roboczych, priorytet zostanie obniżony o jeden poziom (na przykład P0 zostanie obniżony do P1 ). Jeśli nie odpowiesz przez dwa tygodnie, błąd zostanie oznaczony jako Nie zostanie naprawiony (przestarzały) .
Prześlij prośbę o odpowiedź
Poniższy diagram przedstawia proces respinowania. Proces rozpoczyna się w momencie przesłania przez partnera OEM (ty) prośby o respin.
Rysunek 2. Proces respinowania
Aby przystąpić do procesu respin:
- Wypełnij formularz żądania GKI Respin . i natychmiast skontaktuj się ze swoim technicznym menedżerem konta Google. Ten formularz powoduje błąd żądania odpowiedzi GKI. Błędy w prośbach o odpowiedź są widoczne dla Ciebie (osoby zgłaszającej), zespołu GKI i konkretnych osób, które dodasz do listy CC błędów.
- Jeśli masz już poprawkę, prośba powinna wskazywać przesłanie poprawki w AOSP, aby Google mógł ją sprawdzić. Jeżeli przesłanie łatki nie jest możliwe, łatkę należy dołączyć do wniosku w postaci pliku tekstowego.
- Jeśli nie masz rozwiązania, żądanie musi zawierać 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 przydziela Ci ją, jeśli potrzebujesz więcej informacji.
- Po uzgodnieniu poprawki zespół Google GKI sprawdza kod (CR+2) zmianę. Przegląd rozpoczyna się od przedziału czasowego ESRT. Zespół GKI łączy, buduje, testuje regresję i certyfikuje zmianę.
- Plik binarny jest udostępniany na stronie ci.android.com . Ramy czasowe ESRT dobiegają końca, a zespół Google GKI oznacza żądanie jako naprawione i odwołuje się do kompilacji respin. Kompilację respin można również opublikować na stronie kompilacji wersji Generic Kernel Image (GKI) .
Kwalifikacje GKI
| Rodzaje kompilacji GKI | Egzekwowanie jakości | Notatki |
|---|---|---|
| Co tydzień | Testowanie mątwy
|
|
| Miesięcznie (certyfikowany) | Testowanie mątwy
| |
| Respiny (certyfikowane) | Testowanie mątwy
|
|
Gdzie zdobyć artefakty kompilacji
Artefakty dla wszystkich wersji można uzyskać na stronie ci.android.com .
Więcej informacji na temat CI, w tym wyniki testów, znajdziesz na pulpicie nawigacyjnym ciągłej integracji Androida .
Często zadawane pytania
Czy można zbudować nowy plik binarny GKI w oparciu o już wydany GKI?
Tak, nazywa się to respinem. Proces ponownego uruchomienia jest obsługiwany, o ile wydana kompilacja GKI (w przypadku której zażądano ponownego uruchomienia) jest zgodna z wymaganiami LTS określonymi w Biuletynie zabezpieczeń systemu Android (ASB).
Czy możliwe jest odtworzenie plików binarnych GKI?
Tak, odwołaj się do poniższego przykładu.
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 wykonaj następujące 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
Możesz pobrać kopię artefaktu GKI z out/.../dist .
Czy plik binarny GKI (w tym łatka awaryjna) został zbudowany w oparciu o najnowszą bazę kodu?
Nie. Respiny zawierają tylko łatki, które znajdują się na wybranych miesięcznych certyfikowanych jądrach. Te respiny zawierają wszystkie poprawki błędów blokujących uruchamianie zgłoszone do dowolnego momentu przez producentów OEM korzystających z odpowiedniej podstawowej miesięcznej wersji. Zobacz poniższy przykład tego, jak dzieje się tego typu scenariusz.
- OEM1 i OEM2 decydują się na użycie wersji binarnej GKI od listopada 2021 r.
- OEM1 i OEM2 znajdują problemy, które wymagają poprawek w celu uzyskania wsparcia. Te poprawki mogą się różnić lub mogą być takie same.
- Respiny ponad plik binarny z listopada 2021 r. zawierają poprawki blokujące uruchamianie zgłoszone zarówno przez OEM1, jak i OEM2 w oknie respin, ale nic więcej.
- Zagadnienia wymienione w punkcie drugim są także uwzględniane w kolejnych comiesięcznych wydaniach GKI.
Październikowe wydanie zawiera wszystkie łatki przesłane przez producentów OEM, ale wpływają na nas inne łatki OEM, ponieważ nie zostały one specjalnie przetestowane z naszymi produktami. Czy można dołączyć tylko naszą łatkę?
To jest niemożliwe. Ścieżka respinowa „na producenta OEM” nie jest obecnie skalowalna. Zamiast tego zespół GKI analizuje każdą zmianę wprowadzaną w kompilacjach respinowych i testuje zmiany na całym dostępnym sprzęcie przed utworzeniem nowej kompilacji. Jeśli zespół GKI stwierdzi, że problem dotyczy konkretnego producenta OEM/urządzenia/modelu, zespół GKI może zapewnić, że kod dodany w wyniku zmiany zostanie wykonany tylko na urządzeniu/modelu/SKU, którego dotyczy problem.
Główną zaletą ujednoliconych odpowiedzi jest to, że każde urządzenie korzystające z tej samej bazy wydań czerpie korzyści od siebie nawzajem, zwłaszcza jeśli wykryte błędy są ogólne i dotyczą wszystkich użytkowników. Konkretnym przykładem tej koncepcji są podstawowe błędy jądra wykryte podczas testów przewoźnika.
Czy zdarzają się sytuacje, w których Google udostępnia szczegółowe informacje na temat poprawek OEM i scenariuszy problemów, aby producenci OEM mogli ocenić wpływ i ryzyko wdrożenia poprawek w swoich produktach?
Google nigdy nie doda zmian w kompilacji respin, dopóki problem nie zostanie zrozumiany i nie zostaną zebrane wszystkie szczegóły. Można to zobaczyć w dzienniku zmian (komunikat zatwierdzenia). Google nie ujawnia, jakiego konkretnego urządzenia dotyczy problem, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w dzienniku zmian.