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

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ą.

Harmonogram publikowania GKI 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 elementem android12-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 i android12-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.

Awaryjny proces odzyskiwania Rysunek 2. Proces odzyskiwania

Aby rozpocząć proces odpinania:

  1. 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.
  2. Zespół Google GKI sprawdza prośbę i zatwierdza ją lub przypisuje ją Tobie, jeśli potrzebne są dodatkowe informacje.
  3. 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ę.
  4. 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
  • Rozruchowy
  • Podzbiór VTS
  • Podzbiór CTS
  • Brak certyfikatu. Tylko do testowania i wyświetlania
    urządzenia.
  • Nie można używać do uruchamiania urządzeń.
Co miesiąc (certyfikat) Testowanie mątwy
  • Rozruchowy
  • VTS
  • wskaźnik CTS
Testowe testy sprzętowe
  • Rozruchowy
  • VTS
  • wskaźnik CTS
Respins (certyfikat) Testowanie mątwy
  • Rozruchowy
  • VTS
  • Podzbiór CTS
Testy urządzeń referencyjnych
  • Rozruchowy
  • VTS
  • Oparte na certyfikowanej kompilacji GKI.
  • Kompilacja otrzymuje certyfikację po uzyskaniu kwalifikacji.

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.