Kompilowanie jąder

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

Ta strona zawiera szczegółowe informacje o procesie tworzenia niestandardowych jąder na urządzenia z Androidem. Te instrukcje przeprowadzą Cię przez proces wybierania odpowiednich źródeł, kompilowania jądra i osadzania wyników w obrazu systemu utworzonego na podstawie projektu Android Open Source (AOSP).

Pobieranie źródeł i narzędzi do kompilacji

W przypadku najnowszych jąder użyj repo, aby pobrać źródła, zestaw narzędzi i skrypty kompilacji. Niektóre jądra (np. jądra Pixela 3) wymagają źródeł z kilku repozytoriów Git, a inne (np. wspólne jądra) wymagają tylko jednego źródła. Korzystanie z metody repo zapewnia prawidłową konfigurację katalogu źródeł.

Pobierz źródła dla odpowiedniej gałęzi:

mkdir android-kernel && cd android-kernel

repo init -u https://android.googlesource.com/kernel/manifest -b BRANCH

repo sync

Listę gałęzi repozytorium (BRANCH), które można używać z poprzednim poleceniem `repo init`, znajdziesz w sekcji Gałęzie jądra i ich systemy kompilacji.

Szczegółowe informacje o pobieraniu i kompilowaniu jąder na urządzeniach Pixel znajdziesz w artykule Kompilowanie jąder Pixel.

Kompilowanie jądra

Kompilowanie za pomocą Bazel (Kleaf)

Android 13 wprowadził kompilowanie jąder za pomocą Bazel.

Aby utworzyć dystrybucję jądra GKI dla architektury aarch64, pobierz gałąź Android Common Kernel nie starszą niż Android 13, a potem uruchom to polecenie:

tools/bazel run //common:kernel_aarch64_dist [-- --destdir=$DIST_DIR]

Następnie binarny jądro, moduły i odpowiednie obrazy znajdują się w katalogu $DIST_DIR. Jeśli parametr --destdir nie jest określony, informacje o lokalizacji artefaktów znajdziesz w wyjściu tego polecenia. Szczegółowe informacje znajdziesz w dokumentacji AOSP.

Kompilowanie za pomocą build.sh (starsza wersja)

Odgałę na Androidzie 12 lub starszym LUB na gałęzi bez Kleaf:

build/build.sh

Plik binarny jądra, moduły i odpowiednia obraz znajdują się w katalogu out/BRANCH/dist.

Utwórz moduły dostawcy dla urządzenia wirtualnego

Android 13 wprowadził kompilowanie jąder za pomocą Bazel (Kleaf), zastępując build.sh.

Aby utworzyć dystrybucję dla modułów usługi virtual_device, wykonaj te czynności:

tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist [-- --destdir=$DIST_DIR]

Więcej informacji o generowaniu jąder Androida za pomocą Bazel znajdziesz tutaj: Kleaf – tworzenie jąder Androida za pomocą Bazel

Szczegółowe informacje o obsługiwanych przez Kleaf architekturach znajdziesz w artykule Obsługa Kleaf w przypadku urządzeń i jąder.

Kompilowanie modułów dostawcy dla urządzenia wirtualnego za pomocą build.sh (wersja starsza)

W Androidzie 12 Cuttlefish i Goldfish są z sobą zbliżone, więc mają ten sam jądro: virtual_device. Aby skompilować moduły tego jądra, użyj tej konfiguracji kompilacji:

BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.x86_64 build/build.sh

Android 11 wprowadził GKI, który dzieli jądro na obraz jądra obsługiwany przez Google i moduły obsługiwane przez producenta, które są kompilowane osobno.

Ten przykład pokazuje konfigurację obrazu jądra:

BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh

Ten przykład pokazuje konfigurację modułu (Cuttlefish i Emulator):

BUILD_CONFIG=common-modules/virtual-device/build.config.cuttlefish.x86_64 build/build.sh

Uruchamianie jądra

Istnieje kilka sposobów uruchamiania niestandardowego jądra. Poniżej przedstawiamy znane sposoby odpowiednie do różnych scenariuszy programowania.

Wstawianie w kompilacji obrazu Androida

Skopiuj Image.lz4-dtb do odpowiedniej lokalizacji binarnej jądra w drzewie AOSP i utwórz ponownie obraz rozruchowy.

Możesz też zdefiniować zmienną TARGET_PREBUILT_KERNEL, używając polecenia make bootimage (lub dowolnego innego polecenia wiersza poleceń make, które tworzy obraz rozruchowy). Ta zmienna jest obsługiwana na wszystkich urządzeniach, ponieważ jest konfigurowana za pomocą device/common/populate-new-device.sh. Przykład:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Flashowanie i uruchamianie jądra za pomocą fastboot

Najnowsze urządzenia mają rozszerzenie programu rozruchowego, które upraszcza proces generowania i uruchamiania obrazu rozruchowego.

Aby uruchomić jądro bez flashowania:

adb reboot bootloader
fastboot boot Image.lz4-dtb

W przypadku tej metody nie następuje flashowanie jądra i nie będzie ono zachowane po ponownym uruchomieniu.

Uruchamianie jąder w Cuttlefish

Na urządzeniach typu Cuttlefish możesz uruchamiać jądra o dowolnej architekturze.

Aby uruchomić urządzenie Cuttlefish z określonym zestawem elementów jądra, uruchom polecenie cvd create, podając jako parametry docelowe elementy jądra. W tym przykładowym poleceniu użyto artefaktów jądra dla celu arm64 z manifestu jądra (common-android14-6.1).

cvd create \
    -kernel_path=/$PATH/$TO/common-android14-6.1/out/android14-6.1/dist/Image \
    -initramfs_path=/$PATH/$TO/common-android14-6.1/out/android14-6.1/dist/initramfs.img

Więcej informacji znajdziesz w artykule Tworzenie jąder w Cuttlefish.

Dostosowywanie wersji jądra

Aby dostosować kompilacje jądra dla kompilacji Kleaf, zapoznaj się z dokumentacją Kleaf.

Dostosowywanie kompilacji jądra za pomocą build.sh (wersja starsza)

W przypadku build/build.sh zmienne środowiskowe mogą mieć wpływ na proces kompilacji i jego wynik. Większość z nich jest opcjonalna, a każda gałąź jądra powinna być dostarczana z odpowiednią domyślną konfiguracją. Poniżej znajdziesz najczęściej używane z nich. Pełną (i aktualną) listę znajdziesz na stronie build/build.sh.

Niestandardowa konfiguracja jądra w przypadku wersji lokalnych

W Androidzie 14 i nowszych możesz używać fragmentów defconfig do dostosowywania konfiguracji jądra. Więcej informacji znajdziesz w dokumentacji Kleaf na temat fragmentów defconfig.

Niestandardowa konfiguracja jądra dla kompilacji lokalnych z konfiguracjami kompilacji (starsza wersja)

W przypadku Androida 13 i starszych:

Jeśli musisz regularnie przełączać opcję konfiguracji jądra, na przykład podczas pracy nad funkcją, lub jeśli musisz ustawić opcję na potrzeby rozwoju, możesz uzyskać taką elastyczność, zachowując lokalną modyfikację lub kopię konfiguracji kompilacji.

Ustaw zmienną POST_DEFCONFIG_CMDS na instrukcję, która jest oceniana bezpośrednio po zakończeniu zwykłego kroku make defconfig. Ponieważ pliki build.config są pobierane do środowiska kompilacji, funkcje zdefiniowane w pliku build.config mogą być wywoływane w ramach poleceń po skonfigurowaniu definicji.

Typowym przykładem jest wyłączenie optymalizacji w czasie łączenia (LTO) dla jąder krzyżujących się podczas tworzenia. Chociaż LTO jest korzystne w przypadku opublikowanych jąder, nakład pracy w czasie kompilacji może być znaczny. Ten fragment kodu dodany do pliku build.config wyłącza LTO na stałe podczas korzystania z pliku build/build.sh.

POST_DEFCONFIG_CMDS="check_defconfig && update_debug_config"
function update_debug_config() {
    ${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
         -d LTO \
         -d LTO_CLANG \
         -d CFI \
         -d CFI_PERMISSIVE \
         -d CFI_CLANG
    (cd ${OUT_DIR} && \
     make O=${OUT_DIR} $archsubarch CC=${CC} CROSS_COMPILE=${CROSS_COMPILE} olddefconfig)
}

Określanie wersji jądra

Prawidłową wersję do skompilowania możesz określić na podstawie 2 źródeł: drzewa AOSP i obrazu systemu.

Wersja jądra z drzewa AOSP

Drzewo AOSP zawiera gotowe wersje jądra. Log gita pokazuje poprawną wersję w ramach wiadomości o zmianie:

cd $AOSP/device/VENDOR/NAME
git log --max-count=1

Jeśli wersja jądra nie jest wymieniona w logu git, pobierz ją z obrazu systemu, jak opisano poniżej.

Wersja jądra z obrazu systemu

Aby określić wersję jądra używaną w pliku obrazu systemu, uruchom to polecenie w pliku jądra:

file kernel

W przypadku plików Image.lz4-dtb wykonaj:

grep -a 'Linux version' Image.lz4-dtb

Tworzenie obrazu rozruchowego

Obraz rozruchowy można skompilować za pomocą środowiska kompilacji jądra.

Tworzenie obrazu rozruchowego dla urządzeń z init_boot

W przypadku urządzeń z partycją init_boot obraz rozruchu jest tworzony razem z jądrem. Obraz initramfs nie jest osadzony w obrazie rozruchowym.

Na przykład w przypadku Kleaf możesz utworzyć obraz rozruchowy GKI za pomocą:

tools/bazel run //common:kernel_aarch64_dist [-- --destdir=$DIST_DIR]

W przypadku build/build.sh (starsza wersja) możesz utworzyć obraz rozruchowy GKI za pomocą:

BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh

Obraz rozruchowy GKI znajduje się w $DIST_DIR.

Tworzenie obrazu rozruchowego na urządzeniach bez init_boot (wersja starsza)

W przypadku urządzeń bez partycji init_boot musisz mieć plik binarny ramdisk, który możesz uzyskać, pobierając obraz rozruchowy GKI i rozpakowując go. Dobrze sprawdzi się dowolny obraz GKI z powiązanej wersji Androida.

tools/mkbootimg/unpack_bootimg.py --boot_img=boot-5.4-gz.img
mv $KERNEL_ROOT/out/ramdisk gki-ramdisk.lz4

Folder docelowy to katalog główny drzewa jądra (bieżący katalog roboczy).

Jeśli pracujesz z najnowszą gałęzi wersji AOSP, możesz zamiast tego pobrać artefakt kompilacji ramdisk-recovery.img z kompilacji aosp_arm64 na stronie ci.android.com i użyć go jako binarnego pliku ramdisk.

Gdy masz plik binarny dysku RAM i skopiujesz go do gki-ramdisk.lz4 w katalogu głównym wersji jądra, możesz wygenerować obraz rozruchowy, wykonując:

BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=Image GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh

Jeśli pracujesz na architekturze x86, zastąp Image wartością bzImage, a aarch64 wartością x86_64:

BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=bzImage GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh

Ten plik znajduje się w katalogu artefaktów $KERNEL_ROOT/out/$KERNEL_VERSION/dist.

Obraz rozruchowy znajduje się pod adresem out/<kernel branch>/dist/boot.img.