Android suporta páginas de memória de 16 KB: impacto real e o que fazer

Android salta para páginas de memória de 16 KB E essa não é uma mudança pequena para o desenvolvedor. Por trás disso, há um ajuste de baixo nível na forma como o sistema gerencia RAM Isso pode se traduzir em inicializações de aplicativos mais rápidas, menor consumo de energia e dispositivos mais responsivos, especialmente em hardware moderno com mais memória. Se você trabalha com NDKs, mecanismos de jogo ou SDKs que incluem arquivos .so, essa mudança afeta você diretamente.

Nas próximas versões, Cada vez mais dispositivos virão configurados para 16 KB E o Google Play ditará o ritmo com um requisito específico: se o seu aplicativo for destinado ao Android 15 ou superior, ele deve ser compatível. Aqui, você encontrará, sem mais delongas, o que está mudando, por que é importante, quem é afetado, como detectar no seu APK ou AAB, o que atualizar no AGP e no NDK, como testar em emuladores e Pixels, modo de compatibilidade e datas de lançamento importantes.

O que é uma página de memória e por que o Android muda para 16 KB?

Uma página é a unidade com a qual o sistema operacional aloca e gerencia a RAM. O Android historicamente foi otimizado para 4 KB porque era algo comum em kernels e dispositivos. CPUs ARM Eles também suportam 16 KB e, a partir do Android 15, o AOSP permite que o sistema seja configurado para usar páginas de 16 KB no arm64, mantendo a compatibilidade com kernels de 4 KB ou 16 KB a partir do android14-6.1.

A mudança tem uma desvantagem: um pouco mais de memória é usada em média, mas a contabilidade da tabela de páginas é reduzida e a eficiência da memória e de E/S é melhorada. Com mais RAM nos terminais atuais, o equilíbrio é equilibrado. Além disso, o alinhamento ELF de 16 KB no espaço do usuário permite que o mesmo binário seja executado em kernels de 4 KB e 16 KB quando alinhado corretamente.

Benefícios medidos e custos associados

Os testes internos do Google indicam melhorias claras: Lançamentos de aplicativos em média 3,16% mais rápido, com casos chegando a 30% em certos aplicativos. Ao iniciar aplicativos, o consumo de energia é reduzido em cerca de 4,56%.

Impactos em funções do sistema sensíveis ao desempenho também foram observados: A câmera inicia 4,48% mais rápido quando quente e 6,60% mais rápido quando fria, e o tempo de inicialização do sistema melhora em cerca de 8% (cerca de 950 ms). Outras análises publicadas relatam ganhos gerais de 5 a 10%, ao custo de cerca de 9% a mais de RAM.

Quem isso realmente afeta?

Se o seu aplicativo usa código nativo C ou C++ Se você estiver usando o NDK, vinculando-se a bibliotecas .so de terceiros, integrando mecanismos como Unity ou Unreal ou contando com SDKs que incluem arquivos .so, recompile e alinhe para 16 KB. Se suspeitar de uso excessivo, veja como identificar aplicativos que consomem muita memóriaAplicativos escritos exclusivamente em Java ou Kotlin, incluindo suas dependências, agora são suportados, embora seja uma boa ideia testar em menos de 16 KB para evitar surpresas.

Tem em conta que Muitos SDKs modernos já oferecem compilações compatíveis E, de acordo com diversos veículos de comunicação, muitos aplicativos e frameworks populares, como Flutter e React Native, estão se adaptando. Ainda assim, é fundamental verificar cada arquivo .so que você empacota.

Como saber se seu aplicativo usa nativo e é afetado

Primeiro, verifique se o APK ou AAB contém .so. Analisador de APK no Android Studio Facilita: Compilar → Analisar APK, navegue até lib e verifique se há objetos compartilhados em arm64-v8a ou x86_64. Se houver arquivos .so, há nativo. A coluna Alinhamento exibe avisos ao detectar problemas com 16 KB.

Além disso, Lint alerta sobre bibliotecas nativas desalinhadas em 16 KBÉ uma maneira rápida de ver quais dependências ou módulos precisam de atenção antes mesmo de compilar uma versão final.

Verifique o alinhamento e a embalagem do ELF

O ponto-chave é que o Os segmentos LOAD do seu .so estão alinhados a 16 KB e o APK resultante é alinhado em zip para 16 KB quando você não compacta jniLibs.

Roteiro oficial check_elf_alignment.sh no Linux ou macOS – Analisa um APK e marca cada .so como ALINHADO ou NÃO ALINHADO para arm64-v8a e x86_64.
ferramentas de linha de comando: Extraia o APK, localize os arquivos .so em lib e examine os segmentos LOAD com readelf. Procure pelo alinhamento 2**14.
zipalign: Valida se o APK está alinhado em 16 KB quando não está compactando bibliotecas compartilhadas.

# Comprobar segmentos de carga y su alineación
readelf -l ruta/libmilib.so | grep LOAD
# Ejemplo de salida válida (alineación 16 KB)
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
LOAD off 0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14

# Verificar zipalign del APK en 16 KB
zipalign -c -P 16 -v 4 MiApp.apk
# Debe terminar con Verification successful

Se você ver alinhamento 213, 212 ou menos, ou se o zipalign falhar, que a biblioteca ou embalagem não está em conformidade. Recompile, corrija os sinalizadores e verifique novamente antes de publicar.

Atualize sua cadeia de ferramentas: AGP, NDK e sinalizadores necessários

Para dispositivos de 16 KB, há duas frentes obrigatórias: Alinhamento ELF do .so y Alinhamento do APK ZIP quando você distribui jniLibs descompactados.

Plugin Gradle para Android 8.5.1 ou superior

Com bibliotecas descompactadas, dispositivos de 16 KB exigem que o APK seja alinhado em zip para 16 KB. O AGP 8.5.1 ou posterior faz isso por padrão. E é o caminho recomendado. Se você estiver trabalhando com AGP 8.3 a 8.5, há uma armadilha conhecida: o bundletool não compacta por padrão, e você pode ver que tudo parece correto localmente, mas a compilação distribuída pelo Play não é instalada.

Se você ainda não consegue atualizar para 8.5.1, há uma plano B temporário: Empacote bibliotecas compactadas para evitar o requisito de alinhamento zip de 16 KB. No Gradle, você pode forçar o empacotamento legado de jniLibs.

// Groovy
authoring example
android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging true
    }
  }
}

// Kotlin DSL
android {
  packaging {
    jniLibs {
      useLegacyPackaging = true
    }
  }
}

Tenha cuidado com esta abordagem: Ao compactar .so o instalador deve extraí-los e copiá-los, o que aumenta o espaço ocupado e pode aumentar a taxa de falhas na instalação devido à insuficiência de armazenamento. A solução mais viável é atualizar para o AGP 8.5.1 ou superior.

NDK e vinculado a 16 KB

NDK r28 ou posterior: compila por padrão com alinhamento de 16 KB. Esta é a opção ideal.
NDK-r27: Permita 16 KB adicionando os sinalizadores apropriados no ndk-build, CMake ou diretamente no vinculador.
NDK r26 e anteriores: Não recomendado. Pode ser forçado, mas o suporte não é garantido. Na versão R22 e anteriores, common-page-size=16384 pode ser necessário devido a bugs históricos no ld e lld, e devido ao ELF incluir .relro_padding com LLD 18 ou superior.

# Flag estándar de vinculador para máximo tamaño de página
-Wl,-z,max-page-size=16384

Se o seu aplicativo vincula dinamicamente com o antigo libc++_shared.so Se você estiver usando o NDK r26 ou anterior, corre o risco de a instalação falhar em dispositivos de 16 KB. A recomendação é migrar para o NDK r27 ou r28; como alternativa temporária, você pode vincular estaticamente o STL à sua biblioteca, ponderando os prós e contras de manutenção e tamanho.

Corrija suposições de 4 KB em seu código

Mesmo se você alinhar corretamente, poderá haver travamentos ou vazamentos se presumir que PAGE_SIZE é 4096. Evite depender de PAGE_SIZE rigidamente; no NDK r27 e posteriores, abaixo de 16 KB, ele nem é definido para evitar uso indevido.

Obtenha o tamanho real em tempo de execução com getpagesize ou sysconf, e verifique chamadas mmap e APIs que exigem argumentos alinhados à página. Se você solicitar de 1 a 5 KB, o kernel ainda alocará 16 KB para 16 KB; quando possível, combina regiões RW para aproveitar uma única página e reduzir o desperdício.

// Ejemplos en C/C++
long sz = getpagesize();
// o
long sz2 = sysconf(_SC_PAGESIZE);
// Usa sz en lugar de valores fijos al calcular offsets, tamaños y alineaciones

Testando em ambiente de 16 KB

Após a recompilação, é hora de validar completamente. Configurar Android 15 no SDK e cria um AVD baseado em imagem de 16 KB. O Android Studio Jellyfish 2023.3.1 ou superior oferece suporte; para uma melhor experiência, recomenda-se o Ladybug 2024.2.1 ou superior.

No SDK Manager, em Plataformas SDK, mostre detalhes e, em Android VanillaIceCream ou posterior, selecione o Imagens de 16 KB Você precisa de: ARM 64 v8a Google APIs Experimental ou x86_64 Google APIs Experimental, tamanho de página de 16 KB. Se você estiver emulando um Pixel compatível, ARM 64 v8a é suficiente.

Nota sobre emulador e depuração

Entre as versões 35.1.5 e 35.1.20 do emulador e antes da revisão 4 das imagens de 16 KB do Android 15, no x86_64 há uma etapa extra: editar config.ini do AVD e inclua o parâmetro do kernel.

# Edita config.ini del AVD
añade esta línea y guarda
kernel.parameters = androidboot.page_shift=14

# Verifica el entorno de 16 KB
a db shell getconf PAGE_SIZE
16384

Há um problema conhecido com LLDB em imagens de 16 KB, que foi abordado no NDK r27 RC1 e no Android Studio Koala 2024.1.2 Canary 5. Mantenha suas ferramentas atualizadas para uma depuração sem atrito.

Testes em hardware real e opções de desenvolvedor

A partir do Android 15 QPR1, alguns dispositivos incluem uma opção para inicializar em 16 KB. Pixel 8, 8 Pro e 8a com 15 QPR1, e Pixel 9, 9 Pro e 9 Pro XL com QPR2 Beta 15 ou superior, podem ser ativados nas Opções do Desenvolvedor. Certifique-se de aplicar as atualizações do sistema antes de testar.

# Comprueba el tamaño de página del dispositivo
adb shell getconf PAGE_SIZE
# Espera ver 16384

Modo de compatibilidade de 16 KB

Quando o dispositivo executa um kernel de 16 KB, o Gerenciador de Pacotes pode ativar um modo de compatibilidade com versões anteriores Se detectar um arquivo .so com segmentos LOAD de 4 KB ou um APK com um arquivo ELF descompactado alinhado a 4 KB, o aplicativo exibirá um aviso na primeira inicialização, indicando que está sendo executado no modo de compatibilidade.

Este modo permite que alguns aplicativos funcionem, mas não é a opção recomendada. Para confiabilidade e estabilidade, alinhe tudo para 16 KBVocê pode ativar ou desativar a compatibilidade por aplicativo nas informações do aplicativo, em Avançado, em Executar aplicativo no modo de compatibilidade de tamanho de página, visível apenas em dispositivos configurados com 16 KB.

# Control global de compatibilidad en el dispositivo
adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

# Forzar desactivación global
adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

# A nivel de app en el manifest
android:pageSizeCompat

Datas e requisitos do Google Play

Para preparar os novos dispositivos, a partir de 1º de novembro de 2025 Todos os novos aplicativos e atualizações para Android 15 ou superior devem oferecer suporte a páginas de 16 KB no Google Play. Sem esse suporte, a publicação pode ser bloqueada.

Vários desenvolvedores receberam comunicações adicionais no Play Console colocando um marco por volta de 1º de maio de 2026 para reforçar o bloqueio de atualizações não compatíveis. Verifique seu console e as comunicações do Play para confirmar quais prazos se aplicam a você.

Como fazer as malas e despachar antes do embarque

Antes de publicar, certifique-se de que seu APK ou AAB esteja em ordem. Construir, analisar e validar sempre em CI e localmente.

Compile com AGP 8.5.1 ou superior e NDK r28 sempre que possível. Se estiver usando r27, adicione sinalizadores de 16 KB ao vincular.
Faça uma varredura com o APK Analyzer e o Lint para encontrar avisos de alinhamento e .so.
Use readelf para confirmar o alinhamento 2**14 nos segmentos LOAD de todos os arquivos .so.
Valide o zipalign em 16 KB com zipalign -c -P 16 -v 4.
Instale e teste em um emulador ou em um Pixel com 16 KB habilitado. Certifique-se de que PAGE_SIZE = 16384.

Erros comuns e como resolvê-los

A instalação do Play falhou, mas funcionou localmente: Isso geralmente ocorre devido a um zipalign ausente ao gerar a partir de um pacote com AGP 8.3–8.5. Atualize para o AGP 8.5.1 ou use temporariamente jniLibs compactadas e valide novamente.
INSTALL_FAILED_INVALID_APK ou tamanho de página ELF não suportado: : há .so com 4 KB. Corrija o NDK r27 ou r28, adicione -Wl,-z,max-page-size=16384 se aplicável, limpe e recompile.
Funciona no emulador e falha em dispositivos de 16 KB- Suspeite de SDKs de terceiros desatualizados. Identifique o arquivo .so problemático no logcat, atualize a dependência ou solicite uma compilação compatível.
O alerta do Play Console persiste: Existem alguns arquivos .so restantes com 4 KB no seu AAB. Gere .apks com o bundletool, extraia-os e execute o comando readelf em todos os arquivos .so até ter certeza de que todos eles apresentam alinhamento 2**14.

Para dispositivos de plataforma e OEM: kernel e espaço do usuário

No arm64, você pode compilar o kernel em 16 KB com o Kleaf usando a opção apropriada ou habilitando CONFIG_ARM64_16K_PÁGINAS em vez de CONFIG_ARM64_4K_PAGES. No espaço do usuário do Android, estes sinalizadores de produto ajudam a habilitar 16 KB e a garantir o futuro:

PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384

Depois de selecionar o destino com lunch, verifique as variáveis com get_build_var e confirme se elas retornam 16384 e true, respectivamente. Mesmo que a compilação passe, diferenças de tempo de execução de até 16 KB podem persistir, portanto, é aconselhável testar completamente o mmap, os alinhamentos e as suposições em componentes críticos.

Controles adicionais para pré-construções e testes

Para reduzir surpresas com binários externos, você pode habilitar VERIFICAÇÃO_DO_PRODUTO_PRÉ-CONSTRUÍDA_TAMANHO_MÁXIMO_DA_PÁGINA Desde o Android 16, esse recurso é usado para validar pré-compilações em compilações. Ele pode ser ignorado temporariamente com ignore_max_page_size em Android.bp ou LOCAL_IGNORE_MAX_PAGE_SIZE em Android.mk.

PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true
# Ignorar temporalmente en Android.bp
ignore_max_page_size: true
# Ignorar temporalmente en Android.mk
LOCAL_IGNORE_MAX_PAGE_SIZE := true

# Test de alineación en dispositivos lanzados con Android 15+
atest elf_alignment_test

Lista de verificação de conformidade expressa

AGP 8.5.1+ ou jniLibs compactados como uma medida temporária.
NDK r28+ (ou r27 com sinalizadores) e todos .so com alinhamento 2**14.
Sem suposições de 4 KB no código; use getpagesize ou sysconf.
zipalign em 16 KB validado e testado no emulador e no Pixel 16 KB.
Dependências nativas verificado e atualizado para compilações compatíveis.

Qualquer pessoa que desenvolva aplicativos com nativo deve reservar algum tempo para esse ajuste, mas o ganho de desempenho e a garantia de instalação em novos dispositivos valem o esforço. Com ferramentas atualizadas, verificação sistemática de .so, correção de suposições de código e testes em 16 KB, o mesmo binário funcionará tanto em 4 KB quanto em 16 KB.