O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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.

Dispositivo Caminho binário na árvore AOSP Ramos de recompra
Pixel 7 (pantera)
Pixel 7 Pro (chita)
dispositivo/google/pantah-kernel android-gs-pantah-5.10-android13-d1
Pixel 6a (bluejay) dispositivo/google/bluejay-kernel android-gs-bluejay-5.10-android13
Pixel 6 (oriole)
Pixel 6 Pro (corvo)
dispositivo/google/raviole-kernel android-gs-raviole-5.10-android13
Pixel 5a (barbet) dispositivo/google/barbet-kernel android-msm-barbet-4.19-android13
Pixel 5 (redfin)
Pixel 4a (5G) (bramble)
dispositivo/google/redbull-kernel android-msm-redbull-4.19-android13
Pixel 4a (peixe-lua) device/google/sunfish-kernel android-msm-sunfish-4.14-android13
Pixel 4 (chama)
Pixel 4 XL (coral)
dispositivo/google/coral-kernel android-msm-coral-4.14-android13
Pixel 3a (sargo)
Pixel 3a XL (bonito)
dispositivo/google/bonito-kernel android-msm-bonito-4.9-android12L
Pixel 3 (linha azul)
Pixel 3 XL (hachura)
device/google/crosshatch-kernel android-msm-hatch-4.9-android12
Pixel 2 (walleye)
Pixel 2 XL (taimen)
dispositivo/google/wahoo-kernel android-msm-wahoo-4.4-android10-qpr3
Pixel (peixe-vela)
Pixel XL (marlim)
dispositivo/google/marlin-kernel android-msm-marlin-3.18-pie-qpr2
Hikey960 dispositivo/linaro/hikey-kernel hikey-linaro-android-4.14
hikey-linaro-android-4.19
common-android12-5.4
common-android13-5.10
Beagle x15 dispositivo/ti/beagle_x15-kernel omap-beagle-x15-android-4.14
omap-beagle-x15-android-4.19
Kernel comum do Android N / D common-android-4.4
common-android-4.9
common-android-4.14
common-android-4.19
comum-android-4.19-estável
common-android11-5.4
common-android12-5.4
common-android12-5.10
common-android13-5.10
common-android13-5.15
common-android14-5.15
common-android-mainline

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.

Dispositivo Ramos de recompra Suporte Kleaf suporte build/build.sh
Kernel comum do Android
db845c
Dispositivo virtual (x86_64, arm64)
Dispositivo virtual (i686, braço)
Rockpi4
common-android-4.4
common-android-4.9
common-android-4.14
common-android-4.19
comum-android-4.19-estável
common-android11-5.4
common-android12-5.4
common-android12-5.10
Kernel comum do Android common-android13-5.10
common-android13-5.15
✅ (oficial) 1
Kernel comum do Android common-android14-5.15
common-android-mainline
db845c common-android13-5.10
db845c common-android13-5.15 ✅ (oficial) 1
db845c common-android14-5.15
common-android-mainline
Dispositivo virtual (x86_64, arm64) common-android13-5.10
common-android13-5.15
✅ (oficial) 1 ⚠️ (sem manutenção) 2
Dispositivo virtual (x86_64, arm64) common-android14-5.15
common-android-mainline
Dispositivo virtual (i686, braço) common-android13-5.10
common-android13-5.15
Dispositivo virtual (i686, braço) common-android14-5.15
common-android-mainline
Rockpi4 common-android13-5.10
common-android13-5.15
Rockpi4 common-android14-5.15
common-android-mainline
Hikey960 hikey-linaro-android-4.14
hikey-linaro-android-4.19
common-android12-5.4
common-android13-5.10
módulo fips140 common-android12-5.10
common-android13-5.10
common-android13-5.15
módulo fips140 common-android14-5.15
common-android-mainline

1 "Oficial" significa que esta é a forma oficial de compilar o kernel, embora a forma alternativa também possa ser usada para compilar o kernel.

2 "Não mantido" significa que a compilação do kernel com este método deve funcionar, mas o método de compilação não é testado continuamente. Pode parar de construir no futuro. Em vez disso, use a maneira "oficial" de construir.

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 .

Variável de ambiente Descrição Exemplo
BUILD_CONFIG Crie o arquivo de configuração de onde você inicializa o ambiente de construção. O local deve ser definido em relação ao diretório raiz do Repo. O padrão é build.config .
Obrigatório para kernels comuns.
BUILD_CONFIG=common/build.config.gki.aarch64
CC Substitua o compilador a ser usado. Volta para o compilador padrão definido por build.config . CC=clang
DIST_DIR Diretório de saída base para a distribuição do kernel. DIST_DIR=/path/to/my/dist
OUT_DIR Diretório de saída base para a compilação do kernel. OUT_DIR=/path/to/my/out
SKIP_DEFCONFIG Ignorar make defconfig SKIP_DEFCONFIG=1
SKIP_MRPROPER Pular make mrproper SKIP_MRPROPER=1

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. Para fazer isso, 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 .