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-qpr1 |
Pixel 6a (bluejay) | dispositivo/google/bluejay-kernel | android-gs-bluejay-5.10-android13-qpr1 |
Pixel 6 (oriole) Pixel 6 Pro (corvo) | dispositivo/google/raviole-kernel | android-gs-raviole-5.10-android13-qpr1 |
Pixel 5a (barbet) Pixel 5 (redfin) Pixel 4a (5G) (bramble) | dispositivo/google/redbull-kernel | android-msm-redbull-4.19-android13-qpr1 |
Pixel 4a (peixe-lua) | device/google/sunfish-kernel | android-msm-sunfish-4.14-android13-qpr1 |
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-android14-6.1 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-android14-6.1 common-android-mainline | ✅ | ❌ |
db845c | common-android13-5.10 | ❌ | ✅ |
db845c | common-android13-5.15 | ✅ | ✅ (oficial) 1 |
db845c | common-android14-5.15 common-android14-6.1 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-android14-6.1 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-android14-6.1 common-android-mainline | ✅ | ❌ |
Rockpi4 | common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
Rockpi4 | common-android14-5.15 common-android14-6.1 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 | ✅ | ❌ |
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.
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
.