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ć:

• Wsteczne wdrożenia i wybrane funkcje z górnego poziomu potrzebne do obsługi funkcji Androida
• Funkcje gotowe na urządzenia z Androidem, ale nadal w fazie rozwoju w górę.
• 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, 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 wersją 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 systemu Linux, została ona scalona z powszechnie używanym jądrem 6.1 (android14-6.1). Partnerów gorąco zachęcamy do aktualizowania jąder, aby zawsze korzystać z najnowszych wersji LTS i poprawek dotyczących Androida.

Gałęź jądra ACK KMI

Jądra GKI mają stabilny interfejs Kernel Module. 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 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

Najwyższy poziom wspólnej hierarchii jądra pokazano na rysunku 1.

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

Etap rozwoju

Po utworzeniu gałąź ACK KMI wchodzi w fazę rozwoju (oznaczoną na rysunku 2 jako dev) i staje się dostępna dla wkładów w postaci funkcji do następnej wersji platformy Android. Na rysunku 2 android15-6.6 została utworzona, gdy 6.6 zostało ogłoszone jako nowe jądro LTS w łańcuchu dostawy.

Stabilizacja

Gdy oświadczymy, że w gałęzi ACK KMI funkcja 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 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 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 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 można ich zmienić w przyszłych aktualizacjach.

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 na potrzeby uruchomienia lub aktualizacji.

Numer generacji KMI

Jeśli w fazie stabilizacji nastąpiło scalone wydanie LTS, wystąpił problem z bezpieczeństwem lub inne zdarzenie, które wymaga zaakceptowania poprawki zmieniającej KMI, liczba generacji KMI zapisana w build.config.common zostanie zwiększona. 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

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ądr 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. 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 dodana do 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 łaty są zatwierdzane 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 obejmuje testowanie każdej poprawki w ramach wszystkich typowych gałęzi jądra Androida, gdy zostaną wdrożone nowe poprawki. Przeprowadzane są różne testy: testy uruchamiania, 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 zalecamy wdrażanie zmian w głównym repozytorium, 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 zaleceń dotyczących wkładu.