Wspólne jądra Androida

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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

• Backporty i wybrane funkcje z upstreamu 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 w ekosystemie

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 przenoszeniem i testowaniem poprawek Androida, ponieważ osiąga ten sam efekt stopniowo. android-mainline jest stale testowany, co zapewnia wysoką jakość jądra od dnia jego opublikowania.

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 ją 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, dlatego 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

Odgałęzienie z 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 jądra 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 rdzeni 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 osiągnięcia kamienia milowego dotyczącego ukończenia funkcji jądra wiosną 2021 r., aby umożliwić rozwój funkcji na potrzeby Androida 13. Od wersji 15 Androida (2024 r.) jest tylko 1 nowe jądro GKI na wersję jądra (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 wkładów w postaci funkcji do 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 upstream.

Stabilizacja

Gdy oświadczymy, że w gałęzi ACK KMI funkcja jest gotowa, wejdzie ona w fazę stabilizacji (oznaczoną na rysunku 2 jako stabilna). 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 zdefiniowanym 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 przez cały okres istnienia gałęzi. 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 powoduje to problemów z dotychczasowym wspólnym jądrem 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 ono wstecznie zgodne z przestrzenią użytkownika, dzięki czemu można go bezpiecznie używać 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.6 moż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 zarówno do uruchomienia, jak i uaktualnienia.

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 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 zgodnymi 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

Począwszy od nowych jąder GKI zmieniają się wymagania dotyczące zgodności między jądrami należącymi do tej samej rodziny jąder LTS.

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 graficznymi GKI z poprzednich wersji. Możesz więc bezpiecznie używać jądra android14-6.1 opracowanego na potrzeby Androida 14 (2023) na urządzeniach z Androidem 15 (2024). 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ż odpowiednie 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łównym Linuksie, a nie na wspólnych jądrach Androida. Zdecydowanie zachęcamy do wdrażania zmian w głównym projekcie, a po ich zaakceptowaniu można je łatwo przenieść do odpowiedniej 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.