Ten dokument opisuje sposób udostępniania GKI – w tym cotygodniowe, comiesięczne i poza nią awaryjne. Celem tego dokumentu jest przekazanie producentom OEM instrukcji, gdzie mogą uzyskać GKI, a także procedury wprowadzania pozapasmowych poprawek. OEM może też skorzystać z przewodnika dla programistów GKI, aby dowiedzieć się więcej o tym, jak współpracować z zespołem Androida jądra przy optymalizacji jądra GKI dla swoich produktów.
Częstotliwość udostępniania GKI
Usługa GKI jest udostępniana w cyklu miesięcznym po okresie blokady KMI.
Android 13, 14 i 15 GKI w wersji 13, 14 i 15
Ta tabela ma zastosowanie tylko do android13-5.10
, android13-5.15
i android14-6.1
.
Comiesięczne kompilacje z certyfikatem GKI | Ostateczny termin zameldowania | Data gotowości do wstępnego załadowania GKI | Potwierdzono? |
---|---|---|---|
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 |
Marzec | 15 marca 2023 r. | 31 marca 2023 r. | Tak |
Kwiecień | 13 kwietnia 2023 r. | 28 kwietnia 2023 r. | Tak |
Maj | 17 maja 2023 r. | 31 maja 2023 roku | 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 roku | 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 |
Marzec | 13 marca 2024 r. | 29 marca 2024 r. | Tak |
Kwiecień | 16 kwietnia 2024 r. | 30 kwietnia 2024 r. | Tak |
Maj | 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 |
Od stycznia 2024 r. będziemy wznawiać miesięczne publikowanie wersji android14-5.15
zgodnie z harmonogramem miesięcznym podanym w tabeli poniżej.
Od lipca 2024 r. android15-6.6
będzie korzystać z tego samego cyklu publikowania.
Comiesięczne kompilacje z certyfikatem GKI | Ostateczny termin zameldowania | Data gotowości do wstępnego załadowania GKI | Potwierdzono? |
---|---|---|---|
Styczeń | 16 stycznia 2024 r. | 31 stycznia 2024 r. | Tak |
Luty | 13 lutego 2024 r. | 29 lutego 2024 r. | Tak |
Marzec | 4 marca 2024 r. | 15 marca 2024 r. | Tak |
Kwiecień | 1 kwietnia 2024 r. | 17 kwietnia 2024 r. | Tak |
Maj | 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 roku | 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 roku | 15 listopada 2024 r. | Tak |
Grudzień | 2 grudnia 2024 r. | 16 grudnia 2024 r. | Tak |
Android 12 – wersja GKI
Od maja 2024 r. wersje GKI w systemie android12-5.10
są publikowane co kwartał i publikowane w połowie miesiąca.
Ta tabela ma zastosowanie tylko do android12-5.10
.
Comiesięczne kompilacje z certyfikatem GKI | Ostateczny termin zameldowania | Data gotowości do wstępnego załadowania GKI | Potwierdzono? |
---|---|---|---|
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 |
Marzec | 4 marca 2024 r. | 15 marca 2024 r. | Tak |
Maj | 1 maja 2024 r. | 17 maja 2024 r. | Tak |
Sierpień | 1 sierpnia 2024 roku | 16 sierpnia 2024 r. | Tak |
Listopad | 1 listopada 2024 roku | 15 listopada 2024 r. | Tak |
Luty | 3 lutego 2025 r. | 17 lutego 2025 r. | Tak |
Zgodność GKI dla producentów OEM
OEM może używać niedawno opublikowanego interfejsu GKI Androida. OEM może wprowadzać na rynek kompilacje z certyfikatem GKI, o ile są one zgodne z wymaganiami dotyczącymi kanału LTS opisanymi w biuletynie Android Security Bulletin (ASB).
Cotygodniowe informacje o wersjach rozwojowych
Wersje są testowane z wykorzystaniem mątwy, aby sprawdzić, czy spełniają minimalną jakość.Pliki binarne GKI są dostępne do samoobsługi na ci.android.com w miarę scalania zmian. Cotygodniowe kompilacje nie będą certyfikowane, ale mogą zostać wykorzystane jako podstawa podczas programowania i testowania. Tygodniowych kompilacji nie można używać w przypadku kompilacji na urządzenia produkcyjne przeznaczone dla użytkowników.
Certyfikowane treści co miesiąc
Comiesięczne wersje GKI zawierają przetestowany zasób boot.img
zawierający certyfikat wstawiony przez Google potwierdzający, że pliki binarne zostały skompilowane na podstawie znanej wartości bazowej kodu źródłowego.
Co miesiąc po ostatecznym terminie rejestracji, czyli zazwyczaj 2 tygodniowej kompilacji w danym miesiącu, wybierany jest kandydat do comiesięcznej wersji GKI (bez certyfikatu). Po wybraniu wersji miesięcznej, która kandyduje do publikacji w danym miesiącu, nowe zmiany nie zostaną zaakceptowane w wersji w danym miesiącu. W okresie zamkniętym można poprawić tylko te błędy, które powodują błąd testu. Kandydat do wydania przechodzi kontrolę jakości (opisaną w sekcji dotyczącej kwalifikacji GKI), by mieć pewność, że testy zgodności GSI+GKI kompilują kompilację z urządzeniem referencyjnym i mątwą.
Rysunek 1. Harmonogram premiery GKI
Awaryjny proces odzyskiwania
Respin oznacza proces ponownego tworzenia, odbudowy, ponownego testowania i ponownej certyfikacji pliku binarnego po publicznej publikacji jądra GKI. Możesz poprosić o odświeżenie certyfikowanego pliku binarnego w dowolnej z tych sytuacji:
- Aby zaktualizować listę symboli.
- Wprowadzenie poprawki do błędu, w tym błędów wykrytych podczas zatwierdzania modułu przez operatora.
- Aby dodać link do strony dostawcy.
- Aby zastosować poprawkę do istniejącej funkcji.
- Aby zastosować poprawkę zabezpieczeń (po 6 miesiącach).
Poprawki zabezpieczeń są automatycznie scalane w gałęzi wersji przez maksymalnie 6 miesięcy od wydania gałęzi. Po upływie 6 miesięcy musisz poprosić o odseparowanie, aby zastosować poprawki zabezpieczeń do gałęzi.
Zanim poprosisz o ponowne sprawdzenie, zapoznaj się z tymi wytycznymi:
Przypinania są dozwolone tylko w gałęziach wersji po opublikowaniu pierwszej publicznej wersji miesięcznej kompilacji.
Prośby o respin są akceptowane tylko w przypadku danej gałęzi wersji przez maksymalnie 6 miesięcy od pierwotnej publikacji. Po 6 miesiącach można odpiąć gałęzie tylko w przypadku poprawek zabezpieczeń wymienionych w biuletynie o bezpieczeństwie Androida.
Gdy wymagania LTS zdefiniowane w biuletynie dotyczącym bezpieczeństwa Androida (ASB) powodują, że gałąź jest niezgodna, gałąź jest wycofana. Żądania Respin dotyczące wycofanych gałęzi nie są akceptowane. Data wycofania danej gałęzi GKI jest podana w comiesięcznych informacjach o kompilacji GKI w sekcji Wersje. Na potrzeby planowania w przyszłości wymagania dotyczące kanału 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 odinstalowań po 1 maja 2024 r., ponieważ gałąźandroid12-5.10-2023-07
(5.10.177) nie jest zgodna z wymaganiami LTS zawartymi w standardzie ASB-2024-05.Przypinania mają zastosowanie tylko w przypadku pilnych poprawek błędów, aktualizacji listy symboli lub zastosowania poprawki w celu naprawienia istniejącej funkcji.
Wszystkie poprawki trafiające do miesięcznej gałęzi wersji muszą już zostać scalone z główną gałęzią deweloperską GKI. Jeśli na przykład poprawka jest wymagana dla odpowiedzi
android12-5.10-2022-09
, musi zostać już scalona z elementemandroid12-5.10
.Musisz wybrać poprawki z głównej gałęzi programistycznej GKI i przesłać je do gałęzi comiesięcznych wydań.
W prośbie o ponowne dostosowanie musisz nadać jej priorytet (pilność). Dzięki temu zespół GKI może sprawniej pomagać partnerom. W przypadku żądań krytycznych lub pilnych wyznacz priorytet P0. W przypadku żądań P0 i P1 również należy uzasadnić tę potrzebę. W tabeli poniżej znajdziesz mapowanie priorytetu błędu i czasu na rozwiązanie (ESRT):
Priorytet raport ESRT, P0 2 dni robocze P1S 5 dni roboczych P2 10 dni roboczych P3 15 dni roboczych
Musisz przesłać oddzielne żądanie odpowiedzi na każdą gałąź wersji. Jeśli na przykład odwrotność jest potrzebna zarówno dla
android12-5.10-2022-08
, jak iandroid12-5.10-2022-09
, musisz utworzyć 2 żądania respin.Po dostarczeniu kompilacji i oznaczeniu żądania odpięcia jako naprawionej nie należy ponownie otwierać tego żądania, aby dodać kolejne listy zmian. Jeśli istnieją dodatkowe poprawki, które wymagają scalenia, musisz przesłać nową prośbę o respin.
Do każdej rozważanej listy zmian dodaj następujące tagi. Bez tej informacji postęp przetwarzania żądania ponownego szyfrowania jest blokowany.
Bug
: identyfikator błędu należy dodać do komunikatu zatwierdzenia w przypadku każdej listy zmian.Change-Id
: musi być taki sam jak identyfikator zmiany zmiany gałęzi podstawowej.
Jeśli żądanie odpowiedzi wymaga odpowiedzi i 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 będzie oznaczony jako Nie zostanie naprawiony (nieaktualny).
Prześlij prośbę o respin
Poniższy diagram przedstawia proces odpinania. Ten proces rozpoczyna się, gdy partner OEM (Ty) prześle prośbę o respin.
Rysunek 2. Proces odzyskiwania
Aby rozpocząć proces odpinania:
- Wypełnij formularz prośby o przyznanie GKI Respin i natychmiast skontaktuj się z technicznym menedżerem konta Google. Ten formularz powoduje utworzenie błędu żądania odpowiedzi GKI. Błędy związane z prośbą o odpięcie są widoczne dla Ciebie (osoby zgłaszającej prośbę), zespołu GKI i konkretnych osób, które dodasz do listy DW danego błędu.
- Jeśli masz już poprawkę, prośba powinna wskazywać przesłaną poprawkę w AOSP, aby umożliwić Google jej sprawdzenie. Jeśli nie można przesłać poprawki, należy ją dołączyć do żądania w postaci pliku tekstowego.
- Jeśli nie ma rozwiązania, żądanie musi zawierać jak najwięcej informacji, w tym numer wersji jądra i dzienniki, aby ułatwić Google debugowanie problemu.
- Zespół Google GKI sprawdza prośbę i zatwierdza ją lub przypisuje ją Tobie, jeśli potrzebne są dodatkowe informacje.
- Po uzgodnieniu poprawki zespół Google GKI sprawdzi zmianę (CR+2). Okres weryfikacji rozpoczyna się przez ESRT. Zespół GKI scala, kompiluje i testuje pod kątem regresji, a także certyfikuje zmianę.
- Plik binarny zostanie udostępniony na stronie ci.android.com. Okres końcowy ESRT kończy się, a zespół Google GKI oznacza żądanie jako naprawione i odwołuje się do kompilacji respin. Kompilację z respinem można też opublikować na stronie z kompilacjami wersji ogólnej obrazu jądra (GKI).
Kwalifikacje do GKI
Typy kompilacji GKI | Egzekwowanie jakości | Notes |
---|---|---|
Co tydzień | Testowanie mątwy
|
|
Co miesiąc (certyfikat) | Testowanie mątwy
|
|
Respins (certyfikat) | 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 testu, znajdziesz w panelu ciągłej integracji Androida.
Najczęstsze pytania
Czy można utworzyć nowy plik binarny GKI na podstawie już opublikowanej wersji GKI?
Tak. Jest to tzw. odwrotność. Proces odpinania jest obsługiwany, o ile dostępna kompilacja GKI (która wymaga ponownego utworzenia kodu) jest zgodna z wymaganiami dotyczącymi kanału LTS zawartymi w biuletynie Android Security Bulletin (ASB).
Czy można odtworzyć pliki binarne GKI?
Tak. Zobacz ten 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 wykonaj 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 awaryjnego spinania) został utworzony na podstawie najnowszej bazy kodu?
Nie. Kody Respin zawierają tylko poprawki, które są umieszczane na certyfikowanym jądrze w danym miesiącu. Te zmiany zawierają wszystkie poprawki błędów blokujące uruchomienie zgłoszone do chwili obecnej przez producentów OEM w ramach odpowiedniej podstawowej wersji miesięcznej. Poniższy przykład ilustruje przebieg tego typu scenariuszy.
- OEM1 i OEM2 decydują się na używanie wersji binarnej GKI od listopada 2021 r.
- OEM1 i OEM2 znajdują problemy, które wymagają poprawek do pomocy. Mogą być różne lub takie same.
- W przypadku zmian w pliku binarnym z listopada 2021 roku wprowadzono poprawki związane z blokowaniem uruchamiania zgłoszone przez OEM1 i OEM2 w okresie sprawdzania, ale nic więcej.
- Problemy wymienione w drugim punkcie są też uwzględniane w kolejnych comiesięcznych wersjach GKI.
W październiku wszystkie poprawki OEM zostały zgłoszone, ale dotyczy to też innych łatek OEM, ponieważ nie zostały one specjalnie przetestowane z naszymi produktami. Czy możemy dołączyć tylko naszą poprawkę?
Nie jest to możliwe. Ścieżka zmiany znaczenia „dla producenta OEM” nie jest obecnie skalowalna. Zamiast tego zespół GKI przed utworzeniem nowej kompilacji sprawdza każdą zmianę, która wchodzi w skład kompilacji, i testuje je na całym dostępnym sprzęcie. Jeśli zespół GKI stwierdzi, że problem dotyczy OEM, urządzenia lub modelu, zespół GKI może zagwarantować, że dodany przez niego kod będzie działać tylko na urządzeniu, modelu lub kodzie SKU, których dotyczy problem.
Główną zaletą ujednoliconego podsumowania zmian jest to, że każde urządzenie korzystające z tej samej bazy wersji uzyskuje korzyści od siebie nawzajem, zwłaszcza jeśli wykryte błędy są ogólne i odnoszą się do wszystkich użytkowników. Konkretnym przykładem takiej koncepcji są błędy w jądrze, które pojawiają się w testach u operatora.
Czy w niektórych sytuacjach Google udostępnia konkretne informacje o poprawkach OEM i scenariuszach problemów, aby firmy OEM mogły ocenić wpływ i ryzyko wprowadzenia poprawek w swoich produktach?
Google nigdy nie doda zmiany w kompilacji opartej na odpowiedzi, dopóki problem nie zostanie zrozumiany i nie zostaną zebrane wszystkie szczegóły. Można to zobaczyć w historii zmian (komunikatach zatwierdzenia). Google nie podaje, jakiego konkretnie urządzenia to dotyczy, ale producenci OEM zawsze mogą znaleźć opis problemu i rozwiązanie w dzienniku zmian.