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

Como criar kernels

Esta página detalha o processo de criação de kernels personalizados para dispositivos Android. As instruções a seguir oferecem orientação sobre o processo para selecionar as origens certas, criar o kernel e incorporar os resultados em uma imagem do sistema criada usando o Android Open Source Project (AOSP).

Você pode conseguir origens de kernel mais recentes usando o Repo. Crie sem precisar de mais configurações executando build/build.sh pela raiz da saída da origem.

Como fazer o download de origens e ferramentas de build

Para kernels recentes, use o repo para fazer o download de origens, conjuntos de ferramentas e scripts de criação. Alguns kernels (como os do Pixel 3) exigem origens de vários repositórios git, enquanto outros (como os comuns) exigem apenas uma origem. O uso da abordagem repo garante uma configuração correta do diretório de origem.

Faça o download das origens para a ramificação adequada:

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 de BRANCH para kernels disponíveis por meio desse método.

Dispositivo Caminho do binário na árvore AOSP Ramificações do Repo
Pixel 6 (oriole)
Pixel 6 Pro (raven)		 device/google/raviole-kernel android-gs-raviole-5.10-android12L
Pixel 5a (barbet) device/google/barbet-kernel android-msm-barbet-4.19-android12L
Pixel 5 (redfin)
Pixel 4a 5G (bramble)		 device/google/redbull-kernel android-msm-redbull-4.19-android12L
Pixel 4a (sunfish) device/google/sunfish-kernel android-msm-sunfish-4.14-android12L
Pixel 4 (flame)
Pixel 4 XL (coral)		 device/google/coral-kernel android-msm-coral-4.14-android12L
Pixel 3a (sargo)
Pixel 3a XL (bonito)		 device/google/bonito-kernel android-msm-bonito-4.9-android12L
Pixel 3 (blueline)
Pixel 3 XL (crosshatch)		 device/google/crosshatch-kernel android-msm-crosshatch-4.9-android12
Pixel 2 (walleye)
Pixel 2 XL (taimen)		 device/google/wahoo-kernel android-msm-wahoo-4.4-android10-qpr3
Pixel (sailfish)
Pixel XL (marlin)		 device/google/marlin-kernel android-msm-marlin-3.18-pie-qpr2
Hikey960 device/linaro/hikey-kernel hikey-linaro-android-4.14
hikey-linaro-android-4.19
common-android12-5.4
Beagle x15 device/ti/beagle_x15-kernel omap-beagle-x15-android-4.14
omap-beagle-x15-android-4.19
Kernel comum do Android N/A common-android-4.4
common-android-4.9
common-android-4.14
common-android-4.19
common-android-4.19-stable
common-android11-5.4
common-android12-5.4
common-android12-5.10
common-android13-5.10
common-android13-5.15
common-android-mainline

Como criar o kernel

Em seguida, crie o kernel com este código:

build/build.sh

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

Como criar os módulos de GKI

O Android 11 introduziu a GKI, que separa o kernel em uma imagem do kernel mantida pelo Google e em 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 uma configuração de módulo (Cuttlefish e Emulator):

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

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

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

Como executar o kernel

Há várias maneiras de executar um kernel personalizado. A seguir, apresentamos as maneiras conhecidas que são adequadas para vários cenários de desenvolvimento.

Como incorporar na criação da imagem do Android

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

Outra alternativa é definir a variável TARGET_PREBUILT_KERNEL ao usar make bootimage (ou qualquer outra linha de comando make que crie uma imagem de inicialização). Essa variável é compatível com todos os dispositivos porque é configurada por device/common/populate-new-device.sh. Por exemplo:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Como realizar uma atualização flash e inicializar kernels com fastboot

Os dispositivos mais recentes têm uma extensão do carregador de inicialização para otimizar o processo que gera e inicia uma imagem de inicialização.

Para inicializar o kernel sem realizar uma atualização flash:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Com o uso desse método, uma atualização flash não é realizada no kernel e não persiste durante a reinicialização.

Personalizar a criação do kernel

O processo de criação e o resultado podem ser influenciados por variáveis de ambiente. A maior parte das variáveis é opcional e cada branch do kernel apresenta uma configuração padrão adequada. As mais usadas estão listadas aqui. Para ver uma lista completa (e atualizada), consulte build/build.sh.

Variável de ambiente Descrição Exemplo
BUILD_CONFIG Cria o arquivo de configuração a partir do qual você inicializa o ambiente de build. O local precisa ser definido em relação ao diretório raiz do Repo. O valor padrão é build.config.
Obrigatório para kernels comuns. 		BUILD_CONFIG=common/build.config.gki.aarch64
CC Substitui o compilador a ser usado. Volta para o compilador padrão definido pelo 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 o build do kernel. OUT_DIR=/path/to/my/out
SKIP_DEFCONFIG Pula a make defconfig SKIP_DEFCONFIG=1
SKIP_MRPROPER Pula make mrproper SKIP_MRPROPER=1

Configuração personalizada do kernel para builds locais

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

Defina a variável POST_DEFCONFIG_CMDS como uma declaração que é avaliada logo após a etapa normal de make defconfig ter sido realizada. Como os arquivos build.config são originados no ambiente de compilaçã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 vinculação (LTO, na sigla em inglês) para kernels crosshatch durante o desenvolvimento. Embora a LTO seja benéfica para os kernels lançados, a sobrecarga no tempo de criação pode ser significativa. O snippet a seguir, incluído no build.config local, sempre desativa a LTO 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)
}

Como identificar as versões do kernel

Você pode identificar a versão correta para criar usando duas origens: a árvore AOSP e a imagem do sistema.

Versão do kernel da árvore AOSP

A árvore AOSP contém versões pré-criadas do kernel. O log do git 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 log do git, consiga-a pela 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

Como criar uma imagem de inicialização

É possível criar uma imagem de inicialização usando o ambiente de build do kernel. Para isso, você precisa de um binário do ramdisk, que pode ser adquirido ao fazer o download de uma imagem de inicialização GKI e descompactá-la. 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 tools/mkbootimg/out/ramdisk gki-ramdisk.lz4

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

Se você estiver desenvolvendo com o AOSP mestre, faça o download do artefato de compilação ramdisk-recovery.img de um build aosp_arm64 em ci.android.com e use-o como seu binário do ramdisk.

Depois de conseguir um binário do ramdisk e copiá-lo para gki-ramdisk.lz4 no diretório raiz do build do kernel, execute o seguinte para gerar uma imagem de inicialização:

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ê está trabalhando com uma 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 artefatos $KERNEL_ROOT/out/$KERNEL_VERSION/dist.

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