Os requisitos de qualidade técnica do Google Play ajudam a garantir experiências de alta qualidade para os utilizadores das suas apps no Google Play, como parte dos quatro pilares da qualidade das apps Android.
Os requisitos de qualidade técnica no Google Play estão organizados em duas categorias:
- Requisitos atuais: requisitos que estão aplicados ativamente atualmente. Cumprir estas normas é essencial para manter a estabilidade, o desempenho e a visibilidade da sua app no Google Play.
- Requisitos futuros: novas normas anunciadas antecipadamente. Embora estes ainda não sejam obrigatórios, deve usar o período de transição para avaliar a sua app, integrar as ferramentas e as APIs recomendadas e trabalhar no sentido de cumprir os requisitos antes do início da aplicação.
Requisitos futuros
Conforme anunciado a 26 de agosto de 2026, existem requisitos de qualidade técnica futuros para apps e jogos publicados no Google Play. Este artigo do Centro de Ajuda fornece mais detalhes sobre os limites técnicos e tem como objetivo ajudar a compreender e preparar-se para os novos requisitos antes de entrarem em vigor.
Utilização de memória reduzida
A partir de fevereiro de 2027, as apps e os jogos no Google Play vão ter de cumprir os novos limites de comportamento incorreto. Consulte abaixo os detalhes específicos.
Otimização de código
A partir de fevereiro de 2027, as apps e os jogos no Google Play vão ter de cumprir limites de otimização. Consulte abaixo os detalhes específicos.
Restauro do início de sessão sem toques
A partir de abril de 2027, as apps no Google Play vão ter de ser compatíveis com as credenciais de restauro sem toques. Consulte abaixo os detalhes específicos.
Utilização de memória reduzida
O Google Play definiu limites de comportamento incorreto para as métricas essenciais do Android vitals da sua app. A utilização de memória está a ser introduzida como novas métricas essenciais do Android vitals, com duas métricas:
- Utilização de memória (RSS anónimo + espaço de memória)
- Utilização de memória do mapa de bits
Tal como as métricas do Android vitals existentes com limites de comportamento incorreto, o Google Play usa os últimos 28 dias de dados para avaliar a qualidade da sua app.
Estas métricas estão disponíveis no título Memória na vista geral do Android vitals, bem como na API Google Play Developer Reporting.
Estas métricas medem a quantidade de memória que a sua app usa ao longo do respetivo ciclo de vida, assim que é carregada a partir do armazenamento e executada, em primeiro plano e em segundo plano.
Os valores destas métricas são amostrados a partir dos dispositivos dos utilizadores que aceitaram, anonimizados e agregados. Na Play Console, pode ver vários percentis para cada um, incluindo o percentil 90, que é usado para avaliar o desempenho da sua app em relação aos limites de comportamento incorreto. O valor do percentil 90 significa que 10% das amostras recolhidas ao longo de um período de 1 dia tiveram um número superior a esse. Por exemplo, um P90 de 1,7 GB indica que 90% das amostras recolhidas tinham um valor inferior a 1,7 GB e 10% das amostras recolhidas tinham um valor superior a 1,7 GB.
Este requisito aplica-se apenas aos formatos para telemóvel e tablet.
Utilização de memória
O Resident Set Size anónimo (RSS anónimo) representa a memória atribuída diretamente pela sua aplicação (como a memória Java/Kotlin, as atribuições de memória nativa e os mapeamentos de memória anónimos) que não pode ser paginada para o disco sem espaço de memória. O espaço de memória representa a memória comprimida ou paginada em zRAM.
Os limites são personalizados de acordo com a categoria da aplicação (apps vs. jogos) e o nível de RAM do dispositivo para refletir as várias restrições de hardware. A partir de fevereiro de 2027, as apps e os jogos no Google Play têm de cumprir os seguintes limites para se manterem em conformidade:
Apps
| Estado da app | Em primeiro plano | Serviços observados pelo utilizador | Em segundo plano | Em cache |
| RAM física | Percentil 90 | Percentil 90 | Percentil 90 | Percentil 90 |
|
0 – 4 GB (0 MB – 3200 MB de memória total) |
- | - | - | - |
|
4 GB (3200 MB – 4800 MB de memória total) |
2 GB | 1 GB | 1 GB | - |
|
6 GB (4800 MB – 6800 MB de memória total) |
2,25 GB | 1,25 GB | 1,25 GB | - |
|
8 GB (6800 MB – 9216 MB de memória total) |
2,25 GB | 1,5 GB | 1,5 GB | - |
|
12 GB (9216 MB – 14 336 MB de memória total) |
3,25 GB | 1,75 GB | 1,75 GB | - |
|
16 GB (14 336 MB – 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) |
- | - | - | - |
Nota: cada intervalo de nível de RAM inclui o respetivo valor mais baixo. A memória total pode ser inferior à RAM física anunciada de um dispositivo.
Jogos
| Estado da app | Em primeiro plano | Serviços observados pelo utilizador | Em segundo plano | Em cache |
| RAM física | Percentil 90 | Percentil 90 | Percentil 90 | Percentil 90 |
|
0 – 4 GB (0 MB – 3200 MB de memória total) |
- | - | - | - |
|
4 GB (3200 MB – 4800 MB de memória total) |
2,25 GB | 2,0 GB | 2,0 GB | - |
|
6 GB (4800 MB – 6800 MB de memória total) |
2,75 GB | 2,5 GB | 2,5 GB | - |
|
8 GB (6800 MB – 9216 MB de memória total) |
3,5 GB | 2,75 GB | 2,75 GB | - |
|
12 GB (9216 MB – 14 336 MB de memória total) |
4 GB | 3,2 GB | 3,2 GB | - |
|
16 GB (14 336 MB – 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) |
- | - | - | - |
Nota: cada intervalo de nível de RAM inclui o respetivo valor mais baixo. A memória total pode ser inferior à RAM física anunciada de um dispositivo.
Utilização de memória do mapa de bits
Manter mapas de bits durante longos períodos em estados da app que não sejam em primeiro plano pode consumir demasiada memória. Não é possível renderizar mapas de bits, a menos que a IU esteja visível. Normalmente, não deve manter mapas de bits durante longos períodos nestes estados, mas a sua app pode ser amostrada pouco depois de uma alteração de estado em que esteja a responder ativamente a onTrimMemory e a libertar memória retida para mapas de bits, pelo que estes limites são superiores a zero para ter isto em conta.
| Estado da app | Percentil 90 |
| Em primeiro plano | |
| Serviços observados pelo utilizador | > 200 MB |
| Em segundo plano | > 200 MB |
| Em cache | > 400 MB |
Otimização de código DEX
A partir de fevereiro de 2027, as apps e os jogos no Google Play vão ter de cumprir requisitos mínimos de otimização. Tem de alcançar um mínimo de 25% de otimização, ocultação e redução para todos os carregamentos de apps para a Play Console. Compreendemos que nem todas as apps ou jogos fazem um uso intensivo do código DEX e, por isso, este requisito só vai ser aplicado quando tiver tamanhos de DEX significativos. Pode ver o tamanho do DEX, bem como as percentagens de otimização de cada pacote de apps que carrega no explorador de pacote de apps na Play Console.
Este requisito aplica-se a todos os formatos.
| Jogos | Apps | |||
| Otimização de código | Jogos com código DEX > 50 MB | Apps com código DEX > 10 MB | ||
| Ocultação | 25% | 25% | ||
| Otimização | 25% | 25% | ||
| Redução | 25% | 25% | ||
Pode usar qualquer ferramenta, como o R8 ou outro redutor de apps, para alcançar os limites mínimos de 25%.
Pode usar o analisador de configuração do R8 para ver mais estatísticas e aperfeiçoar ainda mais o desempenho. Tenha em atenção que, se publicar através de pipelines de CI/CD ou num ambiente empresarial, as suas compilações locais podem não corresponder perfeitamente à compilação carregada para a Play Console para distribuição aos utilizadores, pelo que podem ser esperadas algumas pequenas diferenças.
Restauro do início de sessão sem toques
A partir de abril de 2027, as apps compatíveis com o início de sessão do utilizador (opcional ou obrigatório) têm de ser compatíveis com o restauro do início de sessão sem toques quando um utilizador muda do respetivo dispositivo Android anterior para um novo e seleciona a opção para restaurar os dados a partir de uma transferência entre dispositivos ou uma cópia de segurança na nuvem. Os inícios de sessão manuais durante a configuração do dispositivo não só criam fricção no processo de integração e diminuem a retenção de utilizadores, como também expõem ativamente as 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 estes problemas e cumprir este requisito, e está disponível a partir do Android 9.
- As apps que se integrem com a Block Store, até 30 de setembro de 2026, para restaurar o estado de início de sessão de um utilizador são consideradas em conformidade com este requisito.
- As apps de gestão de dispositivos empresariais e permanentemente privadas estão fora do âmbito deste requisito.
- As apps sujeitas a exigências regulamentares ou de conformidade rigorosas que afetam o funcionamento da sua funcionalidade de início de sessão (como serviços financeiros ou cuidados de saúde) podem ser elegíveis para uma isenção. Os programadores têm de enviar um pedido de isenção para este requisito através da Play Console antes da data de aplicação.
- Os jogos encontram-se fora do âmbito deste requisito. Os programadores devem esperar orientações dedicadas e soluções personalizadas para exemplos de utilização de autenticação de videojogos complexos em 2027. Para jogos que são compatíveis com uma única conta de utilizador, recomendamos vivamente a utilização da API Restore Credentials para serem compatíveis com o início de sessão sem toques.
Vão ser publicados mais detalhes sobre o requisito e as exceções nos próximos meses.
Integração e teste
Teste a integração para garantir que os utilizadores têm uma experiência integrada e que cumpre este requisito. A competência de IA para a API Restore Credentials publicada recentemente pode ajudar a fazer a integração mais facilmente.
Formatos e versões do Android abrangidos
Este requisito aplica-se apenas aos formatos para telemóvel/tablet. A API Restore Credentials não é compatível com outros formatos no momento. A API Restore Credentials está disponível a partir do Android 9.
Perguntas frequentes sobre os requisitos futuros
Requisitos de memória
Porque é que a Google está a introduzir aplicações para métricas de memória?
Uma crise de memória em todo o ecossistema é iminente devido ao aumento dos custos da RAM. A utilização ineficiente da memória, como uma única app com uma fuga de memória descontrolada que consome a maior parte da memória do dispositivo, faz com que o dispositivo apresente interrupções e encerre outras apps com bom comportamento em segundo plano. O Android anunciou limites de memória rigorosos e o Google Play quer garantir que a sua app se enquadra nestes limites e minimizar as hipóteses de o dispositivo ter de encerrar a app.
Como posso reduzir a minha utilização de memória?
Siga as práticas recomendadas para apps e jogos. As principais estratégias incluem libertar recursos em onTrimMemory() (incluindo tirar partido do motor de jogo para o fazer), evitar fugas de memória estáticas através de componentes que reconhecem o ciclo de vida, criar perfis de atribuições e capturas da área dinâmica para dados com o Perfetto e minimizar as tarefas em segundo plano de longa duração
Como posso reduzir as minhas atribuições de mapas de bits?
Faça a subamostragem e descodifique as imagens para corresponderem às dimensões exatas da vista de apresentação, use bibliotecas de carregamento de imagens modernas (como o Coil ou o Glide) configuradas com caches que têm em conta a memória, liberte mapas de bits na memória não usados quando a IU está oculta (através de TRIM_MEMORY_UI_HIDDEN em onTrimMemory) e evite manter referências estáticas a mapas de bits ou vistas.
Tenho de usar o R8 para a otimização de código?
Embora recomendemos vivamente a utilização do R8 pelas suas otimizações e estatísticas avançadas, estão disponíveis outras ferramentas de otimização que podem ser usadas para cumprir este requisito.
Porque é que os requisitos diferem entre apps e jogos?
Os jogos têm diferentes padrões de utilização de memória para oferecer uma experiência de jogabilidade fluida, principalmente em primeiro plano. Normalmente, dependem de motores de jogos nativos que têm restrições técnicas diferentes das apps. Os requisitos de jogos são adaptados ao exemplo de utilização.
Como é que o Google Play distingue entre uma app e um jogo?
Isto baseia-se na categoria que pode configurar nas definições da Play Store na Play Console, o que influencia a parte da Play Store em que a sua app é apresentada. Tenha em atenção que alterar a categoria da sua app para uma que não reflita com precisão a respetiva funcionalidade essencial, numa tentativa de se qualificar para limites técnicos diferentes, constitui uma violação da Política de Metadados da Ficha da loja.
Como é que estes requisitos se cruzam com o Programa de experiência nas apps e os programas Level Up?
Assim que a aplicação destes limites de memória entrar em vigor, as apps e os jogos têm de estar em conformidade com todos os limites de memória para serem elegíveis ou manterem a elegibilidade para o PEA e os Level Up.
Os limites de memória do Android estão disponíveis a partir do Android 17. Os requisitos do Google Play aplicam-se apenas a partir do Android 17?
Não, o Google Play avalia todas as versões da app para as quais existem dados disponíveis. Isto é a partir do Android 13 para a Utilização de memória (RSS anónimo + espaço de memória) e a Utilização de memória do mapa de bits.
Porque é que existem limites diferentes para RSS anónimo + espaço de memória e cada nível de RAM?
A divisão por nível de RAM reconhece que diferentes dispositivos têm níveis de tolerância variáveis para uma utilização de memória excessiva. O que tem um bom desempenho num dispositivo de 16 GB pode não ter um desempenho tão bom num dispositivo de 4 GB. Deve garantir que a respetiva app não usa memória excessiva em todos os níveis de RAM
Que formatos são abrangidos pelos requisitos de memória?
Para a métrica Utilização de memória (RSS anónimo + espaço de memória) e Utilização de memória do mapa de bits, está abrangido o formato para telemóvel e tablet.
Que ferramentas estão disponíveis para compreender melhor a minha utilização de memória?
-
Pode começar por melhorar a memória para apps ou jogos com as nossas orientações de memória.
-
Google Play Console (Android vitals): monitorize as métricas P90 de 28 dias consecutivos para Utilização de memória (RSS anónimo + espaço de memória) e Utilização de memória do mapa de bits, filtráveis pelo estado da app (Em primeiro plano, Serviço observado pelo utilizador, Em segundo plano, Em cache), nível de RAM do dispositivo (por exemplo, 4 a 6 GB), versão do Android e lançamento da app.
-
API Google Play Developer Reporting: consulte métricas de forma programática para automatizar os relatórios, identificar regressões de desempenho e integrar dados do Android vitals nos seus painéis de controlo internos.
-
Memory Profiler e capturas da área dinâmica para dados do Android Studio: inspecione as atribuições em tempo real na memória Java/Kotlin, na memória nativa e nos gráficos. Capture e analise as capturas da área dinâmica para dados (.
hprof) para detetar fugas de memória, atividades não lançadas, mapas de bits duplicados e caminhos de retenção. -
Perfetto e Rastreio do sistema: use o Perfetto (
heapprofd) para amostragem de sobrecarga reduzida de atribuições memória nativa e Java para identificar pilhas de chamadas que causam picos de memória. Os rastreios do sistema ajudam a monitorizar a utilização de memória em transições do ciclo de vida e correlacionam-se com eventos de encerramento por falta de memória (lmkd). As competências de análise de IA (como as competências de IA do Perfetto) também estão disponíveis para automatizar os rastreios e a análise de capturas da área dinâmica para dados. -
Ferramentas de diagnóstico no dispositivo: use
adb shell dumpsys meminfo <package_name>para uma análise detalhada em tempo real de PSS, Private Dirty (RSS anónimo), Swap Dirty (zRAM) e mapas de bits, ou useComponentCallbacks2.onTrimMemory()para telemetria de cliente personalizada.
Porque é que existe um limite mínimo de tamanho do DEX para a otimização de código?
Embora recomendemos sempre a otimização do código, devido às muitas vantagens em termos de desempenho, estamos a equilibrar o esforço necessário para reconstruir e otimizar uma app ou um jogo, juntamente com a vantagem para o utilizador. Os tamanhos de DEX pequenos (menos de 10 MB para apps e menos de 50 MB para jogos) têm um impacto limitado na quantidade de memória dos dispositivos e, por isso, não estamos a exigir a otimização do código neste caso.
Restauro do início de sessão sem toques
A chave de restauro persiste se uma app for desinstalada e reinstalada no mesmo dispositivo?
Não. A chave de restauro é eliminada automaticamente quando uma app é desinstalada.
Este requisito aplica-se a todos os formatos?
Não, o requisito de credenciais de restauro sem toques só se aplica aos formatos para telemóvel e tablet.
Este requisito aplica-se se um utilizador não tiver sessão iniciada ou a apps sem contas de utilizador?
Não. O requisito foi concebido para preservar um estado de início de sessão ativo em transições de dispositivos.
-
Apps sem início de sessão do utilizador: as apps que não oferecem contas de utilizador nem a funcionalidade de início de sessão não são afetadas.
-
Utilizadores convidados ou com sessão terminada: se um utilizador tiver terminado sessão, estiver a usar o Modo convidado ou tiver terminado sessão antes de mudar de dispositivo, a sua app deve ser iniciada no mesmo estado não autenticado no novo dispositivo.
A API Restore Credentials funciona com qualquer método de autenticação?
Sim, a API Restore Credentials foi concebida para funcionar com qualquer método de autenticação, permitindo que as apps armazenem uma chave de restauro.
A API Restore Credentials processa âmbitos de autorização ou validação de nível superior (por exemplo, MFA)?
-
Não. A API Restore Credentials foi concebida exclusivamente para autenticação (restaurar a identidade e a sessão do utilizador). Não processa pedidos de autorização secundários, como concessões de autorizações OAuth ou desafios multifator.
-
Recomendamos uma abordagem em dois passos:
-
Restaurar a identidade: use a API Restore Credentials para restabelecer silenciosamente o estado de início de sessão principal do utilizador ao iniciar pela primeira vez no novo dispositivo.
-
Autorizar no contexto: peça autorizações de recursos específicos (por exemplo, acesso ao Google Drive) no momento em que o utilizador acede às funcionalidades que as requerem. Se necessário, também pode pedir uma autenticação de nível superior (por exemplo, MFA)
-
Como posso saber se a minha integração está a cumprir o requisito?
A restauração bem-sucedida do início de sessão do utilizador é determinada através da obtenção bem-sucedida da chave de restauro. As apps que identificarmos como não cumprindo este requisito serão notificadas.
Como posso saber se a minha app faz parte de uma exceção?
Serão fornecidas mais orientações sobre as exceções numa data posterior.
Como posso gerir os exemplos de utilização da autenticação multifator (MFA)?
A API Restore Credentials não processa desafios de MFA nem se destina a contornar as políticas de segurança da sua app. Ao obter uma chave de restauro num novo dispositivo, a sua app tem de decidir se quer exigir uma validação de nível superior adicional. Restaurar o contexto de identidade do utilizador (por exemplo, apresentar "Olá novamente, Alex") é suficiente para cumprir o requisito. No entanto, tenha em atenção que um restauro entre dispositivos fornece uma prova forte de propriedade e, por isso, não deve exigir um passo de MFA adicional.
Porque é que os jogos estão isentos deste requisito?
Os jogos estão inicialmente isentos, uma vez que estamos a trabalhar em soluções personalizadas para exemplos de utilização de autenticação complexos, que são comuns para jogos. Recomendamos vivamente que os jogos que sejam compatíveis com o início de sessão com uma única conta adotem a API Restore Credentials para serem compatíveis com o início de sessão sem toques.
Posso usar a Block Store para cumprir os novos requisitos de integração de dispositivos?
Sim, uma integração com a Block Store pode ser considerada em conformidade, mas apenas se a integração tiver sido concluída e estiver em produção até 30 de setembro de 2026, inclusive, e restaurar com êxito o estado de início de sessão de um utilizador. Outros tipos de integração ou os concluídos após o prazo limite não são considerados em conformidade.
Porque é que existe um prazo até 30 de setembro de 2026 para as integrações da Block Store?
A data de 30 de setembro de 2026 constitui um marco claro para as equipas que estão atualmente a integrar a Block Store. Garante que as implementações de início de sessão sem toques existentes permanecem válidas, ao mesmo tempo que direciona as integrações futuras para o padrão recomendado do Gestor de credenciais.
O que acontece quando o utilizador termina sessão ou elimina a respetiva conta no dispositivo antigo?
A app tem de eliminar ativamente a chave de restauro. Se a app for desinstalada, a chave de restauro é eliminada automaticamente.
O que faço com os utilizadores num modo convidado?
O requisito aplica-se apenas à parte autenticada da sua app. Se um utilizador era um convidado no dispositivo antigo, a app deve ser iniciada no modo convidado no novo dispositivo.
O que devo fazer com os utilizadores que usam várias contas no mesmo dispositivo?
Para cumprir o requisito, a sua app deve armazenar a chave de restauro da conta de utilizador atualmente ativa (ou da última conta ativa) no dispositivo de origem. Pode saber mais na documentação sobre a API Restore Credentials.
Posso enviar notificações para utilizadores restaurados sem que estes tenham de conceder novamente autorizações de notificações?
Sim. Os serviços de cópia de segurança e restauro tratam do restauro das autorizações das apps, incluindo as autorizações de notificações, do dispositivo anterior. Isto permite-lhe enviar notificações genéricas. Além disso, quando combinada com a API Restore Credentials, pode voltar a interagir com os utilizadores com notificações personalizadas no novo dispositivo sem que o utilizador tenha de abrir a app primeiro.
Outros
Estes requisitos são opcionais?
Todos os requisitos publicados nesta página não são opcionais. O não cumprimento de um requisito pode afetar a visibilidade e as capacidades de publicação de uma app no Google Play.
Recursos úteis
Otimização de código
- Ative a otimização de apps com o R8 | Qualidade da app | Programadores Android
- Use o R8 no modo completo | Qualidade da app | Programadores Android
- Use o analisador de configuração do R8 | Qualidade da app | Programadores Android
Utilização de memória (RSS anónimo + espaço de memória)
Utilização de memória do mapa de bits
Restaurar credenciais
- Compreender a API Restore Credentials
- Guias oficiais: implemente a API Restore Credentials
- Materiais de teste: teste a API Restore Credentials no Android Studio
- Caso prático de impacto no mundo real: como a Uber reduziu os inícios de sessão manuais em 4 milhões por ano
Competências
As competências são instruções e recursos modulares otimizados pela IA que ajudam os LLMs a compreender e executar melhor padrões específicos que seguem as práticas recomendadas e as orientações sobre programação Android em developer.android.com. Pode usá-las através da Android CLI ou de outras ferramentas baseadas em LLMs.
- Competência de análise do R8: analisa a configuração do R8 e as regras de manutenção de uma app
- Competências de IA do Perfetto: use para interpretar as capturas da área dinâmica para dados e receber sugestões acionáveis para melhorar o desempenho da memória
- Competência do Android Profiler: use para interpretar capturas da área dinâmica para dados e rastreios e receber sugestões acionáveis para melhorar o desempenho da memória
- Competência da API Restore Credentials: use para receber ajuda na integração e no teste da configuração do restauro de credenciais
Requisitos atuais
Os requisitos técnicos existentes do Google Play incluem limites de comportamento incorreto num conjunto de métricas essenciais do Android vitals, bem como requisitos relacionados com o pacote de apps que carrega na Play Console.
Métricas essenciais do Android vitals e estabilidade
O Google Play monitoriza as métricas de desempenho essenciais para garantir que as apps cumprem os padrões de estabilidade. Exceder estes limites pode afetar a visibilidade da sua app na Google Play Store.
- Taxa de falhas observadas pelo utilizador: limite de 1,09% no geral (média entre dispositivos), 8% por modelo de telemóvel e 4% por modelo de relógio. Saiba mais
- Taxa de erros ANR observados pelo utilizador: limite de 0,47% no geral (média entre dispositivos), 8% por modelo de telemóvel e 5% por modelo de relógio. Saiba mais
- Wake locks parciais excessivos: limite de 5% no geral (média entre dispositivos). Manter o dispositivo ativo consome bateria desnecessariamente. Certifique-se de que usa os wake locks corretamente e considere usar o WorkManager para tarefas em segundo plano. Saiba mais
- Utilização excessiva da bateria: limite de 1% por modelo de relógio. Saiba mais
Requisitos técnicos
O Google Play é compatível com uma vasta gama de dispositivos com várias configurações e arquiteturas de hardware. Algumas arquiteturas são fundamentais para o futuro do Android e, como tal, os novos pacotes de apps carregados para a Play Console têm de ser compatíveis com as mesmas para garantir que podemos oferecer as experiências da sua app.
- Compatibilidade com 64 bits: as apps que contêm código nativo têm de ser compatíveis com arquiteturas apenas de 64 bits. Saiba mais
- Compatibilidade com o tamanho de página de memória de 16 KB: as apps que contêm código nativo têm de ser compatíveis com dispositivos com tamanhos de página de memória de 16 KB. As apps apenas Java/Kotlin são compatíveis por predefinição. Saiba mais
- Compatibilidade com tamanho de página de memória de 16 KB e 64 bits do Wear OS: obrigatória a partir de 15 de setembro de 2026. Saiba mais
- Compatibilidade com tamanho de página de memória de 16 KB e 64 bits para TV: obrigatória a partir de 1 de agosto de 2026. Saiba mais