Esses requisitos ajudam a garantir boas experiências para os usuários dos seus apps no Google Play, como parte dos quatro pilares da qualidade de apps Android.
Os requisitos de qualidade técnica no Google Play são organizados em duas categorias:
- Requisitos atuais: requisitos que já estão em vigor hoje. Atender a esses padrões é essencial para manter a estabilidade, o desempenho e a facilidade de descoberta do app no Google Play.
- Próximos requisitos: novos padrões anunciados com antecedência. Embora ainda não sejam obrigatórios, use o período de transição para avaliar seu app, integrar as ferramentas e APIs recomendadas e trabalhar para atender aos requisitos antes que a aplicação comece.
Próximos requisitos
Conforme anunciado em 26 de agosto de 2026, os apps e jogos publicados no Google Play vão ter que atender a novos requisitos de qualidade técnica. Este artigo da Central de Ajuda traz mais detalhes sobre os limites técnicos para você entender melhor os novos requisitos e se preparar antes que eles entrem em vigor.
Uso reduzido da memória
A partir de fevereiro de 2027, os apps e jogos no Google Play vão ter que atender aos novos limites de mau comportamento. Veja abaixo os detalhes específicos.
Otimização de código
A partir de fevereiro de 2027, os apps e jogos no Google Play vão ter que atender aos limites de otimização. Veja abaixo os detalhes específicos.
Restauração por login sem toque
A partir de abril de 2027, os apps no Google Play terão que permitir a restauração usando credenciais de login sem toque. Veja abaixo os detalhes específicos.
Uso reduzido da memória
O Google Play definiu limites de mau comportamento para as principais métricas do app. O uso da memória está sendo introduzido como uma nova métrica principal, com duas métricas:
- Uso da memória (RSS anônimo e espaço de troca)
- Uso da memória de bitmap
Como as métricas atuais do Android Vitals com limites de mau comportamento, o Google Play usa os dados dos últimos 28 dias para avaliar a qualidade do app.
Essas métricas estão disponíveis na seção Memória da visão geral do Android Vitals e na API Google Play Developer Reporting.
Essas métricas medem a quantidade de memória que o app usa durante o ciclo de vida depois de ser carregado do armazenamento e executado, do primeiro ao segundo plano.
Os valores dessas métricas são amostrados dos dispositivos dos usuários que aceitaram participar, anonimizados e agregados. No Play Console, é possível ver vários percentis para cada um, incluindo o 90º percentil, que é usado para avaliar o desempenho do app em relação aos limites de mau comportamento. O valor do 90º percentil significa que 10% das amostras coletadas em um período de 1 dia tiveram um número maior que esse. Por exemplo, um P90 de 1,7 GB indica que 90% das amostras coletadas tinham um valor inferior a 1,7 GB e 10% das amostras coletadas tinham um valor superior a 1,7 GB.
Esse requisito só se aplica aos formatos para celulares e tablets.
Uso da memória
O tamanho do conjunto residente anônimo (RSS anônimo) representa a memória alocada diretamente pelo aplicativo (como o heap Java/Kotlin, as alocações de memória nativa e os mapeamentos de memória anônima) que não pode ser paginada para o disco sem troca. O espaço de troca corresponde à memória compactada ou paginada na zRAM.
Os limites são adaptados à categoria do aplicativo (apps x jogos) e ao nível de RAM do dispositivo para refletir as diferentes restrições de hardware. A partir de fevereiro de 2027, os apps e jogos no Google Play vão ter que atender aos seguintes limites para manter a conformidade:
Apps
| Estado do app | Primeiro plano | Serviços percebidos pelo usuário | Segundo plano | Em cache |
| RAM física | 90º percentil | 90º percentil | 90º percentil | 90º percentil |
|
0 a 4 GB (0 MB a 3.200 MB de memória total) |
- | - | - | - |
|
4 GB (3.200 MB a 4.800 MB de memória total) |
2 GB | 1 GB | 1 GB | - |
|
6 GB (4.800 MB a 6.800 MB de memória total) |
2,25 GB | 1,25 GB | 1,25 GB | - |
|
8 GB (6.800 MB a 9.216 MB de memória total) |
2,25 GB | 1,5 GB | 1,5 GB | - |
|
12 GB (9.216 MB a 14.336 MB de memória total) |
3,25 GB | 1,75 GB | 1,75 GB | - |
|
16 GB (14.336 MB a 18.432 MB de memória total) |
4,25 GB | 2 GB | 2 GB | - |
|
16 GB ou mais (Acima de 18.432 MB de memória total) |
- | - | - | - |
Observação: cada intervalo de nível de RAM inclui o valor mais baixo. A memória total pode ser menor do que a RAM física anunciada de um dispositivo.
Jogos
| Estado do app | Primeiro plano | Serviços percebidos pelo usuário | Segundo plano | Em cache |
| RAM física | 90º percentil | 90º percentil | 90º percentil | 90º percentil |
|
0 a 4 GB (0 MB a 3.200 MB de memória total) |
- | - | - | - |
|
4 GB (3.200 MB a 4.800 MB de memória total) |
2,25 GB | 2,0 GB | 2,0 GB | - |
|
6 GB (4.800 MB a 6.800 MB de memória total) |
2,75 GB | 2,5 GB | 2,5 GB | - |
|
8 GB (6.800 MB a 9.216 MB de memória total) |
3,5 GB | 2,75 GB | 2,75 GB | - |
|
12 GB (9.216 MB a 14.336 MB de memória total) |
4 GB | 3,2 GB | 3,2 GB | - |
|
16 GB (14.336 MB a 18.432 MB de memória total) |
5 GB | 3,5 GB | 3,5 GB | - |
|
16 GB ou mais (Acima de 18.432 MB de memória total) |
- | - | - | - |
Observação: cada intervalo de nível de RAM inclui o valor mais baixo. A memória total pode ser menor do que a RAM física anunciada de um dispositivo.
Uso da memória de bitmap
Manter bitmaps por longos períodos em estados do app que não sejam o primeiro plano pode consumir muita memória. Não é possível renderizar bitmaps, a menos que a UI esteja visível. Normalmente, não é recomendável manter bitmaps por longos períodos nesses estados, mas o app pode ser amostrado logo após uma mudança de estado em que você está respondendo ativamente a onTrimMemory e liberando memória reservada para bitmaps. É por isso que esses limites são maiores que zero.
| Estado do app | 90º percentil |
| Primeiro plano | |
| Serviços percebidos pelo usuário | > 200 MB |
| Segundo plano | > 200 MB |
| Em cache | Mais de 400 MB |
Otimização de código DEX
A partir de fevereiro de 2027, os apps e jogos no Google Play vão ter que atender aos requisitos mínimos de otimização. Você precisa atingir um mínimo de 25% de otimização, ofuscação e redução para qualquer upload de app no Play Console. Sabemos que nem todos os apps ou jogos usam muito o código DEX. Por isso, esse requisito só vai ser aplicado quando os tamanhos de DEX forem significativos. É possível conferir o tamanho do DEX e as porcentagens de otimização de cada pacote de apps enviado no Pesquisador de pacotes de apps do Play Console.
Esse requisito se aplica a todos os formatos.
| Jogos | Apps | |||
| Otimização de código | Jogos com código DEX maior que 50 MB | Apps com código DEX maior que 10 MB | ||
| Ofuscação | 25% | 25% | ||
| Otimização | 25% | 25% | ||
| Reduzindo | 25% | 25% | ||
Você pode usar qualquer ferramenta, como o R8 ou outro compactador de apps, para atingir os limites mínimos de 25%.
Use o Analisador de configuração do R8 para receber mais insights e ajustar ainda mais o desempenho. Se você publicar usando pipelines de CI/CD ou em um ambiente empresarial, as versões locais podem não corresponder perfeitamente à versão enviada ao Play Console para distribuição aos usuários. Por isso, algumas pequenas diferenças são esperadas.
Restauração por login sem toque
A partir de abril de 2027, os apps que aceitam o login do usuário (opcional ou obrigatório) terão que permitir a restauração por login sem toque quando um usuário migrar de um dispositivo Android anterior para um novo e optar por restaurar os dados via transferência entre dispositivos ou backup na nuvem. Os logins manuais durante a configuração do dispositivo não apenas criam atrito na integração e diminuem a retenção de usuários, mas também expõem ativamente os apps a vulnerabilidades de segurança críticas, como phishing e roubo de credenciais durante a configuração. A API Android Restore Credentials é o principal método para resolver esses problemas e atender a esse requisito. Ela está disponível no Android 9 e versões mais recentes.
- Os apps que se integrarem ao Block Store até 30 de setembro de 2026 para restaurar o estado de login de um usuário serão considerados em conformidade com esse requisito.
- Os apps de gerenciamento de dispositivos corporativos e permanentemente particulares estão fora do escopo desse requisito.
- Os apps sujeitos a exigências regulatórias ou de compliance rígidas que afetam o funcionamento do recurso de login (como serviços financeiros ou de saúde) podem se qualificar para uma isenção. Os desenvolvedores precisam enviar um pedido de isenção desse requisito pelo Play Console antes da data de aplicação.
- No momento, os jogos estão fora do escopo desse requisito. Os desenvolvedores vão receber orientações exclusivas e soluções personalizadas para casos de uso complexos de autenticação de jogos em 2027. No caso dos jogos que aceitam uma única conta de usuário, recomendamos o uso da API Restore Credentials para permitir o login sem toque.
Mais detalhes sobre o requisito e as exceções serão publicados nos próximos meses.
Integração e testes
Teste sua integração para garantir que os usuários tenham uma experiência otimizada e que você atenda a esse requisito. As AI skill for Restore Credentials, publicadas recentemente, podem ajudar você a fazer a integração com mais facilidade.
Formatos e versões do Android no escopo
Esse requisito só se aplica aos formatos para celulares e tablets. No momento, a API Restore Credentials não é compatível com outros formatos. A Restore Credentials está disponível no Android 9 e versões mais recentes.
Perguntas Frequentes sobre os próximos requisitos
Requisitos de memória
Por que o Google está introduzindo restrições para métricas de memória?
Uma crise de memória em todo o ecossistema é iminente devido ao aumento dos custos de RAM. O uso ineficiente da memória, como um único app com um vazamento de memória descontrolado que consome a maior parte da memória do dispositivo, faz com que o dispositivo apresente renderização lenta e feche outros apps que estão funcionando corretamente em segundo plano. O Android anunciou limites de memória rígidos, e o Google Play quer garantir que seu app esteja dentro desses limites e minimizar as chances de o dispositivo precisar fechar o app.
Como posso reduzir o uso da memória?
Siga as práticas recomendadas para apps e jogos. As principais estratégias incluem liberar recursos em onTrimMemory() (inclusive usando o mecanismo de jogo para tal), evitar vazamentos de memória estática usando componentes com reconhecimento de ciclo de vida, criar perfis de alocações e heap dumps usando o Perfetto e minimizar tarefas em segundo plano de longa duração
Como posso reduzir minhas alocações de bitmap?
Reduza a resolução e decodifique imagens para chegar às dimensões exatas da visualização, use bibliotecas modernas de carregamento de imagens (como Coil ou Glide) configuradas com caches que economizam memória, libere bitmaps não utilizados na memória quando a UI estiver oculta (usando TRIM_MEMORY_UI_HIDDEN em onTrimMemory) e evite manter referências estáticas a bitmaps ou visualizações.
Preciso usar o R8 para otimização de código?
Embora seja altamente recomendável usar o R8 pelas otimizações e insights avançados, outras ferramentas de otimização estão disponíveis e podem ser usadas para atender a esse requisito.
Por que os requisitos são diferentes para apps e jogos?
Os jogos têm diferentes padrões de uso da memória para oferecer uma experiência de jogo tranquila, principalmente em primeiro plano. Eles costumam usar mecanismos de jogo nativos, que têm restrições técnicas diferentes dos apps. Os requisitos de jogos são adaptados ao caso de uso.
Como o Google Play diferencia um app de um jogo?
Ele se baseia na categoria que você pode ajustar nas Configurações da loja no Play Console, o que influencia em qual parte da Google Play Store seu app aparece. Mudar a categoria do app para uma que não reflita com precisão a funcionalidade principal dele na tentativa de se qualificar para limites técnicos diferentes é uma violação da política de metadados da página de detalhes do app.
Como esses requisitos se cruzam com o programa Experiência nos Apps e os programas Level Up?
Quando a aplicação desses limites de memória estiver em vigor, os apps e jogos precisarão obedecer a todos os limites de memória para se qualificar ou manter a qualificação para o AEP e o Level Up.
Os limites de memória do Android estão no Android 17 ou versões mais recentes. Os requisitos do Google Play são apenas para o A17 ou versões mais recentes?
Não, o Google Play avalia todas as versões do app em que os dados estão disponíveis. Ou seja, a partir do Android 13 no caso de "Uso da memória (RSS anônimo e espaço de troca)" e "Uso da memória de bitmap".
Por que os limites são diferentes para RSS anônimo/espaço de troca e para cada nível de RAM?
A divisão por nível de RAM reconhece que os dispositivos têm diferentes níveis de tolerância ao uso excessivo da memória. Algo que funciona bem em um aparelho de 16 GB pode não ter o mesmo desempenho em um dispositivo de 4 GB. Você precisa garantir que o app não use memória excessiva em todos os níveis de RAM.
Quais formatos estão no escopo dos requisitos de memória?
No caso das métricas "Uso da memória (RSS anônimo e espaço de troca)" e "Uso da memória de bitmap", os formatos para celulares e tablets estão no escopo.
Quais ferramentas estão disponíveis para entender melhor meu uso da memória?
-
Para começar a melhorar a memória de apps ou jogos, use nosso guia de memória.
-
Google Play Console (Android Vitals): monitore as métricas P90 contínuas de 28 dias em "Uso da memória (RSS anônimo e espaço de troca)" e "Uso da memória de bitmap", que podem ser filtradas por estado do app (primeiro plano, serviço percebido pelo usuário, segundo plano e em cache), nível de RAM do dispositivo (por exemplo, 4 a 6 GB), versão do Android e versão do app.
-
API Google Play Developer Reporting: consulte métricas de forma programática para automatizar relatórios, identificar regressões de desempenho e integrar dados do Android Vitals aos seus painéis internos.
-
Heap Dumps e Memory Profiler do Android Studio: inspecione alocações em tempo real no heap Java/Kotlin, na memória nativa e nos gráficos. Capture e analise heap dumps (.
hprof) para detectar vazamentos de memória, atividades não liberadas, bitmaps duplicados e caminhos de retenção. -
Perfetto e rastreamento do sistema: use o Perfetto (
heapprofd) para amostragem de baixa sobrecarga de alocações nativas e Java para identificar pilhas de chamadas que causam picos de memória. Os rastreamentos do sistema ajudam a monitorar o uso da memória em transições de ciclo de vida e se correlacionam com eventos do low-memory killer (lmkd). As habilidades de análise de IA (como as habilidades de IA do Perfetto) também estão disponíveis para automatizar a análise de rastreamento e heap dump. -
Ferramentas de diagnóstico no dispositivo: use
adb shell dumpsys meminfo <package_name>para um detalhamento em tempo real de PSS, Private Dirty (RSS Anônimo), Swap Dirty (zRAM) e Bitmaps ou instrumentoComponentCallbacks2.onTrimMemory()para telemetria personalizada do cliente.
Por que há um limite de tamanho de DEX para otimização de código?
Embora sempre recomendemos a otimização de código, devido aos muitos benefícios de desempenho, estamos equilibrando o esforço necessário para recriar e otimizar um app ou jogo com o benefício para o usuário. Os tamanhos pequenos de DEX (menos de 10 MB para apps e menos de 50 MB para jogos) têm impacto limitado no consumo de memória dos dispositivos. Por isso, não estamos exigindo a otimização de código aqui.
Restauração por login sem toque
A chave de restauração persiste se um app é desinstalado e reinstalado no mesmo dispositivo?
Não. A chave de restauração é excluída automaticamente quando um app é desinstalado.
Essa exigência se aplica a todos os formatos?
Não, o requisito das credenciais de restauração sem toque se aplica apenas aos formatos para celulares e tablets.
Esse requisito se aplica se um usuário não estiver conectado ou a apps sem contas de usuário?
Não. O requisito foi criado para preservar um estado de login ativo em todas as transições de dispositivo.
-
Apps sem login do usuário: apps que não oferecem contas de usuário ou funcionalidade de login não são afetados.
-
Usuários desconectados ou visitantes: se um usuário estava desconectado, usando o modo visitante ou saiu antes de trocar de dispositivo, o app precisa ser iniciado no mesmo estado não autenticado no novo dispositivo.
O recurso Restore Credentials funciona com qualquer método de autenticação?
Sim, a API Restore Credentials foi projetada para funcionar com qualquer método de autenticação, permitindo que os apps armazenem uma chave de restauração.
O recurso Restore Credentials lida com escopos de autorização ou verificação de aumento (por exemplo, MFA)?
-
Não. A API Restore Credentials foi projetada exclusivamente para autenticação (restaurar a identidade e a sessão do usuário). Ela não lida com solicitações de autorização secundárias, como concessões de permissão do OAuth ou desafios multifatoriais.
-
Recomendamos uma abordagem de duas etapas:
-
Restaurar identidade: use as credenciais de restauração para restabelecer silenciosamente o estado de login principal do usuário na primeira inicialização no novo dispositivo.
-
Autorizar no contexto: solicite permissões de recursos específicos (por exemplo, acesso ao Google Drive) no momento em que o usuário acessar recursos que as exijam. Se necessário, você também pode solicitar a autenticação de progressão (por exemplo, MFA)
-
Como saber se minha integração atende ao requisito?
A restauração bem-sucedida do login do usuário é determinada pela recuperação bem-sucedida da chave de restauração. Os apps que não atenderem a esse requisito serão notificados.
Como posso saber se meu app faz parte de uma exceção?
Mais orientações sobre exceções serão fornecidas posteriormente.
Como gerenciar casos de uso de autenticação multifator (MFA)?
A API Restore Credentials não lida com desafios de MFA nem se destina a burlar as políticas de segurança do app. Ao recuperar uma chave de restauração em um novo dispositivo, o app precisa decidir se vai exigir uma verificação progressiva. Restaurar o contexto de identidade do usuário (por exemplo, exibir "Olá, Alex") é suficiente para atender ao requisito. No entanto, uma restauração entre dispositivos fornece uma prova sólida de posse e, portanto, não deve exigir uma etapa progressiva de MFA.
Por que os jogos estão isentos desse requisito?
Os jogos estão inicialmente isentos, já que estamos trabalhando em soluções personalizadas para casos de uso de autenticação complexos, que são comuns em jogos. No caso dos jogos que aceitam o login com uma única conta, recomendamos adotar a API Restore Credentials para permitir o login sem toque.
Posso usar a Block Store para atender aos novos requisitos de integração de dispositivos?
Sim, uma integração com a Block Store pode ser considerada compatível, mas apenas se tiver sido concluída e estiver em produção até 30 de setembro de 2026 e se restaurar o estado de login do usuário. Outros tipos de integração ou aquelas concluídas após a data limite não são consideradas em conformidade.
Por que o prazo para as integrações da Block Store é 30 de setembro de 2026?
A data de 30 de setembro de 2026 é um marco claro para as equipes que estão integrando a Block Store. Isso garante que as implementações de login sem toque permaneçam válidas, enquanto direciona as integrações futuras para o padrão recomendado do Credential Manager.
O que acontece quando o usuário sai ou exclui a conta no dispositivo antigo?
O app precisa excluir ativamente a chave de restauração. Se o app for desinstalado, a chave de restauração será excluída automaticamente.
O que faço com os usuários no modo visitante?
O requisito se aplica apenas à parte autenticada do app. Se um usuário era um visitante no dispositivo antigo, o app precisa ser iniciado no modo visitante no novo dispositivo.
O que faço com usuários que usam várias contas no mesmo dispositivo?
Para atender ao requisito, o app precisa armazenar a chave de restauração da conta de usuário ativa no momento (ou da última conta ativa) no dispositivo de origem. Saiba mais na Documentação da Restore Credentials.
Posso enviar notificações para usuários restaurados sem exigir que eles concedam novamente as permissões de notificação?
Sim. Os serviços de backup e restauração processam a restauração das permissões do app, incluindo as de notificações, do dispositivo anterior. Isso permite que você envie notificações genéricas. Além disso, quando combinada com as credenciais de restauração, VOCÊ pode reengajar os usuários com notificações personalizadas no novo dispositivo sem que eles precisem abrir o app primeiro.
Outros
Esses requisitos são opcionais?
Todos os requisitos publicados nesta página são obrigatórios. Não atender a um requisito pode afetar a visibilidade e os recursos de publicação de um app no Google Play.
Recursos úteis
Otimização de código
- Ativar a otimização de apps com o R8 | Qualidade do app | Desenvolvedores Android
- Usar o R8 no modo completo | Qualidade do app | Desenvolvedores Android
- Usar o R8 Configuration Analyzer | Qualidade do app | Desenvolvedores Android
Uso da memória (RSS anônimo e espaço de troca)
Uso da memória de bitmap
Restore Credentials
- Noções básicas sobre Restore Credentials
- Guias oficiais: implementação da Restore Credentials
- Materiais de teste: como testar a Restore Credentials no Android Studio
- Estudo de caso de impacto no mundo real: How Uber Reduced Manual Logins by 4M Per Year ("Como a Uber reduziu os logins manuais em 4 milhões por ano", em tradução livre; blog em inglês)
Habilidades
As habilidades são instruções e recursos modulares otimizados para IA que ajudam os LLMs a entender e executar melhor padrões específicos que seguem as práticas recomendadas e as orientações sobre desenvolvimento para Android em developer.android.com. Elas podem ser usadas com a CLI do Android ou outras ferramentas baseadas em LLM.
- R8 Analysis Skill: analisa a configuração do R8 de um app e mantém as regras
- Perfetto AI Skills: use para interpretar heap dumps e receber sugestões práticas para melhorar o desempenho da memória
- Android Profiler Skill: use para interpretar heap dumps e traces e receber sugestões úteis para melhorar o desempenho da memória.
- Restore Credentials Skill: use para receber ajuda na integração e no teste da configuração de restauração de credenciais
Requisitos atuais
Os requisitos técnicos atuais do Google Play incluem limites de mau comportamento em um conjunto das principais métricas, além de requisitos relacionados ao pacote de apps que você envia ao Play Console.
Principais métricas e estabilidade
O Google Play monitora as principais métricas de desempenho para garantir que os apps atendam aos padrões de estabilidade. Ultrapassar esses limites pode afetar a capacidade de descoberta do seu app na Google Play Store.
- Taxa de falhas percebidas pelo usuário: limite de 1,09% no geral (média entre dispositivos), 8% por modelo de celular e 4% por modelo de relógio. Saiba mais
- Taxa de ANR percebido pelo usuário: limite de 0,47% no geral (média entre dispositivos), 8% por modelo de celular e 5% por modelo de relógio. Saiba mais
- Wake locks parciais em excesso: limite de 5% no geral (média entre dispositivos). Manter o dispositivo ativado sem necessidade gasta a bateria. Empregue corretamente os wake locks e considere usar o WorkManager para tarefas em segundo plano. Saiba mais
- Uso excessivo da bateria: limite de 1% por modelo de relógio. Saiba mais
Requisitos técnicos
O Google Play é compatível com uma ampla variedade de dispositivos com diferentes configurações e arquiteturas de hardware. Algumas arquiteturas são fundamentais para o futuro do Android. Por isso, os novos pacotes de apps enviados ao Play Console precisam ser compatíveis com elas para garantir que possamos oferecer as experiências do seu app.
- Compatibilidade com 64 bits: os apps que contêm código nativo precisam funcionar com arquiteturas apenas de 64 bits. Saiba mais
- Compatibilidade com memória para páginas de 16 KB: os apps que contêm código nativo precisam funcionar em dispositivos com memória para páginas de 16 KB. Os apps somente Java/Kotlin são compatíveis por padrão. Saiba mais
- Compatibilidade com arquiteturas de 64 bits no Wear OS e com memória para páginas de 16 KB: obrigatória a partir de 15 de setembro de 2026. Saiba mais
- Compatibilidade com arquiteturas de 64 bits em TVs e com memória para páginas de 16 KB: obrigatória a partir de 1º de agosto de 2026. Saiba mais