Resposta rápida
O Google Play exige que apps com alvo Android 15 (nível 35 da API) ou superior suportem páginas de memória de 16 KB em dispositivos de 64 bits, e a partir de 1º de fevereiro de 2027 você não vai conseguir publicar atualizações que não suportem. Um app escrito só em Java ou Kotlin, incluindo todas as bibliotecas e SDKs, já está em conformidade. Um app que empacota bibliotecas nativas .so falha até que cada uma seja recompilada ou substituída, de preferência com Android Gradle Plugin 8.5.1+ e NDK r28+, e até o build passar em duas verificações separadas: cada segmento ELF LOAD alinhado em pelo menos 2**14 e o app bundle reportando PAGE_ALIGNMENT_16K. Atualizar o framework não é prova; o artefato é. Se resolver este aviso travou um teste fechado (closed testing) que já estava rodando, a PrimeTestLab mantém o lado dos testadores de pé enquanto você recompila.
O aviso é curto, no máximo cita um nome de arquivo e chega quando você já dava o build por encerrado. É por isso que os mesmos três desvios se repetem: confiar em um prazo que mudou, atualizar um framework e considerar o trabalho feito, ou conferir um único APK local e nunca olhar o pacote a partir do qual o Google realmente compila. Este artigo está organizado do jeito que o problema de fato se resolve, ou seja, identificar, atribuir, reparar e provar, e tudo aqui está atualizado até 5 de agosto de 2026, verificado no guia de tamanhos de página do Google no mesmo dia em que aquela página foi atualizada pela última vez. Quando a evidência é o issue tracker de um mantenedor e não uma nota de versão oficial, a página diz isso no card em vez de arredondar para fato.
O laboratório de alinhamento
Doze instrumentos feitos para este único erro. Nada aqui exige conta, envio ou requisição de rede: cada ferramenta roda no seu navegador com os valores que você digita.
Sumário
Resolva em três passos
Toda correção de verdade para esse erro são os mesmos três movimentos na mesma ordem: identificar a biblioteca nativa que não está alinhada, atualizar a dependência que a entrega e depois verificar o artefato que você vai enviar. Pular direto para o passo dois é o motivo de tantos desenvolvedores atualizarem um framework, recompilarem e verem o aviso voltar sem nenhuma mudança.
O requisito em si é estreito. O guia de tamanhos de página do Google diz que apps com alvo Android 15 (nível 35 da API) ou superior precisam suportar páginas de memória de 16 KB em dispositivos de 64 bits e que a partir de 1º de fevereiro de 2027 você não vai conseguir publicar atualizações que não suportem. Vale só para código nativo. Se o seu app e cada biblioteca e SDK dentro dele forem Java ou Kotlin puro, o Google afirma que o seu app já suporta dispositivos de 16 KB. O problema é que a maioria de quem vê esse aviso acredita estar nessa categoria e não está.
Identifique o .so que falha
Abra o seu APK de produção no Android Studio por Build > Analyze APK..., expanda lib/arm64-v8a e lib/x86_64 e leia a coluna Alignment. Anote cada nome de arquivo sinalizado. Esses nomes são as únicas chaves de busca confiáveis que você tem.
Atualize o que a entrega
Um binário que você compilou é resolvido pelo seu conjunto de ferramentas: AGP 8.5.1 ou mais recente com NDK r28 ou mais recente. Um binário que chegou dentro de um plugin, SDK, motor ou AAR só pode ser resolvido por quem o compilou, então a ação é atualizar, substituir ou pedir um artefato recompilado a esse pacote.
Ache o caminho mais curto para o seu frameworkVerifique o artefato, não a atualização
Duas verificações independentes precisam passar as duas. Cada segmento ELF LOAD precisa estar alinhado em 2**14 ou mais, e o bundletool precisa reportar PAGE_ALIGNMENT_16K para o pacote de produção. Passar em uma não prova nada sobre a outra.
A decisão inteira em uma tela
Antes de mudar uma única versão de dependência, percorra isto. Leva uns dois minutos e é a diferença entre consertar a coisa certa e atualizar onze pacotes que nunca foram o problema.
O APK de produção contém uma pasta lib com arquivos .so?
Já em conformidade
Nenhum código nativo no APK. O Google afirma que um app só de Java ou Kotlin, incluindo suas bibliotecas e SDKs, já suporta dispositivos de 16 KB. Ainda vale uma rodada de teste, e vale confirmar que você inspecionou o mesmo build que enviou.
O APK Analyzer ou o check_elf_alignment.sh citam alguma biblioteca desalinhada?
Atribuir e então atualizar
Descubra qual framework, plugin, SDK ou motor entrega exatamente esse nome de arquivo e atualize esse pacote. O seu próprio NDK não reescreve o binário pré-compilado de outra pessoa.
O que o bundletool dump config reporta para o pacote de produção?
PAGE_ALIGNMENT_4K
As bibliotecas estão bem, mas o empacotamento não. Vá para o AGP 8.5.1 ou mais recente e recompile, ou aplique a solução de empacotamento legado se não puder atualizar.
PAGE_ALIGNMENT_16K
O empacotamento está correto. Agora teste os APKs gerados pelo Play em um ambiente real de 16 KB e audite todo código em execução que assuma um tamanho de página fixo.
A armadilha em uma linha
Um APK local que passa em todas as verificações de alinhamento não prova que o pacote enviado está correto. O Google avisa especificamente que o Android Gradle Plugin 8.3 até 8.5 pode produzir um pacote cujos APKs compilados pelo Play não fiquem bem alinhados em ZIP, mesmo quando o APK na sua máquina parece perfeito. Essa divergência é, de longe, o motivo mais comum de o aviso sobreviver a uma correção "bem-sucedida".
O que o aviso do Play Console realmente significa
A consequência documentada pelo Google é precisa: a partir de 1º de fevereiro de 2027 você não vai conseguir publicar atualizações com alvo Android 15 (nível 35 da API) ou superior sem suporte a 16 KB. É um bloqueio de publicação sobre atualizações, não uma afirmação de que um app já publicado sai da loja naquele dia. Até lá, a maioria dos desenvolvedores vê um aviso de compatibilidade e não uma recusa dura no envio.
A redação importa, porque a versão em pânico dessa história viaja mais rápido que a versão correta. Leia os textos que o Google realmente mostra e o escopo fica estreito e administrável.
App must support 16 KB memory page sizes
Reconstruído a partir da captura do Play Console publicada pelo Google no guia de tamanhos de página. Os rótulos aparecem em inglês, do jeito que estão nessa captura: o seu Console pode mostrá-los em português, e o layout e os botões disponíveis podem variar por conta.
Duas leituras desse card costumam estar erradas. Primeira: "Action by Feb 1, 2027" não é uma contagem regressiva para exclusão; o próprio texto do Google na mesma página descreve o resultado como a impossibilidade de publicar essas atualizações. Segunda: o texto Extension granted aparece na captura do Google, mas isso não estabelece que exista um fluxo de pedido de prorrogação aberto para você agora. Considere uma prorrogação real só se você vir a opção dentro do seu próprio Play Console.
Qual prazo você leu de verdade?
Três datas circulam e só uma está valendo. Escolha a que você viu e isto resolve o status dela contra a página atual do Google, atualizada pela última vez em 5 de agosto de 2026.
Instrumento 01
Resolvedor de prazos
O Google já mudou esse prazo mais de uma vez. Antes de montar um plano de versão em torno de 1º de fevereiro de 2027, abra você mesmo o guia de tamanhos de página e confira a marca de "Última atualização" no rodapé. Esse único hábito vale mais do que qualquer data impressa em um artigo, incluindo este.
O requisito de 16 KB afeta o meu app?
Quem decide isso não é o seu framework. É o conteúdo do APK que você gera. Se houver arquivos .so dentro de lib, você está no escopo mesmo que nunca tenha aberto um arquivo C++, e se não houver nenhum, a própria orientação do Google diz que você já suporta dispositivos de 16 KB.
Apps de Java ou Kotlin puro
O Google é inequívoco aqui: se o seu app e todas as suas bibliotecas e SDKs usam apenas Java ou Kotlin, o seu app já suporta dispositivos de 16 KB. O Google ainda recomenda testar em um ambiente de 16 KB para pegar regressões inesperadas, o que custa uma rodada de emulador.
A pegadinha está na frase "e todas as suas bibliotecas e SDKs". Uma única dependência de banco de dados, analytics, relatório de falhas, mídia, mapas, aprendizado de máquina ou segurança pode adicionar binários nativos a um projeto cujo código-fonte não tem nada além de Kotlin. "Não escrevi C++" não é evidência. A pasta lib é.
Flutter, React Native, Unity, Kivy e construtores no-code
Essas stacks trazem por design runtimes nativos, binários de motor e bibliotecas de plugins, então quase sempre estão no escopo. O Google cita explicitamente construtores de apps de terceiros que usam bibliotecas nativas como um caminho pelo qual um app pode ser afetado mesmo que o autor nunca tenha escrito C ou C++. O que varia não é se você tem código nativo, mas qual pacote entregou a peça que falha, e por isso atribuir o nome do arquivo vem antes de qualquer atualização.
Como conferir, exatamente
Abra o APK de produção, expanda lib e olhe as pastas de ABI lá dentro, normalmente arm64-v8a e x86_64. Qualquer arquivo de objeto compartilhado presente significa que o seu app usa código nativo. Nenhum arquivo .so e nenhuma pasta lib significa que esse APK não usa código nativo. A coluna Alignment no analisador mostra avisos para os arquivos com problema de alinhamento, e é o caminho mais rápido de "tem alguma coisa errada" até um nome de arquivo.
Instrumento 02
Triagem de impacto
01 Qual é o alvo atual do seu app?
02 Abra o APK de produção no APK Analyzer. Existe uma pasta lib?
03 O que descreve melhor o app?
04 Você rodou bundletool dump config no pacote de produção?
Por que um binário de 4 KB falha em um dispositivo de 16 KB
Uma página de memória é o menor bloco que o kernel mapeia de uma vez. O Android historicamente usou páginas de 4 KB; o Android 15 adicionou suporte a dispositivos configurados com páginas de 16 KB. Uma biblioteca nativa registra o alinhamento com que seus segmentos foram ligados e, se esse valor for menor que o tamanho de página do dispositivo, o carregador não consegue colocar o segmento em um limite de página.
Esse é o mecanismo inteiro, e ele explica o único número que você vai continuar vendo. O alinhamento é expresso como potência de dois: 2**12 são 4096 bytes, 2**14 são 16384 bytes. A regra do Google é que cada segmento LOAD de uma biblioteca nativa esteja alinhado em 2**14 ou mais. Uma biblioteca compilada em 2**14 funciona em dispositivos de 4 KB e de 16 KB, porque 16384 é múltiplo exato de 4096. Uma biblioteca compilada em 2**12 só funciona no tamanho de página menor. É essa assimetria que faz a correção ser sempre "aumentar o alinhamento" e nunca "detectar o dispositivo".
Instrumento 03
Visualizador de páginas
Escolha o alinhamento que a sua biblioteca reporta e veja onde os segmentos dela podem começar em um dispositivo que usa páginas de 16 KB.
Passa
Existe uma segunda restrição, completamente separada, que vive fora da biblioteca. Bibliotecas nativas guardadas sem compressão dentro de um APK também precisam ficar em um limite de 16 KB dentro do próprio arquivo ZIP. Isso é uma propriedade do empacotamento, verificada com zipalign e configurada pelo seu plugin de build, e pode estar errada enquanto cada biblioteca lá dentro está perfeitamente alinhada. Manter essas duas ideias separadas é a coisa mais útil que dá para levar desta seção.
Lendo os números
Quando você vir 2**14 na saída do llvm-objdump, isso passa. 2**13 ou 2**12 falha. Não existe nota parcial nem "quase lá": um único segmento LOAD desalinhado, em uma única biblioteca, em uma única ABI, já basta para o aviso continuar na sua conta.
A correção mais curta para cada framework
A prontidão de um framework e a conformidade de um app são coisas diferentes. React Native 0.77 e as versões suportadas da Unity são bases reais e documentadas. O Flutter não tem um mínimo universal verificável. Em todos os casos a atualização conserta os binários do próprio framework e deixa cada plugin de terceiros exatamente tão fora de conformidade quanto antes.
Instrumento 04
Localizador de framework
O que ainda pode falhar depois disso
Todas as bases em uma tabela
| Framework | Base documentada | Ação mais curta | Confiança |
|---|---|---|---|
| Flutter | Sem mínimo universal verificado; 3.38 é o marco de preparação documentado (NDK r28 padrão) | Flutter estável atual, atualizar plugins nativos, limpar, recompilar, inspecionar cada biblioteca | PARCIAL |
| React Native | 0.77 | Caminho de atualização suportado, depois atualizar módulos nativos e SDKs de fornecedores | VERIFICADO |
| Linha Unity 6.1 | 6000.1 ou mais recente | Subir o editor, atualizar pacotes e plugins, recompilar | VERIFICADO |
| Unity 6 LTS | 6000.0.38f1 ou mais recente | Igual ao anterior | VERIFICADO |
| Unity 2022 LTS | 2022.3.56f1 ou mais recente | Igual ao anterior | VERIFICADO |
| Unity 2021 | 2021.3.48f1 ou mais recente, exige elegibilidade de LTS estendido | Subir se tiver direito, senão migrar para um editor suportado | VERIFICADO |
| Unity Burst | 1.8.21 ou mais recente | Subir o Burst quando lib_burst_generated.so for citado |
VERIFICADO |
| Android nativo | NDK r28+ com AGP 8.5.1+ | Recompilar o código próprio, atualizar cada dependência pré-compilada | VERIFICADO |
| Preso a um NDK antigo | r27 ou anterior com as duas opções de link | Adicionar max-page-size e common-page-size, recompilar todas as bibliotecas |
FUNCIONA, NÃO PREFERIDO |
| Kivy ou construtor Python | Nenhuma versão universal verificada | Atualizar o construtor e as receitas, escalar o nome exato para cima | DEPENDE DO FORNECEDOR |
| Construtor no-code | Nenhuma versão universal verificada | Gerar de novo na stack de build em conformidade do fornecedor e mandar o nome do arquivo | DEPENDE DO FORNECEDOR |
Os rótulos de confiança significam a mesma coisa em toda esta página. VERIFICADO quer dizer que uma fonte primária atual afirma isso diretamente. PARCIAL quer dizer que uma fonte confiável sustenta a afirmação central mas não todo detalhe de implementação. RELATADO quer dizer que a evidência é o issue tracker de um mantenedor ou relatos de desenvolvedores e não uma nota de versão oficial.
Encontre a biblioteca exata que causa o erro
O nome do arquivo é a investigação inteira. Assim que você sabe que libfoo.so é o binário que falha, a pergunta deixa de ser "como conserto o suporte a 16 KB" e passa a ser "qual pacote entrega libfoo.so e existe uma versão mais nova". Essa segunda pergunta tem resposta; a primeira não.
Comece pelo APK Analyzer
Abra Build > Analyze APK..., carregue o APK de produção e expanda lib. Lá dentro você vai ver uma pasta por ABI, normalmente arm64-v8a e x86_64. A coluna Alignment mostra mensagens de aviso nos arquivos com problema de alinhamento. Os avisos do próprio Android Studio e o Lint também destacam bibliotecas nativas fora de conformidade, então você pode ver o mesmo achado em mais de um lugar.
Anote cada nome de arquivo sinalizado antes de mexer em um único número de versão. Confira as duas pastas de ABI separadamente: é totalmente normal arm64-v8a passar enquanto x86_64 falha, ou o contrário, porque são binários diferentes compilados por pipelines potencialmente diferentes.
Decodifique a saída da linha de comando
Se você prefere trabalhar no terminal, o Google fornece o check_elf_alignment.sh, que reporta ALIGNED ou UNALIGNED para um APK, e você pode inspecionar uma única biblioteca direto com o llvm-objdump. Os dois precisam do Android SDK Build-Tools 35.0.0 ou mais recente. Cole abaixo o que eles imprimirem e isto vai ler de volta para você.
Instrumento 05
Decodificador ELF
Cole a saída de llvm-objdump -p file.so | grep LOAD, check_elf_alignment.sh ou zipalign -c -P 16. Tudo é analisado no seu navegador; nada é enviado para lugar nenhum.
Descubra qual dependência a entrega
O Play Console e o APK Analyzer te dão os dois um nome de arquivo e nenhum dono. Digite abaixo e isto vai dizer o que se sabe sobre aquele binário, com a qualidade da evidência junto, e te dar os comandos de busca já com o seu nome de arquivo no lugar.
Instrumento 06
Busca de dono da biblioteca
./gradlew app:dependencies mostra o grafo de dependências resolvido, e é assim que você acha o pacote transitivo que puxou uma biblioteca que você nunca adicionou. Ele não diz diretamente qual artefato contém um .so específico, então combine com descompactar o AAR suspeito. São técnicas práticas de diagnóstico e não passos obrigatórios do Google.
Verifique o app bundle, não só o APK local
O seu APK local e os APKs que o Google Play gera a partir do seu pacote são artefatos diferentes. O alinhamento ELF vive dentro de cada biblioteca; o alinhamento ZIP é uma propriedade de como o arquivo foi empacotado; e o pacote carrega uma configuração que diz ao Play qual usar. Os três podem divergir, e só o último decide o que os usuários instalam.
Esse é o mecanismo por trás da versão mais frustrante do problema: o desenvolvedor atualiza tudo, inspeciona o APK local, vê saída limpa, envia, e o aviso continua ali. Nada do que ele conferiu estava errado. Ele só nunca conferiu o que o Play avalia.
O que você inspecionou
app-release.apk na sua máquinaCompilado direto pelo Gradle no seu hardware, com o seu comportamento de empacotamento. Passar no zipalign aqui prova que esse arquivo está empacotado corretamente.
O que o Play avalia
Os APKs gerados a partir de app-release.aabCompilados pelo Google a partir do seu pacote, com o alinhamento que o pacote pede. Se o pacote disser 4 KB, eles estão errados por mais limpo que o seu APK local estivesse.
Então rode isto contra o pacote que você está prestes a enviar, sempre:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K é o resultado que você quer. PAGE_ALIGNMENT_4K significa que o pacote está mandando o bundletool empacotar bibliotecas nativas em limites de 4 KB, então todo APK que o Play compilar a partir dele vai estar errado. O Google avisa especificamente que o Android Gradle Plugin 8.3 até 8.5 pode produzir exatamente essa divergência: o build local parece alinhado e o app que o Play compila a partir do pacote não instala corretamente em um dispositivo de 16 KB. A correção preferida é migrar para o Android Gradle Plugin 8.5.1 ou mais recente.
Todos os comandos, com os seus nomes de arquivo
Digite os seus nomes de arquivo uma vez. Cada comando abaixo se reescreve, e cada aba mostra a saída exata que conta como aprovação, então você nunca fica adivinhando se um resultado foi bom.
Instrumento 07
Laboratório de comandos
Não pare em "o APK Analyzer diz alinhado"
Uma inspeção de APK aprovada é uma de quatro verificações, não a linha de chegada. Confirme o alinhamento ELF dos segmentos LOAD, o alinhamento ZIP do APK, a configuração do pacote e o comportamento em execução do artefato que o Play realmente gera. Qualquer uma delas falhando já basta para o aviso continuar na sua conta depois de um build que você achava resolvido.
AGP, NDK e a armadilha do empacotamento
Duas versões carregam quase todo o peso. O NDK r28 ou superior compila código nativo alinhado em 16 KB por padrão, e o Android Gradle Plugin 8.5.1 ou superior empacota corretamente bibliotecas nativas sem compressão em limites ZIP de 16 KB. Nenhum dos dois conserta um binário pré-compilado que chegou dentro de uma dependência.
O terreno perigoso é o Android Gradle Plugin 8.3 até 8.5. Nessa faixa um build local pode parecer completamente correto enquanto o bundletool não alinha em ZIP os APKs que produz do seu pacote para o Play, e a redação do Google é direta sobre o resultado: o app compilado a partir desse pacote não vai instalar direito. Se você está em 8.5.0 e o seu APK local passa em todas as verificações que você imagina, essa é a primeira coisa a descartar.
Instrumento 08
Verificador de ferramentas
Referência de configurações de build
| Situação | Configuração | Observações |
|---|---|---|
| NDK preferido | r28 ou superior |
Produz saída nativa alinhada em 16 KB por padrão |
| AGP preferido | 8.5.1 ou superior |
Trata bibliotecas nativas sem compressão em limites ZIP de 16 KB |
| NDK r27 ou anterior | -Wl,-z,max-page-size=16384 |
Opção de link obrigatória em cada alvo nativo |
| NDK r27 ou anterior | -Wl,-z,common-page-size=16384 |
Use junto com a opção de tamanho máximo de página |
ndk-build |
LOCAL_LDFLAGS += ... |
Aplique as duas opções em cada alvo nativo |
| CMake | target_link_options(...) |
Aplique as duas opções em cada alvo relevante |
| Não dá para atualizar o AGP | jniLibs.useLegacyPackaging = true |
Comprime bibliotecas nativas; aumenta o espaço em disco instalado |
| AGP 8.0 ou anterior | android.bundle.enableUncompressedNativeLibs=false |
Propriedade legada adicional, junto com a opção acima |
| Código em execução | getpagesize() ou sysconf(_SC_PAGESIZE) |
Substitua os 4096 fixos e as suposições de PAGE_SIZE constante |
A parte que o empacotamento não conserta
Se o seu próprio C ou C++ assume um tamanho de página, nenhuma opção de build te salva. Tire os valores 4096 fixos e qualquer dependência de uma constante PAGE_SIZE fixa, consulte o valor real em execução com getpagesize() ou sysconf(_SC_PAGESIZE) e revise cada chamada de mmap() junto com qualquer argumento que você esteja alinhando na mão. Essa é a classe de falha em que um app instala limpo em um dispositivo de 16 KB, passa nas verificações do pacote e depois quebra na primeira vez que toca mapeamento de memória.
Ordem das operações
Conserte o lado do compilador antes do lado do empacotamento. Se você aplicar primeiro a solução de empacotamento legado, o seu APK vai começar a passar no zipalign enquanto as bibliotecas dentro dele continuam compiladas para páginas de 4 KB, e você terá escondido o problema real atrás de um resultado verde.
Teste em um ambiente real de 16 KB
Um único comando decide se o seu teste significa alguma coisa: adb shell getconf PAGE_SIZE precisa retornar 16384. Rode antes de cada sessão. Um emulador que subiu silenciosamente em modo 4 KB deixa um build quebrado passar em tudo que você jogar nele.
Você tem três caminhos práticos e dois especializados. Pegue o que você realmente consegue hoje; para caçar falhas de tamanho de página não existe diferença de qualidade entre eles.
Instrumento 09
Seletor de ambiente de teste
Limitação
Depois, toda vez e sem exceção, antes de qualquer teste
adb shell getconf PAGE_SIZE
Não continue enquanto a saída não for 16384.
O que exercitar de verdade
Com o ambiente confirmado, a passada de teste útil não é "abre?". Falhas nativas se concentram nas funcionalidades que tocam código nativo, então acione essas de propósito: início a frio, navegação pelo app, câmera, leituras e escritas de banco de dados, reprodução e gravação de mídia, autenticação, trabalho em segundo plano, qualquer recurso de aprendizado de máquina ou realidade aumentada, cada superfície de plugin nativo e tudo no seu próprio código que use mapeamento de memória. Se uma funcionalidade é movida por uma das bibliotecas que você acabou de atualizar, essa funcionalidade é o teste.
Modo de compatibilidade não é aprovação
O Android consegue rodar alguns apps alinhados em 4 KB em um dispositivo de 16 KB por um caminho de compatibilidade, e você pode ver um aviso na primeira abertura quando isso acontece. O Google continua recomendando alinhamento correto de 16 KB para a melhor confiabilidade e estabilidade. Um app que só funciona porque o modo de compatibilidade entrou em ação não é um app resolvido, e publicar nessa base significa que a falha real continua na sua frente.
Por que o aviso sobrevive a uma atualização
Quase todo caso de "mas eu já consertei isso" é uma de treze situações específicas, e onze delas dá para provar a partir do artefato que está na sua frente. Escolha o sintoma que combina e você normalmente vai saber a causa antes de terminar de ler.
Instrumento 10
Triagem de aviso persistente
Dois desses casos merecem uma ressalva em vez de uma resposta confiante. Nenhuma fonte primária estabelece quanto tempo o Google Play leva para reavaliar um pacote enviado, então se o seu aviso persiste logo depois de um envio, o movimento honesto é confirmar que o novo código de versão aparece nas suas versões e app bundles mais recentes e conferir de novo mais tarde, em vez de confiar em algum número específico que você leu sobre tempos de processamento. E um app que só funciona porque o modo de compatibilidade entrou em ação não foi consertado, foi acomodado.
Bibliotecas de terceiros que aparecem sempre
São exemplos relatados, não um ranking de quão comuns eles são, e não uma promessa de que uma versão específica vai consertar o seu build. Um pacote pode adicionar, remover ou substituir artefatos nativos em qualquer versão. A autoridade final é sempre o binário que está dentro do seu próprio pacote de produção.
Use isto como ponto de partida quando um nome de arquivo parecer familiar e depois confirme nas versões atuais e nos issues abertos daquele projeto. Quando a evidência é o issue tracker de um mantenedor e não uma nota de versão, o card diz isso.
Instrumento 11
Índice de bibliotecas relatadas
libobjectbox-jni.so
Bibliotecas nativas Android mais antigas falhavam em um ambiente de 16 KB. Não foi possível confirmar aqui, com solidez suficiente para publicar, uma versão corrigida específica. Confira as notas de versão atuais do ObjectBox para achar a versão que adicionou o suporte a 16 KB e depois confirme o binário dentro do seu APK compilado, em vez de confiar só no número da versão.
biblioteca Android embutida
O SDK Dart do ObjectBox traz a própria biblioteca Android. Não foi possível confirmar aqui, com solidez suficiente para publicar, uma versão corrigida específica. Confira as notas de versão atuais do ObjectBox e depois verifique o artefato que o seu build realmente resolve.
libsqlite3.so
Uma dependência antiga 3.43.0 apareceu em empacotamentos afetados de Flutter e AWS Amplify. A evidência dos issues identifica 3.46.1+1 como a versão que adicionou o suporte a 16 KiB. Confira a versão de dependência resolvida, não só a que você declarou, porque um pacote de framework pode fixar uma mais antiga.
sqlcipher-android
O pacote antigo android-database-sqlcipher está descontinuado na origem em favor do pacote mantido sqlcipher-android. Não foi possível confirmar aqui, com solidez suficiente para publicar, uma versão específica como mínimo corrigido, então migre para o pacote mantido atual e valide cada ABI no app compilado em vez de confiar em um número de versão.
binários de processamento de mídia
O repositório original do FFmpegKit foi encerrado e nenhuma versão em conformidade universalmente segura foi estabelecida. A qualidade dos forks varia. Identifique exatamente qual fork o seu build resolve, inspecione os artefatos por ABI diretamente e pese manutenção e procedência antes de adotar um como correção.
binários Realm e JNI
Os relatos se contradizem. A versão 20.1.0 foi apontada, e um relato posterior disse que a 20.2.0 reparou um binário do Realm enquanto outro binário JNI continuava problemático. Não dá para nomear uma única versão segura de forma responsável, então atualize e depois cheque individualmente cada biblioteca que o Realm contribui.
libmediapipe_tasks_vision_jni.so
Relatado com alinhamento 2**12. Nenhuma versão corrigida foi estabelecida no issue consultado, então trate a compatibilidade como dependente da versão: confira as notas de versão atuais, atualize e verifique o binário no seu próprio build.
artefato OpenCV Android
Problemas de alinhamento foram relatados em um artefato Android do OpenCV 5.0.0. O issue do repositório cita uma correção de CI, mas nenhum artefato publicado específico pôde ser estabelecido com segurança. Baixe o AAR exato do qual você depende, descompacte e inspecione as bibliotecas você mesmo.
lib_burst_generated.so
A orientação da própria Unity é atualizar o pacote Burst para 1.8.21 ou mais recente quando esse arquivo é sinalizado. É a única entrada do índice apoiada em documentação oficial do fornecedor e não em relatos de issues.
libUnityARCore.so, libquack.so e outros
Relatos da comunidade citam esses entre os binários que sobrevivem a uma atualização do editor. Não existe versão universal para citar, porque cada um pertence a um pacote diferente. Use o nome exato do arquivo para decidir atrás de qual pacote correr.
Nenhuma entrada corresponde a esse filtro. É normal: este índice cobre exemplos relatados e não todas as bibliotecas do ecossistema. Use a busca de dono da biblioteca e rastreie o arquivo dentro do seu próprio projeto.
Por que este índice é curto: contagem de issues mostra quais projetos têm usuários barulhentos, não quais bibliotecas são mais instaladas. Publicar uma lista ordenada dos "vilões mais comuns" seria inventar uma estatística. O que generaliza é o método: pegar o nome do arquivo, achar o pacote, conferir as versões atuais desse pacote, verificar o binário no seu build.
Como isso se relaciona com o prazo da API 36 de 31 de agosto de 2026
São dois requisitos independentes do Google Play que se encontram em um único ponto. Aumentar o nível de API desejado pode expor o aviso de 16 KB, porque o requisito vale para apps que têm como alvo o Android 15 (nível 35 da API) ou superior. Ele não cria o desalinhamento e também não consegue repará-lo.
O Google Play exige que apps novos e atualizações tenham como alvo o Android 16 (nível 36 da API) a partir de 31 de agosto de 2026, com prorrogação disponível até 1º de novembro de 2026. Isso é uma mudança de manifesto e de comportamento. A regra dos 16 KB, por outro lado, é uma mudança de compatibilidade binária. Quem aumenta o targetSdk na segunda e vê um aviso de 16 KB na terça não quebrou nada: as bibliotecas nativas já estavam compiladas para páginas de 4 KB, e o nível desejado mais alto apenas colocou o app dentro do escopo de uma verificação que ia valer de qualquer jeito.
Requisito A
Ter a API 36 como alvo- Data 31 de agosto de 2026, prorrogação até 1º de novembro de 2026
- Escopo Apps novos e atualizações
- Fica em Seu manifesto e sua configuração de build
- Resolve com Aumentar o nível desejado e tratar as mudanças de comportamento do Android 16
Requisito B
Suporte a páginas de 16 KB- Data 1º de fevereiro de 2027
- Escopo Apps com alvo API 35+ em dispositivos de 64 bits
- Fica em Os binários nativos dentro do seu pacote
- Resolve com Recompilar ou substituir cada biblioteca desalinhada
Na prática, trate os dois como uma única migração com duas provas. Você vai aumentar o nível desejado de qualquer forma: programe a auditoria das bibliotecas nativas na mesma versão em vez de descobri-la no meio da correria da API 36. Para o conjunto completo de níveis por formato de dispositivo, as exceções e a mecânica da prorrogação, veja nosso artigo sobre o prazo da API 36 do Google Play, e para toda a sequência da conta até a produção, nosso artigo de requisitos de publicação 2026.
A checagem antes do envio
Onze verificações, cada uma com uma prova específica de aprovação. Passe por elas antes de enviar em vez de depois de o Play te avisar que tem algo errado, e você transforma uma sessão de depuração sem limite em uma lista finita.
Instrumento 12
Checagem antes do envio
0 de 11 concluídos
Nada provado ainda. Comece pelo build que você realmente pretende enviar, não pelo último que estava aberto.
O seu progresso fica guardado só neste navegador. Nada é enviado para lugar nenhum, e limpar os dados do navegador apaga isso.
Concluir os onze itens prova alinhamento técnico diante das verificações citadas nesta página. Não é uma promessa de aprovação. O Google Play ainda pode levantar, no mesmo envio, problemas de política, conteúdo ou qualidade sem relação com isso, e nenhuma lista de checagem consegue falar por eles.
Onde isso colide com o seu teste fechado
Nada nesta página muda o seu requisito de testadores, e nada nos seus testadores muda o seu build. Os dois problemas colidem em um único eixo: o tempo. Um teste fechado de 14 dias corre em um relógio que você não consegue pausar, e uma investigação de biblioteca nativa corre em um relógio que ninguém consegue prever.
A sequência que dói é esta. Uma conta pessoal de desenvolvedor começa um teste fechado, a janela de 14 dias de participação contínua se inicia, e em algum ponto do meio um aumento do nível desejado expõe um aviso de 16 KB. Agora o desenvolvedor recompila dependências nativas enquanto um grupo de testadores precisa continuar intacto em volta. Enviar uma versão nova para a faixa de teste é perfeitamente normal, e o Google incentiva os desenvolvedores a continuar atualizando durante um teste. O que quebra a sequência é o lado dos testadores ficar em silêncio.
É exatamente essa parte que a PrimeTestLab mantém firme. Fornecemos 12 testadores reais em dispositivos reais cobrindo do Android 7 ao 17, participando e mantidos pelos 14 dias completos, para que a sua recompilação aconteça diante de um teste estável e não de um teste que está desmoronando. O teste começa em 4-6 horas, e já fizemos isso em 7.400+ apps em 120+ países com 99,9% de taxa de sucesso.
Recrutar testadores sozinho x teste gerenciado
| O requisito do Google | Recrutar sozinho | Teste gerenciado |
|---|---|---|
| No mínimo 12 testadores participando | Achar, orientar e cobrar pessoas reais e depois torcer para nenhuma sair | 12 fornecidos e mantidos pela janela inteira |
| 14 dias consecutivos | Um único testador que sai no meio quebra a continuidade | O grupo é monitorado para a janela continuar intacta |
| Dispositivos reais, pessoas reais | Emuladores e contas inativas são o atalho de sempre e o motivo de sempre para um teste falhar | Dispositivos reais do Android 7 ao 17 |
| Tempo até a primeira participação | Dias, dependendo de quem responder | O teste começa em 4-6 horas |
| Custo | Seu tempo, justo na semana em que você já está recompilando bibliotecas | A partir de $19.99 mais 5% de taxa de serviço |
| Recompilar no meio do teste | Cada envio novo é mais uma rodada de pedir para as pessoas atualizarem | Publique versões novas à vontade; o grupo continua participando |
Sendo direto sobre o limite: não recompilamos as suas bibliotecas nativas e este artigo não é um argumento de venda para isso. O trabalho de 16 KB é seu, e tudo antes desta seção foi escrito para deixá-lo o mais curto possível. O que tiramos das suas costas é o requisito de testadores que corre em paralelo, para os dois problemas pararem de disputar a mesma quinzena.
Dica de sequência
Se você ainda não começou o teste fechado e já sabe que carrega bibliotecas nativas, coloque primeiro a janela de testadores para rodar e faça o trabalho de alinhamento dentro dela. O período que qualifica, segundo o Google, é medido pela continuidade da participação dos testadores e não por um build congelado, e o Google incentiva continuar atualizando durante um teste: os dois cronogramas podem se sobrepor em vez de se empilhar. Mantenha a mesma faixa de teste e o mesmo grupo de testadores enquanto faz isso. Costuma ser uma semana inteira economizada.
Perguntas frequentes
O Google Play já está recusando apps incompatíveis com 16 KB?
A documentação atual do Google diz que a partir de 1º de fevereiro de 2027 você não vai conseguir publicar atualizações com alvo Android 15 (nível 35 da API) ou superior sem suporte a 16 KB em dispositivos de 64 bits. Antes dessa data, a maioria dos desenvolvedores vê um aviso de compatibilidade no Play Console e não um bloqueio duro. A consequência documentada na página do Google citada é a impossibilidade de publicar atualizações fora de conformidade, não a remoção automática de um app já publicado.
Por que o Google diz 1º de fevereiro de 2027 e outros artigos dizem 1º de novembro de 2025?
1º de novembro de 2025 foi o prazo anunciado originalmente pelo Google e 31 de maio de 2026 foi uma data de prorrogação histórica posterior. Em 5 de agosto de 2026, tanto a página atual do Android Developers quanto a captura atual do aviso no Play Console mostram 1º de fevereiro de 2027, então vale a fonte primária mais recente. Muitos artigos de blog e respostas de IA continuam citando as datas antigas porque foram escritos antes da mudança.
Nunca escrevi C++. Por que meu app é afetado?
Um framework, SDK, plugin, motor de jogo, banco de dados, componente de mídia ou construtor de apps pode adicionar arquivos nativos .so mesmo quando o seu código-fonte é Dart, JavaScript, Python, Java ou Kotlin. As orientações do Google incluem explicitamente apps que usam bibliotecas do NDK de forma indireta, através de uma dependência. Abra o APK no Android Studio com Build e depois Analyze APK: qualquer arquivo .so dentro de lib significa que o app empacotado usa código nativo.
Um app de Kotlin puro precisa de alguma mudança?
Segundo o Google, um app que usa apenas Java ou Kotlin, incluindo todas as suas bibliotecas e SDKs, já suporta dispositivos de 16 KB. O Google ainda recomenda testar em um ambiente de 16 KB para pegar regressões inesperadas. Verifique se o APK de produção real não tem um diretório lib antes de chamar o seu app de Kotlin puro, porque uma única dependência de analytics ou de banco de dados pode adicionar um.
Qual versão do Flutter resolve o aviso de tamanho de página de 16 KB?
Nenhuma fonte oficial estabelece uma versão do Flutter que garanta que todos os apps e plugins Flutter estejam em conformidade. As notas da versão Flutter 3.27 são mais estreitas do que parecem: cobrem o suporte a 16 KB especificamente para os modelos plugin_ffi e não o motor inteiro. O Flutter 3.38 é o marco mais bem documentado: o Flutter posicionou explicitamente essa atualização como preparação para o requisito de 16 KB do Play e mudou o NDK padrão para r28. A ação mais segura é ir para a versão estável atual do Flutter, atualizar cada plugin nativo, recompilar o pacote de produção e inspecionar cada arquivo .so que sair dele.
Qual versão do React Native suporta páginas de 16 KB?
React Native 0.77 é a versão base oficial e sem ambiguidade. O anúncio da versão afirma que o React Native está pronto para suportar totalmente tamanhos de página de 16 KB. Módulos nativos da comunidade, código C++ local e SDKs de terceiros ainda podem trazer binários incompatíveis, então atualize pelo caminho de migração suportado do React Native ou do Expo e depois inspecione o APK gerado.
De qual versão da Unity eu preciso para suportar páginas de 16 KB?
A Unity lista 6000.1 ou mais recente, 6000.0.38f1 ou mais recente, 2022.3.56f1 ou mais recente e 2021.3.48f1 ou mais recente no LTS estendido para clientes Enterprise ou Industry elegíveis. Atualize também os seus plugins nativos e leve o Burst para 1.8.21 ou mais recente se o Play Console citar lib_burst_generated.so. Uma versão de editor suportada é necessária mas não suficiente, porque plugins de terceiros trazem os próprios binários.
Como encontro o arquivo .so exato que está falhando?
Abra o APK com Build e depois Analyze APK no Android Studio, expanda lib/arm64-v8a e lib/x86_64 e leia a coluna Alignment, que mostra avisos para arquivos com problemas de alinhamento. Para confirmar na linha de comando, rode o script check_elf_alignment.sh do Google contra o APK ou inspecione uma biblioteca com llvm-objdump -p file.so redirecionado para grep LOAD. Qualquer alinhamento LOAD abaixo de 2**14 exige atenção.
Por que meu APK passa mas meu app bundle continua falhando?
O alinhamento ELF dentro de uma biblioteca e o alinhamento ZIP dentro do artefato empacotado são duas verificações separadas. Rode bundletool dump config --bundle=app.aab e procure por alignment: PAGE_ALIGNMENT_16K passa, enquanto PAGE_ALIGNMENT_4K significa que os APKs gerados continuam sendo pedidos em 4 KB. O Google avisa especificamente que o Android Gradle Plugin 8.3 até 8.5 pode parecer correto localmente enquanto os APKs que o Play compila a partir do seu pacote não ficam bem alinhados em ZIP, então vá para 8.5.1 ou mais recente.
Atualizar para o NDK r28 é suficiente para resolver?
Não. O NDK r28 e superiores compilam alinhado em 16 KB por padrão, mas isso só afeta o código nativo compilado durante o seu build. Não dá para reescrever um arquivo .so pré-compilado que chega dentro de um AAR, plugin ou pacote de motor de jogo de terceiros. Cada dependência nativa pré-compilada precisa ser atualizada, substituída ou recompilada e reimportada por conta própria.
Como testo o suporte a 16 KB sem ter um celular compatível?
Instale uma das imagens de sistema de 16 KB do Emulador do Android pelo SDK Manager ou reserve um dispositivo compatível no Samsung Remote Test Lab. Use o que usar, confirme o ambiente antes com adb shell getconf PAGE_SIZE; a saída precisa ser 16384 para o teste significar alguma coisa. Sucesso no emulador prova o comportamento em execução, não o empacotamento, então continue inspecionando também o pacote de produção.
Corrigir o suporte a 16 KB reinicia ou afeta o meu teste fechado?
O Google mede o período que qualifica em torno de pelo menos 12 testadores participando continuamente por 14 dias, e não em torno de um build congelado, e incentiva os desenvolvedores a continuar atualizando o build durante um teste. O Google não publica uma garantia explícita cobrindo todo cenário de troca de build, então a abordagem mais segura é manter o seu grupo de testadores estável enquanto você publica um pacote recompilado e em conformidade com 16 KB no meio do teste. A PrimeTestLab fornece 12 testadores reais em dispositivos reais a partir de $19.99 mais 5% de taxa de serviço e segura o grupo pelos 14 dias completos.
Resumo
Em resumo
O Google Play exige que apps com alvo Android 15 (nível 35 da API) ou superior suportem páginas de memória de 16 KB em dispositivos de 64 bits, e a partir de 1º de fevereiro de 2027 atualizações fora de conformidade não poderão ser publicadas. 1º de novembro de 2025 e 31 de maio de 2026 são datas mortas que ainda ranqueiam. Apps de Java ou Kotlin puro já estão em conformidade. Todo o resto segue os mesmos três passos: nomear o .so que falha, atualizar o pacote que o entrega e provar o artefato com duas verificações independentes, cada segmento ELF LOAD alinhado em 2**14 ou mais e o pacote reportando PAGE_ALIGNMENT_16K. AGP 8.5.1+ com NDK r28+ é o conjunto de ferramentas padrão mais seguro, e nenhum dos dois conserta um binário compilado por outra pessoa. Se isso cair no meio de um teste fechado, o lado dos testadores é a parte que dá para delegar. Ver planos e preços →
Fontes primárias
O que vai vencer primeiro nesta página
- A data de 1º de fevereiro de 2027. O Google já mudou esse cronograma mais de uma vez. Confira a marca de "Última atualização" no rodapé do guia de tamanhos de página antes de planejar uma versão em torno dela.
- Os textos do Play Console. Textos e navegação do Console mudam independentemente das páginas de políticas, então os títulos exatos que você vê podem ser diferentes dos reproduzidos aqui.
- As versões base dos frameworks. O Flutter lança versões estáveis com frequência, a política de suporte do React Native evolui e a elegibilidade do LTS da Unity muda. Confirme nas notas de versão atuais e não em um número impresso em um artigo.
- O índice de bibliotecas relatadas. Qualquer pacote pode adicionar, substituir ou regredir um binário nativo em qualquer versão. Sempre verifique o artefato do seu próprio pacote.
- Os nomes das imagens de emulador. Imagens marcadas como experimentais podem ser renomeadas ou promovidas, então o texto exato no SDK Manager pode não bater.
Verificado na documentação do Google em 9 de agosto de 2026. Revisão mensal até pelo menos um mês após a entrada em vigor.