Configuração do kernel

Use as configurações a seguir como base para uma configuração do kernel do Android. As configurações são organizadas em arquivos .cfg para android-base, android-base-ARCH e android-recommended:

  • As opções android-base ativam os principais recursos do Android e precisam ser configuradas conforme especificado por todos os dispositivos.
  • As opções de android-base-ARCH ativam os principais recursos do Android e precisam ser configuradas conforme especificado por todos os dispositivos da arquitetura ARCH. Nem todas as arquiteturas têm um arquivo correspondente de opções obrigatórias específicas da arquitetura. Se a arquitetura não tiver um arquivo, ela não terá requisitos de configuração de kernel específicos para a arquitetura para o Android.
  • android-recommended. Essas opções ativam recursos avançados do Android e são opcionais para dispositivos.

Esses arquivos de configuração estão localizados no repositório kernel/configs. Use o conjunto de arquivos de configuração que corresponde à versão do kernel que você está usando.

Para saber mais sobre os controles já realizados para fortalecer o kernel nos dispositivos, consulte Segurança do sistema e do kernel. Para saber mais sobre as configurações necessárias, consulte o Documento de definição de compatibilidade do Android (CDD).

Gerar a configuração do kernel

Para dispositivos com um formato defconfig minimalista, use o script merge_config.sh na árvore do kernel para ativar as opções: 

ARCH=ARCH scripts/kconfig/merge_config.sh <...>/device_defconfig <...>/android-base.cfg <...>/android-base-ARCH.cfg <...>/android-recommended.cfg

Isso gera um arquivo .config que pode ser usado para salvar um novo arquivo defconfig ou compilar um novo kernel com recursos do Android ativados.

Outros requisitos de configuração do kernel

Em alguns casos, o mantenedor da plataforma pode escolher entre vários recursos do kernel para satisfazer uma dependência do Android. Essas dependências não podem ser expressas nos arquivos de fragmento de configuração do kernel (descritos acima) porque o formato desses arquivos não oferece suporte a expressões lógicas. No Android 9 e versões mais recentes, o Conjunto de teste de compatibilidade (CTS) e o Conjunto de teste de fornecedor (VTS) verificam se os seguintes requisitos são atendidos:

  • CONFIG_OF=y ou CONFIG_ACPI=y
  • Os kernels 4.4 e 4.9 têm CONFIG_ANDROID_LOW_MEMORY_KILLER=y OU têm CONFIG_MEMCG=y e CONFIG_MEMCG_SWAP=y
  • CONFIG_DEBUG_RODATA=y ou CONFIG_STRICT_KERNEL_RWX=y
  • CONFIG_DEBUG_SET_MODULE_RONX=y ou CONFIG_STRICT_MODULE_RWX=y
  • Apenas para ARM64: CONFIG_ARM64_SW_TTBR0_PAN=y ou CONFIG_ARM64_PAN=y

Além disso, a opção CONFIG_INET_UDP_DIAG precisa ser definida como y para kernels 4.9 no Android 9 e versões mais recentes.

Ativar as opções do modo host USB

Para o áudio no modo host USB, ative as seguintes opções: 

CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=y
# CONFIG_USB_AUDIO is for a peripheral mode (gadget) driver

Para o modo de host USB MIDI, ative a seguinte opção: 

CONFIG_SND_USB_MIDI=y

Seccomp BPF com TSYNC

O Filtro de pacotes do Berkeley (Seccomp BPF) da computação segura é uma tecnologia de segurança do kernel que permite a criação de sandboxes que definem o contexto em que um processo pode fazer chamadas do sistema. O recurso de sincronização de linha de execução (TSYNC) permite o uso do Seccomp BPF em programas multithread. Essa capacidade é limitada a arquiteturas com suporte ao upstream do Seccomp (ARM, ARM64, x86 e x86_64).

Daemon do Android Live-Lock

O Android 10 inclui o daemon do Android Live-Lock (llkd), desenvolvido para detectar e atenuar os deadlocks do kernel. Para saber mais sobre o uso do llkd, consulte Daemon do Android Live-Lock.

vDSO32 no ARM64

O objeto compartilhado dinâmico virtual (vDSO, na sigla em inglês) é uma alternativa às chamadas de sistema que, quando usado e configurado corretamente, pode reduzir os custos de ciclo. O Android 10 adiciona suporte ao vDSO32 em kernels de 64 bits. O Android já oferece suporte ao vDSO64 em kernels de 64 bits e vDSO32 em kernels de 32 bits. O uso do vDSO32 (CONFIG_VDSO_COMPAT) na arquitetura ARM64 proporciona um aumento de 0,4% na duração da bateria e outras melhorias de desempenho.

A comunidade do Linux está trabalhando ativamente para unificar vDSOs entre arquiteturas. É possível configurar o vDSO no kernel do Linux ativando o vDSO32 com CONFIG_COMPAT e CONFIG_CROSS_COMPILE_COMPAT_VDSO com o triplet do compilador arm32. A equipe do kernel do Android fez o backport de versões mais antigas da série de patches do vDSO para dispositivos Pixel. Assim, você pode encontrar exemplos em builds do kernel do Pixel (caminho LINUX_FCC_CROSS_COMPILE_ARM32_PREBUILTS_BIN, referência CROSS_COMPILE_ARM32 e configuração CONFIG_CROSS_COMPILE_ARM32).

Configuração de RAM baixa

Ajustar o kernel e o ActivityManager para reduzir a recuperação direta

A recuperação direta acontece quando um processo ou o kernel tenta alocar uma página de memória (diretamente ou devido a uma falha em uma nova página) e o kernel usa toda a memória livre disponível. Isso exige que o kernel bloqueie a alocação enquanto libera uma página. Isso, por sua vez, geralmente exige que a E/S do disco limpe uma página com suporte a arquivo sujo ou aguarde que lowmemorykiller pare um processo. Isso pode resultar em E/S extra em qualquer linha de execução, incluindo uma linha de execução da interface.

Para evitar a recuperação direta, o kernel tem marcas d'água que acionam kswapd ou a recuperação em segundo plano. Essa é uma linha de execução que tenta liberar páginas para que, na próxima vez que uma linha de execução real for alocada, ela possa ser bem-sucedida rapidamente.

O limite padrão para acionar a recuperação em segundo plano é bastante baixo, cerca de 2 MB em um dispositivo de 2 GB e 636 KB em um dispositivo de 512 MB. O kernel recupera apenas alguns megabytes de memória na recuperação em segundo plano. Isso significa que qualquer processo que aloca rapidamente mais do que alguns megabytes vai atingir rapidamente a recuperação direta.

O suporte a um kernel tunable foi adicionado à ramificação do kernel Android-3.4 como o patch 92189d47f66c67e5fd92eafaa287e153197a454f ("add extra free kbytes tunable"). A seleção seletiva desse patch para o kernel de um dispositivo permite que o ActivityManager diga ao kernel para tentar manter três buffers de memória de 32 bpp em tela cheia livres.

Esses limites podem ser configurados com o framework config.xml.

<!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable
in the kernel (if it exists). A high value increases the amount of memory
that the kernel tries to keep free, reducing allocation time and causing the
lowmemorykiller to kill earlier. A low value allows more memory to be used by
processes but may cause more allocations to block waiting on disk I/O or
lowmemorykiller. Overrides the default value chosen by ActivityManager based
on screen size. 0 prevents keeping any extra memory over what the kernel keeps
by default. -1 keeps the default. -->
<integer name="config_extraFreeKbytesAbsolute">-1</integer>

<!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes
tunable in the kernel (if it exists). 0 uses the default value chosen by
ActivityManager. A positive value increases the amount of memory that the
kernel tries to keep free, reducing allocation time and causing the
lowmemorykiller to kill earlier. A negative value allows more memory to be
used by processes but may cause more allocations to block waiting on disk I/O
or lowmemorykiller. Directly added to the default value chosen by
ActivityManager based on screen size. -->
<integer name="config_extraFreeKbytesAdjust">0</integer>

Ajustar o LowMemoryKiller

O ActivityManager configura os limites do LowMemoryKiller para corresponder à expectativa do conjunto de trabalho de páginas com suporte a arquivos (páginas em cache) necessárias para executar os processos em cada bucket de nível de prioridade. Se um dispositivo tiver requisitos altos para o conjunto de trabalho, por exemplo, se a interface do fornecedor exigir mais memória ou se mais serviços tiverem sido adicionados, os limites poderão ser aumentados.

Os limites podem ser reduzidos se muita memória estiver sendo reservada para páginas com suporte a arquivos. Assim, os processos em segundo plano são encerrados muito antes de ocorrer o thrashing do disco devido ao cache ficar muito pequeno.

<!-- Device configuration setting the minfree tunable in the lowmemorykiller
in the kernel. A high value causes the lowmemorykiller to fire earlier,
keeping more memory in the file cache and preventing I/O thrashing, but
allowing fewer processes to stay in memory. A low value keeps more
processes in memory but may cause thrashing if set too low. Overrides the
default value chosen by ActivityManager based on screen size and total memory
for the largest lowmemorykiller bucket, and scaled proportionally to the
smaller buckets. -1 keeps the default. -->
<integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer>

<!-- Device configuration adjusting the minfree tunable in the
lowmemorykiller in the kernel. A high value causes the lowmemorykiller to
fire earlier, keeping more memory in the file cache and preventing I/O
thrashing, but allowing fewer processes to stay in memory. A low value
keeps more processes in memory but may cause thrashing if set too low. Directly
added to the default value chosen by ActivityManager based on screen
size and total memory for the largest lowmemorykiller bucket, and scaled
proportionally to the smaller buckets. 0 keeps the default. -->
<integer name="config_lowMemoryKillerMinFreeKbytesAdjust">0</integer>