Carregando…
Ação necessária até 1º de fevereiro de 2027O Google bloqueia novos releases no Play Store para apps que não suportam tamanhos de página de memória de 16 KB.
Corrigir meu appA partir de 1º de fevereiro de 2027, o Google Play bloqueia novos releases de apps com alvo Android 15+ que não suportam tamanhos de página de memória de 16 KB. A AllsWeb atualiza sua build chain, reconstrói o AAB contra a ABI de 16 KB, reassina com seu keystore existente e envia o release para o Play Console — para o aviso de política ser removido e você poder lançar atualizações novamente.
Melhor preço quando você compartilha o código-fonte da instalação mais recente. Sem código? Ainda conseguimos reconstruir a partir do AAB publicado — orçado por caso para sem surpresas.
Play Console · Status de política
Problema: O app deve suportar tamanhos de página de memória de 16 KB
O que o Google diz: “Para garantir que seu app funcione corretamente nas versões mais recentes do Android, o Google Play exige que todos os apps com alvo Android 15+ suportem tamanhos de página de memória de 16 KB.”
Prazo: 1 February 2027, apps que não suportam páginas de 16 KB não podem mais lançar atualizações.
Status: seu último release de produção não suporta tamanhos de página de memória de 16 KB.
A AllsWeb resolve isso para você
Reconstruir contra a ABI de 16 KB · reassinar · reenviar
A política em linguagem simples
Traduzimos o banner do Play Console em um escopo claro, um prazo honesto e um preço fixo.
O Google Play exige que todos os apps com alvo Android 15+ suportem tamanhos de página de memória de 16 KB. Apps que não suportam ficam bloqueados de publicar novos releases.
A partir de 1º de fevereiro de 2027, se as atualizações do seu app não suportarem tamanhos de página de memória de 16 KB, o Google não permitirá enviar essas atualizações — incluindo correções críticas de segurança.
O Play Console agora exibe um banner “Status de política → Detalhes do problema”: “Seu último release de produção não suporta tamanhos de página de memória de 16 KB.” Esse é o aviso que corrigimos.
Preços transparentes
Nunca escondemos as variáveis: tempo, complexidade e quanto trabalho de recuperação a correção precisa. Você sempre vê o nível mais baixo primeiro se ele se aplica ao seu app.
Você compartilha o código-fonte da instalação mais recente que entregamos (ou outra agência entregou). Reconstruímos contra o NDK alinhado a 16 KB, reassinamos com seu keystore existente, enviamos o novo release.
Sem código em mãos? Baixamos o último APK / AAB do Play Console, descompilamos, identificamos as libs nativas alinhadas a 4 KB, atualizamos a toolchain e reconstruímos. Reassinado com seu keystore existente.
O preço exato é confirmado em até 24 horas da sua consulta. Nunca começamos o trabalho antes de você aprovar o escopo e o valor.
O que precisamos de você
Enviamos um checklist de uma página + os nomes exatos das funções do Play Console para você manter o controle. Nada sai da sua conta sem a sua aprovação.
Nos convide como usuário com “Ver informações do app”, “Gerenciar faixas de teste” e “Gerente de releases” no seu app — para verificarmos o aviso, fazer upload do novo bundle e publicar o release.
Mesmo .jks/.keystore + alias da chave + senhas usados para publicar o release atual. Sem esses, não conseguimos enviar para a mesma listagem — o Play proíbe rekey.
Qualquer .zip / repo que contém a instalação mais recente. Se não tiver, compartilhe quem instalou o app por último e te ajudaremos a recuperar.
Como a correção funciona de verdade
Conectamos ao Play Console, confirmamos o banner de política de 16 KB, baixamos o AAB atual e listamos cada biblioteca .so que precisa da reconstrução de 16 KB — próprias + transitivas.
NDK r27+, Android Gradle Plugin, AGP 8+, CMake e versões de dependências elevadas ao mínimo que emite binários ELF alinhados a 16 KB. Sem mudanças de código além do que o 16 KB exige.
AAB de release reconstruído na nova toolchain, testado por regressão no Android 14, 15 e emuladores Android 15 com páginas de 16 KB, e verificado com `zipalign -c -p 16` e `readelf -lW`.
Reassinado com seu keystore existente, enviado para o Play Console como novo release na faixa de sua escolha (interna → fechada → produção). O aviso de política é removido na próxima revisão.
Escopo claro
Auditoria + diff do seu AAB atual
Lista de cada biblioteca nativa alinhada a 4 KB + dependência que aciona a política.
Upgrade NDK / Gradle / dependências
Toolchain elevada ao mínimo que satisfaz a ABI de 16 KB sem quebrar o resto do app.
Reconstrução do AAB de release
Bundle de qualidade de produção com `zipalign -p 16` e `-c 16` verificados.
Reassinatura com seu keystore
Mesmo Package ID, mesma assinatura de dados — seus usuários existentes mantêm dados e credenciais.
Upload para o Play Console
Novo release na faixa interna / fechada / produção de sua escolha.
Smoke test de regressão pré-release
Fluxos de login, pagamento, mapa, push e imagem verificados nos emuladores Android 14 + Android 15 com páginas de 16 KB.
Aprovação de engenheiro sênior
Um humano revisa e aprova o release antes do envio — nunca um release feito apenas por modelo.
Suporte vitalício na correção
Se o Play sinalizar a mesma política novamente, reinvestigamos e reenviamos sob o suporte — sem fatura extra.
Qualquer item da direita ainda pode ser orçado — apenas como serviço separado para que a correção de 16 KB em si permaneça previsível.
Funciona para qualquer stack Android
O requisito de ABI de 16 KB se aplica a todo app com suporte NDK — não apenas Flutter, não apenas CodeCanyon. Já entregamos correções nas stacks abaixo.
Como funciona
Envie o link do Play Store, o screenshot do aviso do Play Console, sua stack tecnológica e se tem o código-fonte.
Nos convide para o Play Console (enviamos os nomes exatos das funções). Verificamos o aviso, confirmamos o escopo e fixamos o valor em até 24 horas.
NDK + Gradle + deps atualizados, AAB reconstruído e testado por regressão nos emuladores Android 15 com 16 KB. Você vê o log de verificação.
Release enviado para o Play Console com seu keystore existente. O banner de política é removido na próxima revisão do Play.
Avaliações reais · clientes reais
Os mesmos engenheiros que fazem a reconstrução de 16 KB cuidam do resto da AllsWeb. Cada avaliação abaixo é verificada na plataforma original.
Best experience — he really took his time to hear my concerns and it was so easy to collaborate with him. No problem I brought up felt unsolved. 100% satisfaction.
AllsWeb respondeu: You are very welcome! Working with you has been a delightful experience.
Verificado em Fiverr
Superb service and specially quality work in minimum time. The team is very polite and provides amazing services. Super job 👍
AllsWeb respondeu: Thank you so much for your review!
Verificado em Google
Great experience with the seller, they demonstrated expertise in their work. I am grateful.
AllsWeb respondeu: Thank you so much! It was a pleasure working with you, and I am always here whenever you need support again.
Verificado em Fiverr
Great team! They installed our apps on Android and iOS quickly and efficiently. Excellent service. Highly recommend!
AllsWeb respondeu: Thank you for your kind words! It was a pleasure assisting with your apps.
Verificado em Fiverr
On-time project and excellent communication
AllsWeb respondeu: Thank you! Timely delivery and clear communication are always my priorities.
Verificado em Fiverr
Really loved working with him. Soooo professional
AllsWeb respondeu: Thank you so much for your kind words! It was truly a pleasure working with you.
Verificado em FiverrFAQ
O Android 15 (API 35+) introduziu suporte a tamanhos de página de memória de 16 KB em novos dispositivos — uma melhoria de desempenho sobre o tamanho de página de 4 KB existente. Apps que enviam bibliotecas nativas (NDK) construídas apenas para páginas de 4 KB não carregarão corretamente em dispositivos com 16 KB. O Google Play, portanto, tornou o suporte a 16 KB um requisito de publicação: a partir de 1º de fevereiro de 2027, apps com alvo Android 15+ que não suportam páginas de 16 KB não poderão mais publicar novos releases.
Muito. O banner "Ação necessária até 1º de fevereiro de 2027" significa que o Google deu a você uma janela de prazo fixo. Após essa data, o Google bloqueia todos os novos releases do seu app — incluindo correções emergenciais, patches de segurança e atualizações sazonais — até você enviar um build com suporte a 16 KB. Seu release existente permanece no Play, mas você não pode enviar atualizações. Recomendamos corrigir isso pelo menos 2–3 semanas antes do prazo.
Por dois motivos. (1) Para confirmar o aviso real de bloqueio na sua listagem — o Play Console é a única fonte de verdade; a política pode parecer diferente por app, por faixa. (2) Para fazer upload do AAB reconstruído em seu nome para que o novo release seja publicado sob sua listagem existente, com seu keystore existente, sem impacto nos seus usuários instalados. Enviamos um guia de uma página de como nos adicionar com as funções mínimas necessárias.
Porque precisamos fazer trabalho de recuperação primeiro. Com código-fonte, simplesmente atualizamos o NDK + Gradle, reconstruímos e retestamos — geralmente 1–3 dias úteis. Sem código-fonte, baixamos o último AAB do Play Console, descompilamos, identificamos as bibliotecas nativas alinhadas a 4 KB, atualizamos a toolchain e reconstruímos. Esse trabalho de recuperação + verificação adiciona dias e risco, então o valor é orçado por caso. Sempre apresentamos o preço mais baixo primeiro se ele se aplicar.
Não. Desde que reassinemos com seu keystore existente (mesmo .jks/.keystore + alias da chave + senhas) e enviemos sob o mesmo Package ID, seus usuários existentes são atualizados no lugar — mesmo login, mesmos pedidos, mesmas preferências, mesmo push token. O Google Play não nos deixa alterar o keystore ou o Package ID de um app existente mesmo que quiséssemos.
Um keystore perdido é o único bloqueio que não conseguimos contornar — o Google Play proíbe rekey de uma listagem existente. Se seu app usa o Play App Signing, o Google mantém a chave de upload e você pode redefini-la pelo Play Console; te guiaremos nesse fluxo. Se você usou sua própria assinatura sem o Play App Signing, a única opção é uma nova listagem de app com um novo Package ID — podemos escopar isso como um engajamento separado.
Não. Qualquer app Android com bibliotecas nativas precisa da correção de 16 KB — Flutter, Kotlin nativo, Java nativo, React Native, Cordova / Ionic, Unity, apps in-house personalizados. Scripts CodeCanyon (6ammart, StackFood, 6Valley, eFood, Demandium, DriveMond, HexaCom, GroFresh) são o caso mais comum que vemos porque agrupam múltiplos SDKs que precisam da reconstrução.
1–3 dias úteis quando você tem o código-fonte e o keystore, e nosso acesso ao Play Console é aprovado. 3–7 dias úteis quando precisamos recuperar a partir do AAB publicado. O relógio pausa se estamos aguardando acesso do seu lado — você verá o timer ao vivo na página do projeto.
Não — este serviço é específico para Play Store + Android. A App Store do iOS tem sua própria trilha de políticas (notarização da Apple, manifestos de privacidade) e tratamos isso separadamente. Se também precisar de uma atualização iOS, solicite na mesma consulta e orçaremos ambos.
Novos apps que já têm alvo Android 15+ devem suportar páginas de 16 KB desde o início — isso faz parte do nosso serviço normal de submissão de app no Google Play. Esta página é para apps existentes criados antes de 16 KB se tornar um requisito de publicação.
Diga seu app, compartilhe acesso ao Play Console, e fixamos um orçamento em até 24 horas. A maioria das correções é entregue em 1–3 dias úteis quando o código-fonte está disponível.