Construindo Kernels

Esta página detalha o processo de criação de kernels personalizados para dispositivos Android. Essas instruções orientam você no processo de seleção das fontes corretas, construção do kernel e incorporação dos resultados em uma imagem do sistema criada a partir do Android Open Source Project (AOSP).

Você pode adquirir fontes de kernel mais recentes usando Repo ; construa-os sem configuração adicional executando build/build.sh a partir da raiz de sua verificação de origem.

Download de fontes e ferramentas de compilação

Para kernels recentes, use o repo para baixar as fontes, a cadeia de ferramentas e os scripts de construção. Alguns kernels (por exemplo, os kernels do Pixel 3) requerem fontes de vários repositórios git, enquanto outros (por exemplo, os kernels comuns) requerem apenas uma única fonte. O uso da abordagem de repo garante uma configuração correta do diretório de origem.

Baixe as fontes para o ramo apropriado:

mkdir android-kernel && cd android-kernel

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

repo sync

A tabela a seguir lista os nomes BRANCH para kernels disponíveis por meio desse método.

Construindo o núcleo

Em seguida, construa o kernel com isto:

build/build.sh

O binário do kernel, os módulos e a imagem correspondente estão localizados no diretório out/ BRANCH /dist .

Construindo com Bazel (Kleaf)

O Android 13 introduziu a compilação de kernels com Bazel , substituindo build/build.sh .

Para criar o kernel GKI para a arquitetura aarch64, verifique uma ramificação Android Common Kernel não anterior ao Android 13 e, em seguida, execute o seguinte comando:

tools/bazel build //common:kernel_aarch64_dist

Para criar uma distribuição, execute:

tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR

Depois disso, o binário do kernel, os módulos e as imagens correspondentes estão localizados no diretório $DIST_DIR . Se --dist_dir não for especificado, consulte a saída do comando para obter a localização dos artefatos. Para obter detalhes, consulte a documentação do AOSP .

Construindo os módulos do fornecedor para o dispositivo virtual

O Android 11 introduziu o GKI , que separa o kernel em uma imagem do kernel mantida pelo Google e módulos mantidos pelo fornecedor, que são criados separadamente.

Este exemplo mostra uma configuração de imagem do kernel:

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

Este exemplo mostra a configuração de um módulo (Cuttlefish e Emulador):

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

No Android 12 Cuttlefish e Goldfish convergem, então eles compartilham o mesmo kernel: virtual_device . Para compilar os módulos desse kernel, use esta configuração de compilação:

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

O Android 13 introduziu a compilação de kernels com Bazel (Kleaf), substituindo build.sh .

Para construir os módulos do virtual_device , execute:

tools/bazel build //common-modules/virtual-device:virtual_device_x86_64_dist

Para criar uma distribuição, execute:

tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist -- --dist_dir=$DIST_DIR

Para obter mais detalhes sobre a criação de kernels Android com Bazel, consulte. Kleaf - Construindo Kernels Android com Bazel .

Para obter detalhes sobre o suporte do Kleaf para arquiteturas individuais, consulte Suporte do Kleaf para dispositivos e kernels .

Suporte Kleaf para dispositivos e kernels

A tabela a seguir lista o suporte do Kleaf para kernels de dispositivos individuais. Para dispositivos não listados, entre em contato com o fabricante do dispositivo.

Executando o kernel

Existem várias maneiras de executar um kernel personalizado. A seguir estão maneiras conhecidas adequadas para vários cenários de desenvolvimento.

Incorporando na construção da imagem do Android

Copie Image.lz4-dtb para o respectivo local binário do kernel na árvore AOSP e reconstrua a imagem de inicialização.

Como alternativa, defina a variável TARGET_PREBUILT_KERNEL ao usar make bootimage (ou qualquer outra linha de comando make que crie uma imagem de inicialização). Esta variável é suportada por todos os dispositivos, pois é configurada via device/common/populate-new-device.sh . Por exemplo:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Piscando e inicializando kernels com fastboot

Os dispositivos mais recentes têm uma extensão de bootloader para agilizar o processo de geração e inicialização de uma imagem de inicialização.

Para inicializar o kernel sem piscar:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Usando esse método, o kernel não é realmente atualizado e não persiste em uma reinicialização.

Personalizando a compilação do kernel

Para personalizar as compilações do kernel para as compilações do Kleaf, consulte a documentação do Kleaf .

Para build/build.sh , o processo de compilação e o resultado podem ser influenciados por variáveis ​​de ambiente. A maioria deles é opcional e cada ramificação do kernel deve vir com uma configuração padrão adequada. Os mais usados ​​estão listados aqui. Para obter uma lista completa (e atualizada), consulte build/build.sh .

Configuração de kernel personalizada para compilações locais

Se você precisar alternar uma opção de configuração do kernel regularmente, por exemplo, ao trabalhar em um recurso, ou se precisar definir uma opção para fins de desenvolvimento, poderá obter essa flexibilidade mantendo uma modificação local ou cópia da configuração de compilação.

Defina a variável POST_DEFCONFIG_CMDS para uma instrução que é avaliada logo após a conclusão da etapa usual de make defconfig . Como os arquivos build.config são originados no ambiente de construção, as funções definidas em build.config podem ser chamadas como parte dos comandos post-defconfig.

Um exemplo comum é desativar a otimização de tempo de link (LTO) para kernels hachurados durante o desenvolvimento. Embora o LTO seja benéfico para kernels lançados, a sobrecarga no tempo de compilação pode ser significativa. O snippet a seguir adicionado ao build.config local desativa o LTO persistentemente ao usar 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)
}

Identificando versões do kernel

Você pode identificar a versão correta para construir a partir de duas fontes: a árvore AOSP e a imagem do sistema.

Versão do kernel da árvore AOSP

A árvore AOSP contém versões de kernel pré-compiladas. O git log revela a versão correta como parte da mensagem de confirmação:

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

Se a versão do kernel não estiver listada no git log, obtenha-a na imagem do sistema, conforme descrito abaixo.

Versão do kernel da imagem do sistema

Para determinar a versão do kernel usada em uma imagem do sistema, execute o seguinte comando no arquivo do kernel:

file kernel

Para arquivos Image.lz4-dtb , execute:

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

Criando uma imagem de inicialização

É possível construir uma imagem de inicialização usando o ambiente de construção do kernel.

Construindo uma imagem de inicialização para dispositivos com init_boot

Para dispositivos com a partição init_boot , a imagem de inicialização é construída junto com o kernel. A imagem initramfs não está incorporada na imagem de inicialização.

Por exemplo, com o Kleaf, você pode criar a imagem de inicialização GKI com:

tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR

Com build/build.sh , você pode criar a imagem de inicialização GKI com:

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

A imagem de inicialização GKI está localizada em $DIST_DIR .

Construindo uma imagem de inicialização para dispositivos sem init_boot

Para dispositivos sem a partição init_boot , você precisa de um binário ramdisk, que pode ser obtido baixando uma imagem de inicialização GKI e descompactando-a. Qualquer imagem de inicialização GKI da versão associada do Android funcionará.

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

A pasta de destino é o diretório de nível superior da árvore do kernel (o diretório de trabalho atual).

Se você estiver desenvolvendo com o mestre AOSP, poderá fazer o download do artefato de compilação ramdisk-recovery.img de uma compilação aosp_arm64 em ci.android.com e usá-lo como seu binário ramdisk.

Quando você tem um binário ramdisk e o copiou para gki-ramdisk.lz4 no diretório raiz da compilação do kernel, você pode gerar uma imagem de inicialização executando:

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

Se você estiver trabalhando com arquitetura baseada em x86, substitua Image por bzImage e aarch64 por 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

Esse arquivo está localizado no diretório de artefato $KERNEL_ROOT/out/$KERNEL_VERSION/dist .

A imagem de boot está localizada em out/<kernel branch>/dist/boot.img .