Typowe jądra Androida

Jądra wspólne AOSP (znane też jako jądra wspólne Androida lub ACK)) są pochodnymi jąder kernel.org i zawierają poprawki interesujące społeczność Androida, które nie zostały scalone z jądrami głównymi ani z jądrami LTS. Te poprawki mogą obejmować:

• Wsteczne wdrożenia i wybrane funkcje z górnego poziomu potrzebne do funkcji Androida
• Funkcje gotowe na urządzenia z Androidem, ale nadal w fazie rozwoju w górę łańcucha dostaw
• Funkcje dostawcy/OEM, które są przydatne dla innych partnerów ekosystemu

android-mainline to główny filar rozwoju funkcji Androida. Główna gałąź systemu Linux jest scalana z android-mainline za każdym razem, gdy Linus Torvalds opublikuje wersję lub kandydata do wydania. Przed 2019 r. wspólne jądra Androida były tworzone przez sklonowanie niedawno zadeklarowanego jądra LTS i dodanie poprawek specyficznych dla Androida. W 2019 roku proces ten został zmieniony, aby odgałęziować nowe wspólne jądro Androida z wersji android-mainline. Ten nowy model pozwala uniknąć znacznego wysiłku związanego z przenoszenie portów i testowaniem poprawek Androida, ponieważ osiąga ten sam efekt stopniowo. android-mainline jest stale testowany, dzięki czemu od dnia publikacji zapewnia wysoką jakość jądra.

Gdy nowa wersja LTS zostanie ogłoszona w źródle, odpowiednie wspólne jądro zostanie odgałęzione z android-mainline. Dzięki temu partnerzy mogą rozpocząć projekt przed ogłoszeniem wersji LTS, łącząc go z android-mainline. Po utworzeniu nowego wspólnego gałęzi jądra partnerzy mogą bezproblemowo zmienić źródło scalania na nową gałąź.

Inne popularne gałęzie jądra są regularnie łączone z powiązanymi jądrami LTS. Zwykle odbywa się to natychmiast po opublikowaniu wersji LTS. Na przykład, gdy opublikowano wersję 6.1.75 Linuksa, została ona scalona z powszechnie używanym jądrem 6.1 (android14-6.1). Partnerów zachęcamy do aktualizowania jąder, aby zawsze korzystać z najnowszych wersji LTS i poprawek błędów związanych z Androidem.

Gałęź jądra ACK KMI

Jądra GKI mają stabilny interfejs Kernel Module Interface. KMI jest jednoznacznie identyfikowany przez wersję jądra i wersję platformy Androida, więc gałęzie mają nazwy ANDROID_RELEASE-KERNEL_VERSION. Na przykład jądro GKI 6.1 dla Androida 14 ma nazwę android14-6.1. W Androidzie 15 wprowadzono jądro GKI android15-6.6.

Funkcje i jądra uruchamiania

Przed Androidem 15 do 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. Rdzenie inicjujące Androida 15 to android15-6.6 i android14-6.1.

Ponieważ podczas aktualizacji wersji platformy nie są wymagane aktualizacje jądra, jądra, w których brakuje najnowszych funkcji wersji platformy, nadal mogą być używane do uruchamiania urządzeń. Dlatego jądra opracowane na potrzeby Androida 14, takie jak android14-6.1, można używać na urządzeniach nawet po uaktualnieniu wersji platformy do Androida 15.

Ogólna hierarchia jądra

Gałąź android-mainline

Rysunek 1 przedstawia najwyższy poziom hierarchii wspólnego jądra.

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

W 2022 r. z wersji android-mainline wyodrębniono nowe wspólne jądro Androida android14-6.1. W 2023 r., gdy ogłoszono następną wersję LTS, android15-6.6 została wyodrębniona z android-mainline.

Jak widać na rysunku 1, każda wersja rdzenia może być podstawą 2 rdzenia 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. android12-5.10 została utworzona, gdy ogłoszono wersję LTS, a android13-5.10 została odgałęziona od android12-5.10 w ramach etapu ukończenia funkcji jądra w wiosną 2021 r., aby umożliwić rozwój funkcji na potrzeby Androida 13. Od wersji 15 Androida (2024 r.) w przypadku każdej wersji jądra jest tylko 1 nowe jądro GKI (nie ma jądra android15-6.1).

Cykl życia gałęzi ACK KMI

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

Rysunek 2. 6.6 Cykl życia gałęzi ACK KMI

Aby wyjaśnić proces rozwoju i cykl życia gałęzi, rysunek 2 skupia się na gałęziach ACK KMI w wersji 6.6.

Każda gałąź KMI ACK przechodzi przez 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 przechodzi do fazy rozwoju (oznaczona jako dev na rysunku 2) i staje się dostępna dla programistów, którzy chcą wnosić do niej poprawki, aby można było ją uwzględnić w następnej wersji platformy Android. Na rysunku 2 element android15-6.6 został utworzony, gdy 6.6 zostało ogłoszone jako nowe jądro LTS w łańcuchu dostawy.

Stabilizacja

Gdy oświadczymy, że funkcja w gałęzi ACK KMI jest gotowa, rozpocznie się faza stabilizacji (oznaczona jako stabilna na rysunku 2). Funkcje partnera i poprawki błędów są nadal akceptowane, ale śledzenie KMI jest włączone, aby wykrywać wszelkie zmiany wpływające na interfejs. W tej fazie akceptowane są zmiany powodujące niezgodność z KMI, a definicja KMI jest aktualizowana zgodnie z wstępnie określonym harmonogramem (zwykle co 2 tygodnie). Szczegółowe informacje o monitorowaniu KMI znajdziesz w omówieniu GKI.

Faza zamrożenia KMI

Zanim nowa wersja platformy zostanie przesłana do AOSP, gałąź ACK KMI jest zamrożona i pozostanie zamrożona do końca jej istnienia. Oznacza to, że nie są akceptowane żadne zmiany, które naruszają KMI, chyba że zostanie zidentyfikowany poważny problem z bezpieczeństwem, którego nie można rozwiązać bez wpływu na stabilny KMI. Aby uniknąć problemów z KMI, niektóre poprawki scalone z LTS mogą zostać zmodyfikowane lub usunięte, jeśli poprawka nie jest wymagana na urządzeniach z Androidem.

Gdy gałąź KMI w wersji ACK jest zablokowana, można akceptować poprawki błędów i funkcje partnerów, o ile nie naruszają one wspólnego jądra KMI. KMI można rozszerzyć o nowe wyeksportowane symbole, o ile nie wpłynie to na interfejsy wchodzące w skład bieżącego KMI. Gdy do interfejsu KMI dodawane są nowe interfejsy, stają się one od razu stabilne i nie mogą zostać uszkodzone przez przyszłe zmiany.

Na przykład zmiana, która dodaje pole do struktury używanej przez interfejs KMI (common kernel), nie jest dozwolona, 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 dozwolone:

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 istnienia jądra GKI jest zachowana zgodność wsteczna z przestrzenią użytkownika, dzięki czemu można bezpiecznie używać jądra w ramach wersji platformy Android, z którą urządzenie zostało wprowadzone na rynek. Ciągłe testowanie z użyciem poprzednich wersji zapewnia zachowanie zgodności. Na rysunku 2 jądro android15-6.6może być używane na urządzeniach z Androidem 15 lub nowszym. Ponieważ wersja platformy Android jest też zgodna z poprzednimi wersjami, jądro android14-6.1 może być używane na urządzeniach z Androidem 15 na potrzeby uruchomienia lub aktualizacji.

Numer generacji KMI

Jeśli w fazie stabilizacji nastąpiło scalenie LTS, wystąpił problem z bezpieczeństwem lub inne zdarzenie, które wymaga zaakceptowania poprawki zmieniającej KMI, numer generacji KMI zapisany w pliku build.config.common zostanie zwiększony. Bieżącą generację KMI można znaleźć, używając polecenia uname:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

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

Jeśli generacja KMI ulegnie zmianie, jądro nie będzie zgodne z modułami dostawców, które są zgodne z poprzednią generacją KMI. Dlatego moduły należy ponownie skompilować i zaktualizować synchronicznie z jądrem. Po zamrożeniu KMI zmiany w generowaniu KMI powinny być bardzo rzadkie.

Zgodność między jądrami

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

Jądra GKI

Kernele GKI zachowują zgodność wsteczną ze wszystkimi wersjami platformy Android, które obsługiwały wersję jądra. Ponadto wersje platformy Android są wstecznie zgodne z jądrowymi interfejsami GKI z poprzednich wersji. Możesz bezpiecznie używać jądra android14-6.1 opracowanego na potrzeby Androida 14 (2023 r.) na urządzeniach z Androidem 15 (2024 r.). Zgodność jest weryfikowana przez ciągłe testowanie VTS i CTS jądra GKI we wszystkich obsługiwanych wersjach.

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

Kompatybilność KMI nie jest utrzymywana między różnymi rdzeniami GKI. Oznacza to, że na przykład jądra android14-6.1 nie można zastąpić jądrem android15-6.6 bez odtwarzania wszystkich modułów.

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

Tabela zgodności

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

Obsługa okresów ważności i poprawek zabezpieczeń

Aktualizacje Androida otrzymują zaktualizowane wersje LTS z górnego poziomu i poprawki błędów w konkretnym kodzie na Androida. Poprawki obejmują wszystkie poprawki zabezpieczeń jądra wymienione w comiesięcznych biuletynach o zabezpieczeniach Androida, które mają zastosowanie do ACK.

ACK mogą być obsługiwane dłużej niż odpowiadające im stabilne jądra 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 użytkowania, Google przestanie je obsługiwać, a urządzenia z tymi jądrami będą uznawane za podatne na zagrożenia.

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

Tabela poniżej zawiera czas życia obsługiwanych potwierdzeń:

Testowanie wspólnego jądra

Kernele wspólne są testowane za pomocą kilku systemów CI oraz testów dostawców.

Test funkcjonalny jądra Linuksa

Test funkcjonalny jądra Linuksa (LKFT): testy inicjują różne pakiety testów, w tym kselftest, LTP, VTS i CTS, na zestawie fizycznych urządzeń z procesorami ARM32 i ARM64. Najnowsze wyniki testów znajdziesz tutaj.

Testowanie KernelCI

Testy kompilacji i uruchamiania KernelCI są inicjowane za każdym razem, gdy nowa poprawka zostanie zaakceptowana w ramach wspólnej gałęzi jądra. Kilkaset konfiguracji kompilacji jest testowanych i uruchamianych na różnych płytach. Najnowsze wyniki dotyczące jąder Androida znajdziesz tutaj.

Testowanie przed i po przesłaniu aplikacji na Androida

Testy przed przesłaniem służą do zapobiegania wprowadzania błędów do wspólnych jąder Androida. Podsumowanie wyników testu znajdziesz na karcie „Checks” (Sprawdzanie) w zmianie kodu w gerrit do wspólnego jądra Androida.

Testowanie po przesłaniu Androida jest przeprowadzane na nowych opublikowanych kompilacjach w gałęziach wspólnego jądra Androida, gdy nowe poprawki zostaną zaakceptowane w gałęzi wspólnego jądra Androida na stronie ci.android.com. Po wpisaniu aosp_kernel jako częściowej nazwy gałęzi na stronie ci.android.com zobaczysz listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki wyszukiwania android-mainline znajdziesz tutaj. Po kliknięciu konkretnej kompilacji stan testu znajdziesz na karcie Test Results.

Testy zdefiniowane przez test-mapping z grupą testów kernel-presubmit w drzewie źródłowym platformy Android będą uruchamiane przed przesłaniem w przypadku gałęzi jądra Androida. Na przykład konfiguracja w pliku test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING spowoduje, że test vts_kernel_proc_file_api_test będzie wykonywany jako test presbumit w ramach wspólnego procesu weryfikacji kodu jądra Androida.

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

testowanie typu 0-day,

Testowanie 0-day polega na testowaniu poszczególnych poprawek na wszystkich gałęziach jądra Androida, gdy zostaną wdrożone nowe poprawki. Przeprowadzane są różne testy rozruchu, funkcjonalności i wydajności. Dołącz do grupy publicznej cros-kernel-buildreports

Zestaw testów

Wspieranie tworzenia wspólnych jąder Androida

Ogólnie rzecz biorąc, funkcje powinny być rozwijane na głównych jądrach Linuksa, a nie na wspólnych jądrach Androida. Zdecydowanie zachęcamy do wdrażania zmian w głównym gałęzi. Po zaakceptowaniu zmian można je łatwo przenieść do konkretnej gałęzi ACK. Zespół odpowiedzialny za jądro Androida chętnie wspiera wysiłki związane z przesyłaniem kodu w górę, które przynoszą korzyści ekosystemowi Androida.

Przesyłaj poprawki do Gerrit i przestrzegaj tych wytycznych dotyczących wkładu.