Wspólne jądra Androida

Wspólne jądra AOSP (znane też jako wspólne jądra Androida lub ACK) są pochodnymi jąder kernel.org i zawierają poprawki, które są istotne dla społeczności Androida, ale nie zostały jeszcze scalone z główną linią rozwoju ani z jądrami LTS (Long Term Supported). Mogą one obejmować:

• Przenoszenie wstecz i wybieranie funkcji z wersji nadrzędnej, które są potrzebne do działania funkcji Androida
• Funkcje gotowe na urządzenia z Androidem, ale nadal w fazie rozwoju
• Funkcje dostawcy lub producenta OEM przydatne dla innych partnerów w ekosystemie

android-mainline to główna gałąź rozwoju funkcji Androida. Główna gałąź Linuxa jest scalana z android-mainline za każdym razem, gdy Linus Torvalds opublikuje wersję lub wersję kandydującą. Przed 2019 r. wspólne jądra Androida były tworzone przez sklonowanie ostatnio ogłoszonego jądra LTS i dodanie poprawek specyficznych dla Androida. W 2019 roku zmieniliśmy ten proces, aby odgałęziać nowy wspólny kernel Androida od android-mainline. Ten nowy model pozwala uniknąć znacznego nakładu pracy związanego z przenoszeniem i testowaniem poprawek Androida, ponieważ ten sam efekt można osiągnąć stopniowo. android-mainline jest poddawany ciągłym testom, ten model zawiera wysokiej jakości jądro od dnia publikacji.

Gdy w przypadku LTS zostanie zadeklarowana nowa wersja nadrzędna, odpowiednie jądro wspólne zostanie odgałęzione z android-mainline. Umożliwia to partnerom rozpoczęcie projektu przed zadeklarowaniem wersji LTS przez scalenie z android-mainline. Po utworzeniu nowej gałęzi wspólnego jądra partnerzy mogą bezproblemowo zmienić źródło scalania na nową gałąź.

Inne popularne gałęzie jądra są regularnie łączone z powiązanym jądrem LTS. Zwykle są one przeprowadzane natychmiast po opublikowaniu wersji LTS. Na przykład po opublikowaniu wersji Linuksa 6.1.75 została ona scalona z wspólnym jądrem 6.1 (android14-6.1). Zachęcamy partnerów do aktualizowania jąder, aby mieć dostęp do najnowszych poprawek błędów związanych z LTS i Androidem.

Gałąź jądra ACK KMI

Jądra GKI mają stabilny interfejs modułu jądra. Interfejs KMI jest jednoznacznie identyfikowany przez wersję jądra i wersję platformy Android, więc gałęzie mają nazwy ANDROID_RELEASE-KERNEL_VERSION. Na przykład jądro GKI w wersji 6.1 dla Androida 14 ma nazwę android14-6.1. W przypadku Androida 15 wprowadzono jądro GKIandroid15-6.6.

Jądra funkcji i wersji

Przed Androidem 15 na potrzeby uruchomienia urządzenia można było użyć dowolnego z 3 najnowszych jąder. Od Androida 15 do uruchamiania urządzenia można używać 2 najnowszych wersji jądra. Jądra startowe Androida 15 to android15-6.6 i android14-6.1.

Ponieważ aktualizacja platformy nie wymaga uaktualnienia jądra, do uruchamiania urządzeń można używać jąder, które nie mają najnowszych funkcji dla danej wersji platformy. Dlatego jądra zaprojektowane z myślą o Androidzie 14, takie jak android14-6.1, mogą być używane na urządzeniach nawet po uaktualnieniu platformy do Androida 15.

Wspólna hierarchia jądra

Utwórz gałąź z android-mainline

Najwyższy poziom hierarchii wspólnego jądra przedstawiono na rysunku 1.

Rysunek 1. Tworzenie wspólnych jąder z jądra android-mainline

Zwróć uwagę, że w 2022 roku z android-mainline utworzono nową gałąź wspólnego jądra Androida android14-6.1. W 2023 r., gdy ogłoszono kolejną wersję LTS, gałąź android15-6.6 została odgałęziona od android-mainline.

Jak pokazano na rysunku 1, każda wersja jądra może być podstawą 2 jąder GKI. Na przykład 2 jądra w wersji 5.15 to android13-5.15 i android14-5.15. Oba są jądrami funkcji dla odpowiednich wersji platformy. Tak było też w przypadku wersji 5.10. Gałąź android12-5.10 została utworzona, gdy ogłoszono wersję LTS, a gałąź android13-5.10 została od niej odłączona na etapie ukończenia funkcji jądra wiosną 2021 roku, aby umożliwić opracowywanie funkcji dla Androida 13.android12-5.10 Od Androida 15 (2024) dla każdej wersji jądra GKI będzie dostępne tylko jedno nowe jądro (nie będzie jądra android15-6.1).

Cykl życia gałęzi KMI ACK

Cykl życia gałęzi ACK KMI przedstawiono na rysunku 2.

Rysunek 2. 6.6 ACK KMI branch lifecycle

Aby wyjaśnić proces rozwoju i cykl życia gałęzi, na rysunku 2 przedstawiono gałęzie ACK KMI dla wersji 6.6.

Każda gałąź ACK KMI przechodzi 3 fazy, które na rysunku 2 są oznaczone różnymi kolorami. Jak widać, LTS jest regularnie scalany niezależnie od fazy.

Faza rozwoju

Po utworzeniu gałąź ACK KMI wchodzi w fazę rozwoju (na rysunku 2 oznaczona jako dev) i jest otwarta na wnoszenie funkcji w kolejnej wersji platformy Android. Na rysunku 2 android15-6.6 został utworzony, gdy wersja 6.6 została zadeklarowana jako nowy jądro LTS upstream.

Faza stabilizacji

Gdy gałąź ACK KMI zostanie uznana za ukończoną, przechodzi w fazę stabilizacji (na rysunku 2 oznaczono ją jako stabilna). Funkcje partnerów i poprawki błędów są nadal akceptowane, ale śledzenie KMI jest włączone, aby wykrywać wszelkie zmiany wpływające na interfejs. Na tym etapie akceptowane są zmiany powodujące niezgodność interfejsu KMI, a definicja interfejsu KMI jest aktualizowana zgodnie z ustalonym harmonogramem (zwykle co 2 tygodnie). Szczegółowe informacje o monitorowaniu KMI znajdziesz w omówieniu GKI.

KMI frozen phase

Zanim nowa wersja platformy zostanie przesłana do AOSP, gałąź ACK KMI jest zamrażana i pozostaje zamrożona przez cały okres jej istnienia. Oznacza to, że nie akceptujemy żadnych zmian powodujących niezgodność z KMI, chyba że zostanie wykryty poważny problem z bezpieczeństwem, którego nie można rozwiązać bez wpływu na stabilny interfejs KMI. Aby uniknąć problemów z KMI, niektóre poprawki scalone z LTS mogą zostać zmodyfikowane lub usunięte, jeśli nie są wymagane w przypadku urządzeń z Androidem.

Gdy gałąź ACK KMI jest zamrożona, można akceptować poprawki błędów i funkcje partnerów, o ile nie powodują one uszkodzenia istniejącego wspólnego jądra KMI. Interfejs KMI można rozszerzać o nowe eksportowane symbole, o ile nie ma to wpływu na interfejsy wchodzące w skład obecnego interfejsu KMI. Gdy do KMI dodawane są nowe interfejsy, od razu stają się stabilne i nie można ich uszkodzić przyszłymi zmianami.

Na przykład zmiana, która dodaje pole do struktury używanej przez interfejs KMI wspólnego jądra, jest niedozwolona, ponieważ zmienia definicję interfejsu:

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Dodanie nowej funkcji jest jednak dopuszczalne:

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

Przez cały okres użytkowania jądra GKI zachowana jest zgodność wsteczna z przestrzenią użytkownika, dzięki czemu jądro może być bezpiecznie używane w wersji platformy Android, z którą urządzenie zostało wprowadzone na rynek. Ciągłe testowanie z poprzednimi wersjami zapewnia zgodność. Na rysunku 2 android15-6.6jądro może być używane na urządzeniach z Androidem 15 i nowszym. Wersja platformy Android jest też zgodna z poprzednimi wersjami, więc android14-6.1 jądro może być używaneandroid14-6.1 na urządzeniach z Androidem 15 zarówno podczas uruchamiania, jak i aktualizacji.

Numer generacji KMI

Jeśli w fazie stabilizacji nastąpi scalenie LTS lub po niej wystąpi problem z bezpieczeństwem bądź inne zdarzenie, które wymaga zaakceptowania poprawki zmieniającej KMI, numer generacji KMI zapisany w build.config.common zostanie zwiększony. Aktualną generację KMI można sprawdzić za pomocą polecenia uname:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

Liczba po nazwie platformy to generacja KMI (w tym przypadku 6).

Jeśli generowanie KMI się zmieni, jądro nie będzie zgodne z modułami dostawcy, które są zgodne z poprzednią generacją KMI, więc moduły muszą zostać przebudowane i zaktualizowane synchronicznie z jądrem. Po zamrożeniu KMI zmiany w generowaniu KMI będą bardzo rzadkie.

Zgodność między jądrami

Wymagania dotyczące zgodności między jądrami w tej samej rodzinie LTS zmieniają się wraz z nowymi jądrami GKI.

Jądra GKI

Jądra GKI zachowują zgodność wsteczną ze wszystkimi wersjami platformy Android, które obsługiwały daną wersję jądra. Poza tym platformy Android są zgodne wstecznie z jądrami GKI z poprzednich wersji. Dzięki temu możesz bezpiecznie używać android14-6.1jądra opracowanego dla Androida 14 (2023)android14-6.1 na urządzeniach z Androidem 15 (2024). Zgodność jest weryfikowana przez ciągłe testy VTS i CTS jąder GKI ze wszystkimi obsługiwanymi wersjami.

Interfejs KMI jest stabilny, dzięki czemu można aktualizować jądro bez konieczności ponownego kompilowania modułów jądra w obrazie dostawcy.

Zgodność KMI nie jest zachowywana między różnymi jądrami GKI. Na przykład jądra android14-6.1 nie można zastąpić jądrem android15-6.6 bez ponownego skompilowania wszystkich modułów.

Jądra GKI są obsługiwane tylko w przypadku ich pierwszej i kolejnych wersji. Nie są one obsługiwane w przypadku starszych wersji. Jądro android15-6.6 nie jest obsługiwane na urządzeniach z Androidem 14 (2023).

Tabela zgodności

Ta tabela zawiera wersje jądra obsługiwane i testowane w przypadku każdej wersji platformy Android.

Okresy pomocy i poprawki zabezpieczeń

ACK otrzymują scalenia LTS z upstreamu i poprawki błędów w kodzie specyficznym dla Androida. Obejmują one wszystkie poprawki zabezpieczeń jądra wymienione w comiesięcznych biuletynach zabezpieczeń Androida, które są istotne dla ACK.

ACK mogą być obsługiwane dłużej niż odpowiednie stabilne jądro upstream na stronie kernel.org. W takim przypadku Google zapewnia rozszerzone wsparcie do daty zakończenia cyklu życia (EOL) podanej w tej sekcji. Gdy jądra osiągną koniec okresu eksploatacji, Google przestaje je obsługiwać, a urządzenia, na których działają, są uznawane za podatne na ataki.

Od wersji jądra 6.6 okres wsparcia dla stabilnych jąder wynosi 4 lata.

Ta tabela zawiera okresy ważności obsługiwanych potwierdzeń:

Testowanie wspólnego jądra

Wspólne jądra są testowane w kilku systemach CI, a także w ramach testów przeprowadzanych przez dostawców.

Test funkcjonalny jądra systemu Linux

Linux Kernel Functional Test (LKFT) testy uruchamiają różne pakiety testów, w tym kselftest, LTP, VTS i CTS, na zestawie fizycznych urządzeń arm32 i arm64. Najnowsze wyniki testów znajdziesz na stronie android-lkft.

Testowanie KernelCI

Testy kompilacji i uruchamiania KernelCI są inicjowane za każdym razem, gdy nowy patch zostanie zatwierdzony w wspólnym gałęzi jądra. Kilka setek konfiguracji kompilacji jest testowanych i uruchamianych na różnych płytach. Najnowsze wyniki dotyczące jąder Androida znajdziesz na stronie KernelCL.

Testowanie przed przesłaniem i po przesłaniu w przypadku Androida

Testy przed przesłaniem służą do zapobiegania wprowadzaniu błędów do wspólnych jąder Androida. Podsumowanie wyników testu znajdziesz na karcie „Checks” (Sprawdzanie) w zmianach kodu w gerritowym wspólnym jądrze Androida.

Testy po przesłaniu w Androidzie są przeprowadzane w przypadku nowych opublikowanych kompilacji w gałęziach wspólnego jądra Androida, gdy nowe poprawki są zatwierdzane w gałęzi wspólnego jądra Androida na stronie ci.android.com. Wpisując aosp_kernel jako część nazwy gałęzi na stronie ci.android.com, możesz wyświetlić listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki dla android-mainline znajdziesz w panelu ciągłej integracji Androida (Android CI). Kliknij konkretną kompilację, aby sprawdzić stan testu na karcie Test Results.

Testy zdefiniowane przez test-mapping z grupą testową kernel-presubmit w drzewie źródłowym platformy Android są uruchamiane jako testy przed zatwierdzeniem w przypadku gałęzi jądra Androida. Na przykład ta konfiguracja w pliku test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING umożliwia test vts_kernel_proc_file_api_test jako test przed przesłaniem w przypadku sprawdzania kodu wspólnego jądra Androida.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

Testowanie luk typu 0-day

Testowanie 0-dniowe polega na testowaniu poszczególnych poprawek na wszystkich wspólnych gałęziach jądra Androida po wprowadzeniu nowych poprawek. Przeprowadzane są różne testy rozruchu, funkcjonalne i wydajnościowe. Dołącz do grupy publicznej cros-kernel-buildreports.

Zestaw testów

Współtworzenie wspólnych jąder Androida

Zasadniczo nowe funkcje należy opracowywać w głównej linii Linuksa, a nie w wersjach jądra wspólnych dla Androida. Zdecydowanie zalecamy tworzenie kodu w górę strumienia. Po zaakceptowaniu tam zmian można je w razie potrzeby przenieść do konkretnej gałęzi ACK. Zespół ds. jądra Androida z przyjemnością wspiera działania na rzecz włączenia zmian do głównej gałęzi projektu, co przyniesie korzyści ekosystemowi Androida.

Przesyłaj poprawki do Gerrit i postępuj zgodnie z tymi wytycznymi dotyczącymi współtworzenia.