Resposta rápida
O Google Play aplica a um jogo Android o mesmo pré-requisito de teste fechado para o acesso de produção que aplica a qualquer outro app. Se o jogo for publicado por uma conta pessoal de desenvolvedor criada depois de 13 de novembro de 2023, pelo menos 12 testadores precisam estar participando de um teste fechado durante os últimos 14 dias contínuos, no mínimo, antes de você poder solicitar o acesso de produção. No começo o Google exigia 20 testadores e reduziu o mínimo para 12 em 11 de dezembro de 2024; a documentação atual não traz nenhuma contagem de testadores, duração ou isenção específica para jogos. Bater o número não é aprovação, porque o Google também pergunta como os testadores usaram o jogo, que feedback deram e o que você mudou, e ele pode exigir mais testes. Os jogos ainda carregam riscos de lançamento que esse contador nunca mede: entrega de assets, tempo de frame, código nativo de 64 bits, teste de compras no app e autorização do Play Games Services. Se a parte dos testadores é a que você não consegue montar, a PrimeTestLab cuida dela com testadores reais em dispositivos reais.
Também valendo agora para quem publica jogos
31 de agosto de 2026 já passou: os jogos novos e atualizados para celular precisam ter como alvo o Android 16 (nível de API 36) ou posterior, e o Play Billing Library 7 já passou do prazo para apps novos e para atualizações. Envios para Wear OS e Android Automotive OS precisam da API 35, e Android TV e Android XR precisam da API 34. Se você tem uma extensão, ela vale até 1º de novembro de 2026. Nenhum dos dois faz parte da exigência de testadores, e os dois podem bloquear o lançamento que essa exigência deveria destravar.
A maioria dos guias existentes responde só metade deste problema. As páginas gerais sobre teste fechado explicam a exigência de 12 testadores sem tocar nos riscos de lançamento próprios de um jogo, enquanto as páginas de QA de jogos falam de desempenho e laboratórios de dispositivos sem explicar o portão do acesso de produção, que é o que está travando o lançamento de verdade. As threads da comunidade preenchem o espaço entre umas e outras com folclore dito com muita convicção: jogar uma vez por dia, publicar três atualizações, trinta minutos por sessão, um número mínimo de fases. Nada disso é regra publicada pelo Google, e este post diz isso toda vez que uma dessas ideias aparece. Tudo aqui está atualizado até 12 de agosto de 2026, com as datas-limite de política reverificadas em 14 de agosto de 2026, e tudo rastreado até a documentação primária do Google; quando a resposta honesta é "o Google não publica isso", a página escreve exatamente isso em vez de inventar um número.
A ordem abaixo segue o jeito como o problema se resolve na prática. Primeiro o portão em si, porque não dá para planejar nada enquanto você não sabe se ele se aplica a você e o que exatamente ele conta. Depois a camada com formato de jogo: o que um teste que só acumula contas participando deixa passar, e como testar cada um desses riscos antes que os revisores do Google vejam o resultado.
A bancada
Três instrumentos feitos para as três perguntas que um desenvolvedor de jogos não consegue responder só com a documentação do Google. Cada um roda inteiramente no seu navegador, em cima dos valores que você digitar. Nada é enviado para lugar nenhum e não precisa de conta.
Índice
O Google Play exige teste fechado para jogos Android?
Sim, nos mesmos termos de qualquer outro app. Se o jogo for publicado por uma conta pessoal de desenvolvedor criada depois de 13 de novembro de 2023, você precisa rodar um teste fechado com pelo menos 12 testadores participando continuamente nos últimos 14 dias antes de poder solicitar o acesso de produção. O Google não publica nenhuma contagem de testadores diferente, nenhuma duração menor e nenhuma isenção para jogos.
"Se você tiver uma conta de desenvolvedor pessoal recém-criada, é necessário realizar um teste fechado para o app com no mínimo 12 testadores que participaram continuamente pelo menos nos últimos 14 dias."
Central de Ajuda do Play Console, resposta 14151465
Leia essa frase pelo que ela não diz. Ela não menciona categorias de app. O gatilho está preso à conta, não ao que você sobe, então o fato de o seu bundle estar categorizado como jogo não muda nada sobre o portão se aplicar ou não. O próprio material do Google sobre teste fechado trata apps e jogos dentro do mesmo processo de acesso de produção, e cita explicitamente o teste pré-lançamento de jogos para celular como um uso das faixas de teste.
Leia mais uma vez, agora atrás da expressão seu app. A data de criação da conta decide se a exigência se aplica a você, mas o teste que qualifica e a solicitação de acesso de produção são concluídos para um app individual. Cumprir o processo para um jogo não vale para o próximo pacote que você publicar pela mesma conta: um segundo jogo ganha o próprio teste fechado, os próprios 12 testadores e a própria quinzena. Essa conclusão se apoia no fato de o Google escrever a condição em cima de "seu app" e de o acesso de produção ser solicitado por pacote, e não em uma frase publicada descartando o aproveitamento; planeje um teste novo por jogo e confira o painel do Console para aquele app específico antes de supor uma coisa ou outra.
Achado negativo "Não existe isenção para jogos" é uma conclusão tirada da ausência dela na documentação atual do Google, não uma frase que o Google publique. Essa distinção importa, e este post a mantém: nenhuma contagem de testadores nem duração alternativa para jogos foi encontrada em lugar nenhum do material atual sobre acesso de produção, então a leitura segura é que as contas pessoais afetadas usam o mesmo pré-requisito, seja o que for que estejam publicando.
O que a regra de fato conta
12
Testadores, mínimoContas individuais que concluíram o aceite. Não são as pessoas para quem você mandou e-mail, nem as que disseram sim.
14
Dias contínuosCada uma dessas 12 contas precisa ter ficado participando durante todos os últimos 14 dias no momento em que você solicita.
1
Escopo da conta, teste do appA conta decide se a regra se aplica. O teste que qualifica, esse é rodado por app.
Se você leu em algum lugar que o número é 20, aquela página está desatualizada. No começo o Google fixou o limite em 20 testadores e reduziu para 12 em 11 de dezembro de 2024, descrevendo a mudança com as próprias palavras como exigir "12 em vez de 20 testadores", mantendo intacto o período de duas semanas. O histórico está detalhado no post sobre a mudança de 20 para 12 testadores, e a mecânica da exigência em si, no post sobre o requisito dos 12 testadores. Este post parte dos dois e fica no que um jogo tem de diferente.
Quais desenvolvedores de jogos realmente precisam de 12 testadores?
O pré-requisito vale para contas pessoais de desenvolvedor criadas após 13 de novembro de 2023. Contas organizacionais e contas pessoais mais antigas estão fora desse requisito específico. Enviar um jogo em vez de um app não coloca nem tira você dele, e rodar um teste interno com até 100 pessoas não o cumpre.
| Sua situação | 12 testadores, 14 dias? | A explicação segura |
|---|---|---|
| Conta pessoal criada após 13 nov. 2023 | Sim | Rode um teste fechado com pelo menos 12 testadores participando continuamente nos últimos 14 dias e depois solicite o acesso de produção. |
| Conta pessoal criada antes desse corte | Não por esta regra | O Google limita o requisito às contas pessoais criadas após 13 de novembro de 2023. |
| Conta organizacional | Não por esta regra | O requisito foi escrito expressamente para as contas pessoais que se enquadram. Isso não é o mesmo que estar isento de testes, de qualidade ou da análise de políticas. |
| Um jogo em vez de um app comum | Sem caso especial | Não existe, na documentação atual do Google sobre o acesso de produção, nenhuma contagem de testadores ou duração alternativa para jogos. |
| Você já rodou um teste interno com 100 pessoas | Ainda é obrigatório | Teste interno e teste fechado são faixas separadas. O pré-requisito exige especificamente um teste fechado. |
| Você já cumpriu isso para outro jogo na mesma conta | Ainda é obrigatório | O Google escreve o requisito como um teste fechado "para o seu app". A conta decide se a regra se aplica; o teste que qualifica é concluído por pacote. |
"Contas organizacionais estão isentas" é a frase errada
Uma conta organizacional fica fora desse pré-requisito específico das novas contas pessoais. Ela continua sujeita a todas as obrigações normais: análise, política de conteúdo, padrões de qualidade, declarações e regras de distribuição. Registrar-se como organização para escapar de um requisito de testadores também significa assumir a verificação de organização, e o tipo de conta que você escolhe tem consequências muito além desse portão. Os prós e contras estão detalhados no post sobre conta pessoal versus conta organizacional.
Um contexto geral de conta, porque ele vem sempre na mesma frase e costuma ser confundido com o custo dos testes: o Google cobra uma taxa de registro única de US$ 25 para abrir uma conta de desenvolvedor. Essa taxa não tem relação com o requisito de testes. Nada em rodar um teste fechado custa dinheiro no Play Console; o que custa é encontrar doze pessoas que fiquem.
E esse é o problema de verdade para um jogo. Em comparação com um app utilitário, um jogo costuma precisar de sessões mais profundas antes que seus defeitos sequer apareçam: progressão e estado salvo, entrega de assets, comportamento térmico e monetização só se comportam mal depois que alguém jogou o bastante para ter algo a perder. Nenhuma das duas categorias é bem testada por pessoas que instalam um build e o deixam parado por duas semanas, e o Google pesa engajamento e feedback tanto para apps quanto para jogos. O jogo só torna a versão rasa desse erro mais cara, porque você precisa de pessoas que realmente joguem, em hardware parecido com o de um jogador, por tempo suficiente para chegar ao segundo ato. É dessa lacuna que o resto deste post trata.
Como funciona o teste fechado de 14 dias para um jogo?
Publique uma versão na faixa fechada, leve pelo menos 12 testadores até o fim do processo de participação e mantenha essas pessoas no teste enquanto jogam de verdade. Na hora de solicitar, pelo menos 12 delas precisam ter ficado participando pelos últimos 14 dias contínuos, cada uma. Depois, solicite a produção pelo painel do Play Console. O teste interno aceita até 100 testadores e é útil, mas não cumpre esta etapa.
Fonte: a exigência de teste fechado para novas contas pessoais (resposta 14151465). O mínimo de 12 testadores substituiu os 20 em 11 de dezembro de 2024; o período contínuo de 14 dias não mudou.
-
01
Antes do dia um
Publique a versão do teste fechado e disponibilize para os seus testadores. Confirme que o build entregue pelo Play instala e roda, que os pacotes de assets chegam, que o login do Play Games funciona e que tudo o que o teste precisa alcançar está acessível. Um build que funciona a partir da sua máquina não prova nada sobre o build que o Play monta.
-
02
Aceitar participar
Cada testador precisa aceitar o convite, não apenas aparecer numa lista. Isso derruba gente o tempo todo: colocar alguém numa lista de e-mails ou num Grupo do Google é uma ação sua; aceitar participar é uma ação dela. Conte apenas as contas que concluíram esse aceite.
-
03
Do dia um ao dia quatorze
Pelo menos 12 testadores continuam participando sem interrupção enquanto jogam. Recrute acima do mínimo para que uma única saída não te deixe abaixo da conta. O Google pergunta sobre engajamento e feedback quando você solicita, então o resultado útil desta quinzena é uma lista de coisas que as pessoas te disseram, não um print de um contador.
-
04
Durante o teste
Corrija defeitos reais e continue atualizando o build. Subir novas versões durante a janela é normal e não reinicia nada: a condição que qualifica é escrita em cima do histórico de participação de cada testador, não da idade de um build congelado. Isso decorre do texto do Google sobre participação contínua por testador; o Google não publica nenhuma regra separada sobre atualizações de build, nem a favor nem contra. Exercite os caminhos de instalação e atualização, progressão e saves, download de assets, crashes, desempenho, compras e Play Games conforme o seu jogo usa cada um deles.
-
05
Depois da janela que qualifica
Vá em Dashboard > Apply for production e responda com honestidade quem testou, como essas pessoas usaram o jogo, o que você mudou e por que o jogo está pronto.
-
06
Análise
O Google diz que isso costuma levar 7 dias ou menos e que, de vez em quando, pode demorar mais. Não é um acordo de nível de serviço, e ninguém pode te prometer uma data.
Uma correção que vale fazer cedo, porque ela custa uma quinzena a muita gente. O teste interno é outra faixa, com um teto bem mais alto: até 100 testadores, disponível rapidinho. Ele é realmente útil para colocar um build na mão das pessoas rápido. Mas não substitui o teste fechado que o pré-requisito cita. As diferenças entre as três faixas estão no post sobre teste interno, fechado e aberto, e o teste aberto só fica disponível depois que você tem o acesso de produção.
Os testadores precisam jogar todo dia?
É aqui que quase toda resposta de comunidade erra, então seguem as três categorias bem separadas.
Exigido e publicado
- Pelo menos 12 testadores participando.
- Participando pelos últimos 14 dias contínuos.
- Um teste fechado, especificamente, não interno.
- Respostas honestas na solicitação de acesso de produção.
Boa prática, não regra
- Testadores que de fato chegam ao core loop, não só à tela de título.
- Sessões longas o bastante para o calor e a pressão de memória aparecerem.
- Feedback por escrito que você possa citar na hora de solicitar.
- Correções publicadas durante a janela, quando o feedback justifica.
Não é regra publicada
- Abrir o jogo uma vez por dia.
- Um número mínimo de minutos por sessão.
- Um número obrigatório de builds durante o teste.
- Um número mínimo de fases, telas ou mecânicas.
O Google exige participação contínua e diz que o engajamento pesa quando ele analisa a sua solicitação. Ele não publica cota de aberturas por dia, número de minutos por sessão nem contagem de atualizações. Encare a coluna da direita pelo que ela é: conselho que virou folclore de tanto ser repetido com convicção. Mire em teste de verdade e você atende a coluna do meio sem precisar da terceira.
Se um testador sai, a quinzena recomeça?
Por si só, não, e essa é a regra mais exagerada que circula por aí. A condição do Google é medida no momento em que você solicita: pelo menos 12 testadores, cada um deles participando pelos 14 dias anteriores sem interrupção. Não é uma exigência de que um grupo intocado de exatamente doze pessoas atravesse a quinzena sem nenhuma mudança.
Ou seja, a conta é por testador, não por turma. Comece com exatamente 12 e perca um no dia nove: você fica curto, porque sobram onze contas capazes de mostrar a janela inteira, e o décimo segundo, que entrou no lugar, precisa cumprir os próprios 14 dias contínuos antes de você solicitar. Comece com quinze e perca um: os quatorze restantes ainda podem satisfazer a condição, cada um deles, e você só perdeu folga. Esse é o argumento inteiro para recrutar acima do mínimo em vez de exatamente no mínimo.
Como sabemos disso Esta leitura decorre do próprio texto do Google sobre participação contínua por testador, que é a base em que o requisito está escrito. O Google não publica nenhuma regra separada de reinício de turma dizendo com todas as letras que a saída de um testador preserva o período de todos os outros, então trate isto como uma leitura cuidadosa da condição publicada, e não como uma frase que você possa citar para um revisor. O conselho prático não muda de um jeito nem de outro: recrute acima de 12 para que a pergunta nunca precise ser respondida.
O que acontece depois do dia 14?
Você solicita, e o Google lê as respostas. A solicitação de acesso de produção pergunta como os testadores usaram o jogo, que feedback deram, o que você mudou por causa disso e por que você considera o jogo pronto. Para um jogo existe ainda um pedido específico da categoria: descrever o que faz ele se destacar. Essa pergunta também não é formalidade: é onde um jogo que funciona bem, mas não tem nada a dizer sobre si mesmo, começa a parecer um jogo que ninguém testou a sério.
Escreva as respostas durante o teste, não depois dele
As perguntas são sobre coisas que aconteceram ao longo de quatorze dias. Se você deixar para pensar nelas no dia quinze, vai reconstruir tudo de memória, e dá para perceber isso na leitura. Mantenha uma anotação corrida do que os testadores relataram e do que você publicou em resposta; aí a solicitação leva vinte minutos e diz algo verdadeiro. Tem um passo a passo completo do formulário no post sobre o formulário de acesso de produção.
O que um teste genérico de app deixa passar em um jogo?
Um teste montado em torno de "instale e continue participando" mede o contador e nada mais. Jogos sustentam carga contínua de CPU e GPU, entregam grandes volumes de assets por um sistema de distribuição com modos de falha próprios, normalmente carregam binários nativos, guardam o estado de progressão entre sessões e muitas vezes recebem dinheiro. Cada um desses pontos é um lugar onde a versão passa na sua mesa e falha no celular do jogador.
Nenhum desses riscos é exclusivo de jogos, e este post não afirma o contrário: muitos apps comuns carregam bibliotecas nativas, vendem assinaturas ou entregam assets grandes. O que é distintivo é a concentração. Um jogo normalmente encontra a maior parte dessa lista de uma vez, na mesma versão, durante as mesmas duas semanas, e é por isso que um checklist escrito para um app genérico deixa tanta coisa de um jogo sem teste.
Abaixo está o mapa do resto deste post. A coluna da direita é a parte que as pessoas erram nos dois sentidos: algumas dessas coisas são requisitos do Google com consequências, e outras são prática comum de qualidade que nenhuma política menciona. Tratar uma prática como regra desperdiça suas duas semanas, e tratar uma regra como prática custa o seu lançamento.
| Área de risco | Por que um jogo é diferente | Status |
|---|---|---|
| Entrega de assets e tamanho | Grandes volumes divididos em pacotes install-time, fast-follow e on-demand, cada um com limites próprios e um jeito próprio de chegar atrasado ou não chegar. | Limites do Google |
| Tempo de frame e calor | A carga contínua de renderização esquenta o dispositivo, o sistema reduz o desempenho e os tempos de frame sobem no sexto minuto de uma sessão que parecia bem no primeiro. | Métrica do vitals |
| Código nativo e 64 bits | Engines e plugins entregam binários compilados. Falta de cobertura de 64 bits ou uma ABI errada derruba famílias inteiras de dispositivos, e não apenas um recurso. | Requisito do Google |
| Compras no app | Estar em uma faixa de teste não deixa as compras gratuitas, e uma compra de teste não confirmada some depois de três minutos. | Mecanismo do Google |
| Play Games Services | Uma segunda camada de autorização, com lista de testadores própria, que falha com erros de OAuth e 404 quando não está configurada. | Requisito do Google |
| Política de monetização e conteúdo | A divulgação das probabilidades de itens aleatórios, as mecânicas com dinheiro real e a precisão do questionário de classificação são exposições de política com cara de jogo que um app utilitário comum nunca encontra. | Política do Google |
| Progressão e estado salvo | Sair, retomar, reinstalar e trocar de dispositivo: tudo precisa preservar o progresso, e um bug de save fica invisível até alguém jogar o bastante para ter algo a perder. | Prática de QA |
| Profundidade da sessão | As falhas que importam moram além do tutorial. Um testador que abre o jogo uma vez não produz evidência nenhuma sobre nenhuma das linhas acima. | Prática de QA |
Repare no que não está nessa tabela: um número exigido de dispositivos, uma duração exigida de sessão, uma taxa de frames exigida ou uma contagem mínima de fases. Essas coisas são afirmadas o tempo todo e nenhuma delas é publicada. O que o Google publica são limites, limiares, mecanismos e políticas, e cada um deles é testável durante as mesmas duas semanas que você já está gastando com o contador.
Qual é o tamanho máximo do seu jogo no Google Play?
Em 12 de agosto de 2026, a Ajuda do Play Console lista 500 MB de módulo base, 500 MB por módulo de recursos, 1,5 GB por pacote de assets, 4 GB para todos os módulos mais os pacotes de assets install-time, 30 GB para os pacotes fast-follow e on-demand e um máximo total de 34 GB. Cada um desses valores é um tamanho de download compactado calculado pelo Play Console, não o tamanho do .aab que está no seu disco.
Este é o dado com maior chance de estar errado no que você leu antes de chegar aqui. O número de 200 MB que ainda circula era o limite base anos atrás, e algumas das próprias páginas antigas do Google sobre jogos Android não acompanharam a página da Ajuda do Play Console que governa os envios de verdade. Quando duas páginas do Google se contradizem, a página dedicada aos limites de tamanho na Ajuda do Play Console é a específica e a atual para o que o Console vai aceitar. Confira de novo antes de planejar um lançamento em cima de qualquer número abaixo.
Instrumento 01
Medidor de orçamento do build
Informe os tamanhos de download compactado em megabytes. Tudo roda nesta página; nada é enviado. Esta calculadora usa 1 GB = 1024 MB.
Limites conferidos na Ajuda do Play Console em 12 de agosto de 2026. O Google calcula esses valores a partir do tamanho de download compactado que ele deriva do seu bundle, então o tamanho do arquivo na sua máquina é só uma aproximação do que será medido. Fontes: limites máximos de tamanho de app (resposta 9859372) e Play Asset Delivery.
A tabela completa de limites
| Componente | Limite atual | A que se aplica |
|---|---|---|
| Módulo base | 500 MB | O módulo base do bundle sozinho. |
| Módulo de recursos | 500 MB | Cada módulo de recursos individual, medido separadamente. |
| Pacote de assets | 1,5 GB | Cada pacote de assets individual, medido separadamente. |
| Módulos mais pacotes install-time | 4 GB | Total acumulado de tudo o que é entregue durante a instalação. |
| Pacotes fast-follow mais on-demand | 30 GB | Total acumulado de tudo o que é entregue depois da instalação. |
| Download total | 34 GB | Tamanho máximo geral de download compactado. |
| Pacotes de assets por bundle | 100 | Número máximo de pacotes de assets em um app bundle. |
| Apps acima de 1 GB | minSdk 21 | Qualquer coisa maior que 1 GB precisa ter como alvo pelo menos o Android 5.0 Lollipop. |
| Aviso de dados móveis | 200 MB | Acima disso, instalações por dados móveis mostram uma caixa de diálogo de tamanho grande que não bloqueia. |
| APK legado | 100 MB | Máximo para um único APK na publicação legada por APK. |
Limites de tamanho do Google Play conferidos em 12 de agosto de 2026. Todos os valores são tamanhos de download compactado calculados pelo Play Console. Fontes: limites máximos de tamanho de app (resposta 9859372) e Play Asset Delivery.
Qual modo do Play Asset Delivery o seu jogo deve testar?
O Play Asset Delivery tem três modos, e cada um falha em um lugar diferente. O modo que você escolheu no build determina quais casos de teste são os que importam, então percorra esta tabela e teste só as linhas que seu jogo realmente usa.
| Modo | Quando chega | Pronto no lançamento? | No tamanho exibido na loja? | O caso de teste que encontra bugs |
|---|---|---|---|---|
| Install-time | Entregue durante a instalação como split APKs. | Sim | Sim | A primeira abertura, o caminho de atualização e a instalação com o dispositivo quase sem armazenamento. |
| Fast-follow | Baixa automaticamente logo depois da instalação, sem bloquear a entrada no jogo. | Não necessariamente | Não | Um jogador que abre o jogo antes de o pacote terminar, e a recuperação de um download interrompido. |
| On-demand | Baixado com o jogo rodando, quando o seu código pede. | Só depois de solicitado | Não | Entrar na fase ou no recurso antes de o pacote dele estar disponível, além de novas tentativas e interrupções. |
Não presuma que os pacotes ficam onde você deixou
O Google avisa que os arquivos fast-follow e on-demand podem ser apagados pelo usuário ou movidos pela biblioteca do Play Asset Delivery entre sessões, então um jogo não pode supor que um pacote que existia ontem continua no mesmo lugar hoje. Teste a segunda e a terceira abertura, não só a primeira, e teste o que acontece quando uma atualização invalida um pacote. A segmentação por formato de compactação de textura acrescenta outra dimensão: o Play pode entregar assets de textura diferentes conforme o que o dispositivo suporta, então os assets que o seu dispositivo de teste recebe podem não ser os que outro dispositivo recebe.
O teste local de entrega de assets não reproduz exatamente a entrega feita pelo Play. O Google documenta que, em um teste local, um pacote fast-follow se comporta como um pacote on-demand, e que certos comportamentos de rede e de espera por Wi-Fi não podem ser reproduzidos localmente de jeito nenhum. Esse é o argumento para testar o build que o Play realmente entrega a um testador da faixa fechada, em vez do build que o seu editor gera, e é um dos poucos pontos em que o teste fechado está de fato fazendo trabalho de QA, e não apenas satisfazendo um contador.
Quais números de taxa de frames e de falhas o Google realmente publica?
O Android vitals publica um limite de taxa de falhas percebidas pelo usuário de 1,09% no geral e 8% por modelo de celular, e uma taxa de ANR percebidas pelo usuário de 0,47% no geral e 8% por modelo de celular. Para jogos, especificamente, ele define uma Sessão lenta como aquela em que mais de 25% dos frames são lentos, medidos contra 50 ms (20 FPS) como métrica principal e 34 ms (cerca de 30 FPS) como secundária. Nenhum desses números é um limite de aprovação publicado para o teste fechado.
A distinção importa porque ela se perde o tempo todo. Os limites do vitals descrevem qualidade técnica, e o Google já disse que, no devido tempo, o Play vai afastar os usuários dos jogos que não conseguem chegar a 20 FPS no celular deles. Isso é um mecanismo de descoberta e de qualidade. Não é a análise do acesso de produção, e nenhuma fonte do Google transforma uma taxa de frames em nota de corte do teste de 14 dias. As duas coisas podem ser verdade ao mesmo tempo: seu jogo pode passar pelo portão dos testadores e ainda assim ser um jogo que o Play vai deixar de recomendar em silêncio.
Instrumento 02
Laboratório de sessão lenta
Quarenta frames de uma sessão de jogo. Mova o controle deslizante para dizer quantos deles foram renderizados lentamente, e o laboratório aplica a definição do Google ao resultado.
O Android vitals só começa a monitorar a taxa de frames de um jogo depois que ele roda por 1 minuto, e é também por isso que um testador que abre o jogo e fecha em seguida não gera nenhum sinal útil de desempenho. Um minuto é o ponto de partida da medição, não a duração exigida para uma sessão de jogo humana. Fonte: Sessões lentas no Android vitals.
Os números, e o que cada um não é
| Métrica | Valor do Google | O que significa | O que não significa |
|---|---|---|---|
| Taxa de falhas percebidas pelo usuário | 1.09% | Limite de qualidade técnica do Android vitals, medido no geral. | Não é nenhum tipo de limite do teste fechado. |
| Taxa de falhas por modelo de celular | 8% | O limite do vitals específico por dispositivo. | Não é permissão para tolerar 8% de falhas no seu próprio QA. |
| Taxa de ANR percebidas pelo usuário | 0.47% | Limite de qualidade técnica do Android vitals, medido no geral. | Não faz parte da fórmula do acesso de produção. |
| Taxa de ANR por modelo de celular | 8% | O limite do vitals específico por dispositivo. | Não é uma meta a ser perseguida no design. |
| Sessão lenta | >25% de frames lentos | A definição de qualidade de frames exclusiva de jogos. | Não é uma medida do engajamento dos testadores. |
| Frame lento, principal | 50 ms, 20 FPS | O tempo de referência principal das Sessões lentas. | Não é um FPS mínimo publicado para o acesso de produção. |
| Frame lento, secundário | 34 ms, cerca de 30 FPS | Uma métrica adicional das Sessões lentas que o vitals informa. | Não é prova de que o Google exige que todo jogo rode a 30 FPS. |
| Início do monitoramento | Depois de 1 minuto | A coleta da taxa de frames começa depois que o jogo roda por um minuto. | Não é a duração que o Google exige de uma sessão de jogo humana. |
O bug que só aparece no sexto minuto
O Google lista o superaquecimento e o throttling térmico entre as causas documentadas de frames lentos: a carga contínua de CPU e GPU esquenta o dispositivo, o sistema reduz o desempenho e os tempos de frame sobem. Esse modo de falha é invisível em um smoke test de dois minutos e evidente em uma sessão de vinte minutos com o celular quente. É também o exemplo mais claro de por que um jogo precisa de testadores que realmente joguem, e não de testadores que apenas instalam. Se você estiver fazendo profiling disso, o Android Dynamic Performance Framework (ADPF) expõe sinais de gerenciamento térmico, de CPU e de GPU exatamente para esse fim, para que o jogo possa se adaptar antes que o throttling fique severo.
Bibliotecas nativas e 64 bits
Jogos feitos em Unity, Unreal, Cocos ou em qualquer engine com plugins nativos carregam binários compilados, e esses binários têm regras de compatibilidade próprias, independentes de tudo o que está neste post. O Google Play exige que os apps sejam compatíveis com arquiteturas de 64 bits: quando há suporte a uma arquitetura nativa de 32 bits, a arquitetura de 64 bits correspondente também precisa ser incluída. Teste em um ambiente de 64 bits e trate cada plugin de terceiros como capaz de embarcar o próprio binário incompatível, não importa o que a versão da sua engine afirme.
Se, no meio desse trabalho, sua versão também disparar o aviso de tamanho de página de memória de 16 KB, esse é um requisito separado, com prazo próprio e caminho de correção próprio, tratado no post sobre como corrigir o erro de página de 16 KB.
Não é uma regra publicada Não existe número publicado pelo Google de dispositivos, versões do Android ou famílias de GPU em que um jogo precise ser testado para conseguir o acesso de produção. Quem cita "cinco celulares e três versões do Android" está citando uma preferência, não uma política. Cubra o conjunto de dispositivos que seu jogo realmente suporta, com peso para o hardware que seu público provavelmente tem em mãos, e lembre que emuladores não dizem nada de útil sobre comportamento térmico.
Como testar compras no app sem cobrar dos testadores?
Adicione em Settings > License testing, no Play Console, todas as contas que vão fazer compras de teste. Estar na sua faixa fechada não deixa as compras gratuitas. Um testador comum que tocar em Comprar no seu jogo ainda não lançado pode ser cobrado de verdade, e a única coisa que muda isso é o status de testador de licença na conta que faz a compra.
"Os usuários arcam com cobranças reais ... a menos que o usuário seja um testador de licença."
Google Play Billing, documentação sobre testar o faturamento no app
São duas listas separadas controlando duas coisas separadas. A lista de testadores da faixa fechada controla quem pode instalar o build ainda não lançado. A lista de testadores de licença controla de quem as compras passam pelos métodos de pagamento de teste do Google em vez de um cartão real. Quem adiciona doze pessoas na primeira lista e nenhuma na segunda montou um teste em que toda compra é real, e a primeira pessoa a descobrir isso costuma ser um testador pedindo reembolso.
Instrumento 03
Verificador de cobrança do testador
Responda pensando no aparelho e na conta específicos que estão prestes a fazer a compra. O veredito muda a cada conta, não a cada build.
Testador da faixa fechada x testador de licença
| Situação | Na faixa fechada? | Testador de licença? | O que acontece quando compram |
|---|---|---|---|
| Um testador convidado comum | Sim | Não | Consegue instalar o build não lançado, e as compras podem ser transações cobradas de verdade. |
| Um testador de licença que também está na faixa | Sim | Sim | Instala o build fechado e recebe os métodos de pagamento de teste do Google. |
| Um testador de licença com um build local de pacote correspondente | Não necessariamente | Sim | O Google permite que testadores de licença testem o faturamento sem a exigência normal de build enviado e assinado, desde que as condições de pacote e de conta sejam atendidas. |
| Um aparelho com várias contas do Google | Tanto faz | Depende da conta | A compra normalmente usa a conta que baixou o app; se nenhuma baixou, o Google usa a primeira conta. |
| Uma compra de teste que nunca é confirmada | Tanto faz | Sim | Estornada automaticamente depois de 3 minutos no ambiente de teste acelerado. |
Os testes de compra que um jogo monetizado deve rodar
| Teste | Mecanismo | Comportamento esperado |
|---|---|---|
| Compra de consumível bem-sucedida | O instrumento de teste que sempre aprova. | Item concedido e depois confirmado ou consumido corretamente. |
| Compra recusada | O instrumento de teste que sempre recusa. | Nenhum item concedido e nenhum estado parcial deixado para trás. |
| Consumível repetido | Comprar o mesmo consumível de novo. | A segunda e a terceira compras funcionam exatamente como a primeira. |
| Não consumível | Uma compra de teste bem-sucedida. | Concedido uma vez, com a recompra indesejada bloqueada. |
| Pendente que depois é aprovada | O método de teste que aprova com atraso. | Nada concedido até o estado virar comprado, e então concedido uma vez só. |
| Pendente que falha | O método de teste que recusa com atraso. | O direito de acesso nunca é concedido em momento nenhum. |
| Reinício no meio da compra | Fechar e reabrir o jogo durante um estado pendente. | O estado do direito de acesso se reconcilia corretamente na reabertura. |
| Confirmação | Uma compra bem-sucedida deixada parada. | Sobrevive além dos 3 minutos, em vez de ser estornada automaticamente. |
| Conta errada | Um aparelho com várias contas do Google conectadas. | A conta de faturamento é o testador de licença que você queria. |
Antes de qualquer coisa disso funcionar
O teste de licença fica em Settings > License testing, no Play Console, e a lista de e-mails de lá aceita até 2.000 endereços, enquanto um Grupo do Google pode ser usado sem esse limite de lista de usuários. Os seus produtos avulsos e as suas assinaturas também precisam estar configurados e publicados conforme exigido antes de poderem ser testados direito: um produto não publicado gera falhas que parecem bugs de faturamento e, na verdade, são lacunas de configuração.
Prazos da biblioteca de faturamento: a Play Billing Library 7 passou do prazo para apps novos e atualizações em 31 de agosto de 2026. Se você tem uma extensão, ela vale até 1º de novembro de 2026; fora isso, as novas versões precisam de uma versão posterior compatível. Ser a versão mais nova não é a mesma coisa que ser a versão mínima permitida, então mire em uma versão compatível e mantida, em vez de supor que a mais recente é obrigatória. Fonte: Testar o faturamento no app, incluindo testadores de licença.
As loot boxes tornam seu jogo um app de jogos de azar?
Não. O Google separa os itens virtuais aleatórios comprados dos jogos de azar com dinheiro real. Se os jogadores gastam dinheiro ou valor comprado em itens virtuais aleatórios como as loot boxes, você precisa divulgar claramente as probabilidades antes da compra e perto dela. Pagar por uma chance de ganhar um prêmio do mundo real é outro regime de política, com regras próprias de elegibilidade e licenciamento.
| Sua mecânica | Qual política ela envolve | O que você precisa fazer |
|---|---|---|
| O jogador compra um item virtual conhecido e fixo | Regras comuns de compra digital. | Teste a compra direito e siga as regras de faturamento do Play aplicáveis. Nada de especial. |
| O jogador gasta dinheiro ou valor por um item virtual aleatório | A política de itens aleatórios, que cita as loot boxes explicitamente. | Divulgue as probabilidades antes da compra e perto dela, onde o jogador realmente consiga vê-las. |
| O jogo retrata jogos de azar simulados | Classificação de conteúdo. | Responda ao questionário de classificação com precisão. A classificação resultante depende da autoridade e do questionário aplicáveis. |
| O jogador paga por uma chance de ganhar um prêmio do mundo real | A política separada de jogos de azar, jogos e concursos com dinheiro real. | Trate como categoria restrita, e não como monetização comum de loot box. |
| Produto licenciado de jogos de azar com dinheiro real | Regras específicas de elegibilidade, país e licenciamento. | Fora do escopo de um conselho comum para jogos indie. Trabalhe direto com a política específica do Google sobre jogos de azar. |
O questionário de classificação de conteúdo não é formalidade
Todo jogo precisa de respostas exatas e completas no questionário de classificação de conteúdo, acessível em Policy > App content no Play Console, e precisa atualizá-las quando o conteúdo ou os recursos descritos mudam. Deturpar o que existe dentro de um jogo pode levar à remoção ou à suspensão, o que torna um questionário impreciso um erro bem mais caro do que um frame lento.
Os jogos tocam em mais partes do questionário do que os apps: violência, jogos de azar simulados, compras dentro do jogo, comunicação entre usuários, conteúdo gerado por usuários. Se o seu teste fechado ganhar um chat ou uma recompensa aleatória na segunda semana, as respostas que você deu na primeira semana ficaram erradas. Reabra o questionário antes de solicitar o acesso de produção, e não depois que alguém perceber.
Por baixo de tudo isso está a política de funcionalidade e qualidade básicas: apps e jogos precisam oferecer experiências estáveis, responsivas e suficientemente funcionais, e algo que trava, não carrega ou é praticamente não funcional pode violá-la. Não é uma regra publicada Não existe número mínimo publicado de fases, telas, mecânicas ou minutos de jogo. Um jogo curto não é um problema de política; um jogo quebrado é.
Fonte: a política de itens virtuais aleatórios do Google Play (resposta 9858738), que exige a divulgação das probabilidades antes da compra e perto dela.
Por que o login do Play Games falha durante o teste fechado?
Porque o Play Games Services tem a própria lista de testadores. Enquanto sua configuração do Play Games Services não estiver publicada, os testadores precisam ser autorizados individualmente ou por meio de uma faixa de lançamento ativada; caso contrário, diz o Google, eles vão encontrar erros de OAuth e 404. Estar na faixa fechada dá ao testador a versão do jogo. Não dá a ele a camada do Play Games.
O sintoma é característico e enganoso: o login funciona na sua máquina, funciona para você em um dispositivo, e falha para todo mundo no momento em que a versão chega pelo Play. Isso parece uma versão quebrada, o que faz o desenvolvedor sair reconstruindo algo que nunca esteve errado.
A configuração que resolve
-
01
Abra a lista de testadores do Play Games Services
No Play Console: Grow users > Play Games Services > Setup and management > Testers. Essa lista é separada da lista de testadores da sua faixa fechada e não herda nada dela.
-
02
Autorize os testadores ou ative a faixa
Adicione as contas individualmente ou ative a faixa de lançamento correspondente do Play Console para os testes do Play Games Services, de modo que todo mundo com acesso à versão de teste também receba o acesso ao Play Games. A segunda opção é a que escala além de um punhado de pessoas.
-
03
Confira se as credenciais correspondem à versão enviada
A autenticação falha quando o nome do pacote configurado ou a impressão digital do certificado de assinatura não corresponde ao que foi enviado. Com o Play App Signing no meio do caminho, a impressão digital de que sua configuração do Play Games precisa é a que o Play usa, não a que está na sua máquina.
-
04
Teste todos os recursos que você realmente ativou
Primeiro o login, depois conquistas, placares e jogos salvos, conforme seu jogo os usa. Os jogos salvos merecem atenção especial porque interagem com a progressão: um save que não restaura é um bug que seus testadores só encontram se avançarem o bastante para ter progresso que valha a pena restaurar.
| Sistema | O que ele controla | Substitui o teste fechado de 12/14? | Onde é configurado |
|---|---|---|---|
| Teste fechado | Quem pode receber o jogo ainda não lançado e, para as contas pessoais sujeitas à regra, o próprio pré-requisito do acesso de produção. | Este é o portão obrigatório. | Faixa de teste fechado do Play Console. |
| Testes do Play Games Services | Acesso a uma configuração não publicada do Play Games Services e às APIs dela. | Não | Grow users > Play Games Services > Setup and management > Testers. |
| Teste interno | Distribuição inicial rápida para até 100 testadores. | Não | Uma faixa de teste opcional e separada. |
| Pré-registro | Uma campanha de divulgação do lançamento na loja. | Não | Inicialmente desativado para desenvolvedores sujeitos ao pré-requisito de testes. |
Quatro sistemas, quatro listas, um jogo. Esta seção existe porque três desses quatro são invisíveis de dentro da tela da faixa fechada, então o desenvolvedor que configurou corretamente o único que consegue ver supõe, com razão, que os outros vêm junto. Não vêm.
Fonte: configuração do Play Games Services no console e autorização de testadores, que documenta a lista de testadores, a alternativa de ativar uma faixa e os erros de OAuth e 404 que um testador não autorizado vê.
Dá para usar o pré-registro enquanto seu jogo está em teste fechado?
No começo, não. Para desenvolvedores sujeitos ao requisito de testes das novas contas pessoais, o pré-registro está entre os recursos desativados até o requisito ser cumprido. Quando ele fica disponível, uma campanha de pré-registro pode durar até 90 dias, e um desenvolvedor pode ter no máximo 2 apps ou jogos em pré-registro ao mesmo tempo.
Isso dói mais em jogos do que em apps, porque o pré-registro é uma ferramenta de lançamento, e o lançamento de um jogo costuma ser planejado de trás para frente, a partir de uma data. Se o seu plano contava com uma campanha de pré-registro rodando junto com o teste fechado, esse plano precisa ser reordenado: primeiro cumpra o pré-requisito, depois rode a campanha, depois lance.
| Etapa | Teste fechado | Pré-registro |
|---|---|---|
| Antes de o requisito ser cumprido | Em andamento: esta é a janela que qualifica. | Desativado para as contas afetadas. |
| Depois que o acesso de produção é concedido | Opcional, e ainda útil para atualizações futuras. | Disponível, com até 90 dias por campanha. |
| Com vários títulos em andamento | Cada app novo precisa cumprir o requisito para o próprio nome de pacote. | No máximo 2 títulos em pré-registro ao mesmo tempo. |
| Teste aberto | O fechado é a faixa que o pré-requisito cita. | O teste aberto fica disponível depois que você tem o acesso de produção. |
A ordem prática para um primeiro jogo: rode o teste fechado assim que a versão estiver jogável, em vez de esperar até ela parecer pronta, porque as duas semanas correm em paralelo com o trabalho que você já está fazendo. O marketing que depende de recursos da loja vem depois, não durante.
Fonte: o requisito de teste fechado para novas contas pessoais (resposta 14151465), que é onde o Google afirma que o acesso de produção e o pré-registro continuam restritos até o requisito ser cumprido.
O que os seus testadores devem realmente fazer com o jogo?
Percorra os caminhos em que um jogo quebra de um jeito diferente de um app: a instalação entregue pelo Play, o tutorial, o core loop, o progresso salvo entre reinicializações, uma sessão longa o bastante para esquentar o aparelho, ir para segundo plano e voltar, downloads de assets, compras e login do Play Games. O Google não publica um número obrigatório de aparelhos nem uma duração de sessão, então cubra a faixa de aparelhos que o seu jogo realmente suporta e gaste a profundidade onde o seu jogo tem algo fora do comum.
| Área de teste | O que cobrir | Por que vale o tempo | Status |
|---|---|---|---|
| Instalação e primeira abertura | Uma instalação limpa pelo Play, as permissões e a primeira entrega de assets. | Um jogo que instala localmente ainda pode falhar no comportamento de splits e de assets entregues pelo Play. | Prática de QA |
| Tutorial e primeiros passos | Todos os passos, mais a navegação para trás e os caminhos que as pessoas pegam sem querer. | O acesso de produção pergunta como os testadores se engajaram, e os primeiros minutos são o que a maioria deles vai ver. | Prática de QA |
| Core loop do jogo | Jogo o bastante para exercitar os controles, uma vitória, uma derrota, um reinício e a progressão normal. | É essa a diferença entre um teste com significado e uma instalação passiva. | Prática de QA |
| Progressão e saves | Sair, retomar, reiniciar o app, reiniciar o aparelho e recarregar o progresso. | Perda de save é a falha que os jogadores punem com mais força, e ela precisa de alguém que tenha progresso a perder. | Prática de QA |
| Desempenho prolongado | Jogue bem além do primeiro minuto e fique de olho na degradação dos frames e nos engasgos. | O vitals só começa a medir a taxa de frames depois de um minuto, e o calor chega mais tarde que isso. | Métrica do vitals |
| Variedade de aparelhos | Aparelhos reais cobrindo a faixa que o seu jogo suporta, com peso no que os seus jogadores têm na mão. | A cobertura deve seguir o risco; não existe número fixo publicado de aparelhos ou de GPUs. | Prática de QA |
| Caminhos gráficos | Os caminhos de renderização e as variantes de textura que o seu build realmente leva. | O direcionamento por compressão de textura faz aparelhos diferentes receberem assets diferentes. | Prática de QA |
| Memória e estabilidade | Transições de fase, reinícios repetidos, cenas pesadas e sessões longas. | Crashes e ANRs são métricas de qualidade medidas pelo Play, com limites publicados. | Métrica do vitals |
| Segundo plano e retomada | Botão home, uma notificação interrompendo, tela desligando e ligando, recriação do processo quando der. | Jogos perdem estado e contexto de renderização em mudanças de ciclo de vida com mais frequência do que apps. | Prática de QA |
| Entrega de assets | O que o seu jogo usar entre install-time, fast-follow e on-demand, incluindo downloads interrompidos. | Os modos se comportam de formas diferentes, e o teste local não reproduz a entrega feita pelo Play. | Limites do Google |
| 64 bits | O build rodando em um ambiente de 64 bits, principalmente com plugins nativos presentes. | O Google Play exige suporte a 64 bits nos apps publicados. | Exigência do Google |
| Compras no app | Aprovada, recusada, pendente, consumível repetido, direito de acesso e confirmação. | O Google oferece instrumentos de teste de licença justamente para esses cenários. | Mecanismo do Google |
| Play Games Services | O login mais cada conquista, placar e recurso de jogo salvo que você habilitou. | Configurações não publicadas precisam de autorização de testador à parte e de credenciais que batam. | Exigência do Google |
| Declarações de conteúdo | O questionário de classificação, o público-alvo e qualquer comportamento de probabilidades de itens aleatórios. | Classificações imprecisas ou divulgações ausentes são risco de política, independentemente do teste. | Política do Google |
Dê aos testadores um roteiro, não uma ordem de "testa aí"
O jeito mais rápido de transformar doze instalações em doze relatos úteis é entregar às pessoas um roteiro curto e numerado dentro do jogo, com uma coisa para observar em cada parada e uma pergunta que você realmente quer ver respondida. Testador mandado explorar não relata nada; testador que recebe a instrução "chegue na fase três, feche o jogo, abra de novo e me diga se o seu progresso está lá" relata o bug de save no dia dois, e não no dia treze. Emuladores não ajudam nas linhas acima que dependem de calor, de GPUs reais ou de condições reais de rede, e os riscos de se apoiar neles estão no post sobre emuladores no teste fechado.
Por que o Google pede mais 14 dias depois de você chegar aos 12?
Porque o acesso de produção avalia a qualidade do teste, não só o contador. O Google pergunta o que os testadores fizeram, que feedback deram e o que você mudou, e ele aponta testadores que não se engajaram com o seu app como motivo para exigir mais testes. Bater 12 e 14 é o piso de elegibilidade, não uma aprovação.
Desenvolvedores relatam esse desfecho com frequência: os números foram atingidos, a solicitação foi enviada e a resposta foi mais testes. Relato da comunidade As threads são consistentes sobre a experiência e bem menos confiáveis sobre a causa, já que ninguém fora do Google vê o raciocínio. O que dá para afirmar a partir da documentação do próprio Google é que engajamento e feedback fazem parte do que é avaliado, e com isso já dá para trabalhar.
| Sintoma | O que checar primeiro | A correção real |
|---|---|---|
| O Play diz que não há testadores qualificados suficientes | Alguém nunca concluiu o aceite, alguém saiu ou a janela contínua ainda não terminou. | Confirme que pelo menos 12 contas qualificadas ficaram participando sem interrupção durante toda a janela exigida. |
| 12 testadores e 14 dias cumpridos, acesso recusado | O Google entendeu que faltava teste, o que pode incluir engajamento fraco ou pouca coleta de feedback. | Leia a resposta, siga testando de verdade, colete feedback real, corrija o que ele apontar e responda a solicitação com precisão. |
| O jogo roda local, mas os assets falham pelo Play | Modo de entrega de assets, comportamento de atualização ou pressão de armazenamento diferentes do seu ambiente local. | Teste o build entregue pelo Play e trate a disponibilidade dos pacotes e os estados de atualização, em vez de supor que o comportamento local se mantém. |
| O jogo engasga depois de um tempo de jogo | Gargalo de CPU ou GPU, throttling térmico, frame pacing ou incompatibilidade de taxa de atualização. | Faça profiling de sessões longas e do estado térmico, não de sessões curtas, usando as ferramentas de desempenho de jogos do Android. |
| A tela de compra mostra um cartão real | A conta não está atuando como testadora de licença, ou quem está comprando é outra conta do aparelho. | Adicione a conta certa em Settings > License testing e confirme qual conta baixou o build. |
| Compra de teste estornada minutos depois | A compra nunca foi confirmada. | Corrija a lógica de confirmação ou de consumo. As compras de teste de licença são estornadas automaticamente depois de 3 minutos quando não são confirmadas. |
| O login do Play Games retorna OAuth ou 404 | O testador não está autorizado na configuração não publicada do Play Games. | Adicione o testador individual do Play Games ou habilite a faixa de lançamento para o teste do Play Games. |
| O Play Games funcionava e quebrou depois do upload | Divergência de nome de pacote ou de certificado de assinatura entre a configuração e o build enviado. | Verifique a impressão digital do Play App Signing, o nome do pacote e a credencial vinculada. |
| O jogo nativo não aparece em alguns aparelhos | Uma lacuna de ABI ou de suporte a 64 bits. | Confirme que existe uma biblioteca de 64 bits correspondente para cada arquitetura nativa compatível e teste em um ambiente de 64 bits. |
| Sinalizado por funcionalidade quebrada ou trivial | O jogo trava, não carrega ou não entrega uma funcionalidade que funcione. | Corrija os problemas funcionais. Não saia atrás de um número mínimo de fases inventado para cumprir. |
| Compra de item aleatório questionada | As probabilidades dos itens aleatórios comprados não são divulgadas onde os jogadores as veem. | Mostre as probabilidades antes da compra e perto do momento dela. |
Como deve ser um segundo ciclo
Se pedirem mais testes, a tentação é repetir a primeira rodada com o mesmo padrão de instalação passiva e torcer por uma resposta diferente. Um segundo ciclo mais útil muda alguma coisa de verdade: mantenha o grupo estável, dê aos testadores um roteiro real dentro do jogo, registre por escrito o que eles relatarem, publique as correções que o feedback justificou e descreva tudo isso com clareza quando solicitar de novo. Isso também é, e não por acaso, o que produz um jogo melhor.
O que ele não deve incluir é um ritual inventado. Não existe número publicado de aberturas, nem contagem obrigatória de atualizações, nem cota de jogo diário que transforme uma recusa em aprovação, e ninguém pode te prometer que um padrão específico de atividade vai mudar a decisão do Google. Mais sobre os padrões de recusa em geral no post sobre por que o teste fechado é recusado.
Principais prazos do Google Play para quem publica jogos em 2026 e no início de 2027
31 de agosto de 2026 já passou: jogos para celular novos e atualizados precisam ter como alvo o Android 16 (nível de API 36) ou mais recente, e Play Billing Library 7 passou do prazo para apps novos e atualizações. Se você tem uma extensão, ela vale até 1º de novembro de 2026, que está a 57 dias de distância.
Outros três ficam em volta desses: 30 de setembro de 2026 para o registro de nome de pacote no Play e para a primeira onda de aplicação da verificação de desenvolvedor, e 1º de fevereiro de 2027 para os tamanhos de página de memória de 16 KB, que é o mais provável de pegar um jogo feito em engine. Nenhum deles faz parte da exigência de testadores, e todos eles podem bloquear o lançamento que essa exigência deveria destravar.
| Data | Exigência | O que significa para um jogo |
|---|---|---|
| 31 de agosto de 2026 | Nível de API alvo | Os jogos novos e atualizados para celular precisam ter como alvo o Android 16, nível de API 36 ou posterior. Outros formatos de aparelho são diferentes: Wear OS e Android Automotive OS precisam da API 35, Android TV e Android XR precisam da API 34. Detalhamento completo no post sobre o nível de API alvo. |
| 31 de agosto de 2026 | Play Billing Library | A Play Billing Library 7 chega ao prazo para apps novos e para atualizações. Jogos monetizados precisam de uma versão posterior compatível nas novas versões, a não ser que uma extensão se aplique. |
| 30 de setembro de 2026 | Registro de nome de pacote no Play | Qualquer app ou jogo do Play cujo nome de pacote ainda não estiver registrado até essa data corre risco de remoção do Play. Vale no mundo todo e não tem nada a ver com a idade da sua conta. |
| 30 de setembro de 2026 | Verificação de desenvolvedor, primeira onda | Primeira aplicação da verificação de desenvolvedor do Android, para instalações feitas por lojas participantes no Brasil, na Indonésia, em Singapura e na Tailândia. Não é um desligamento mundial. Detalhes no post sobre a verificação de desenvolvedor. |
| 1º de novembro de 2026 | Fim da extensão | A última data coberta pela extensão disponível, tanto para a exigência de API alvo quanto para a Play Billing Library 7. As extensões são solicitadas pelo aviso correspondente no Play Console, não são concedidas automaticamente. |
| 1º de fevereiro de 2027 | Tamanhos de página de memória de 16 KB | As atualizações afetadas que têm como alvo o nível de API 35 ou posterior e levam código nativo não podem ser publicadas sem compatibilidade com páginas de 16 KB. Os binários da engine e dos plugins são exatamente onde isso morde. Caminho de reparo no post sobre o erro de 16 KB. |
| 27 de janeiro de 2027 | Permissões de contatos | Vale apenas para apps que têm como alvo o Android 17, nível de API 37 ou posterior, e que usam o acesso amplo a contatos afetado, algo que a maioria dos jogos nunca pede. A linha do tempo de políticas do Google e a tabela de prazos da Central de Ajuda do Play Console agora trazem essa mesma data. |
Essas datas mudam sem nenhum aviso
Confira de novo antes de planejar O Google publica prazos de política em duas superfícies que se afastam uma da outra e depois são reconciliadas em silêncio. Os prazos de contatos e localização acima diziam 28 de outubro de 2026 na linha do tempo do Android Developers até meados de agosto de 2026, quando aquela página foi editada para 27 de janeiro de 2027 para bater com a Central de Ajuda do Play Console, sem nenhuma entrada de changelog. Newsletters mais antigas do Google ainda citam a data aposentada. Compare a tabela de prazos da Central de Ajuda do Play Console com a linha do tempo de políticas antes de montar um plano de lançamento em cima de qualquer linha daqui, e não confie nem numa newsletter nem num post de blog acima das páginas ativas. Uma linha ainda diverge hoje: Child Safety Standards aparece como 26 de agosto de 2026 na tabela da Central de Ajuda e como 28 de outubro de 2026 na linha do tempo. Planeje para 26 de agosto.
Fontes: os requisitos de nível de API alvo (resposta 11926878) para as datas de 31 de agosto e os níveis por formato de aparelho, e para o resto as duas superfícies de política do Google: a tabela de prazos da Central de Ajuda do Play Console e a linha do tempo de políticas do Android Developers.
Vale dizer com todas as letras, porque a ordem das coisas pega muita gente: nenhuma dessas datas tem qualquer relação com a exigência de testadores, e cumprir a exigência de testadores não isenta você de nenhuma delas. Um jogo pode terminar um teste fechado de 14 dias impecável e ainda assim não conseguir ser publicado porque o build tem como alvo o nível de API errado. Confira as exigências que bloqueiam o lançamento antes de começar a quinzena, não depois dela.
Onde encontrar 12 testadores reais para um jogo?
Recrutar essas pessoas é a parte que a maioria dos desenvolvedores solo subestima. A exigência de teste publicada pelo Google não determina como os testadores precisam ser recrutados, então pagar por QA não desqualifica automaticamente. Leia isso como ausência de proibição, e não como um aval do Google aos serviços de testadores enquanto categoria, porque o Google nunca publicou aval nenhum. O que as políticas do Google proíbem é manipular avaliações, comentários, posicionamento ou contagem de instalações por meios ilegítimos: bots, contas falsas, instalações fraudulentas, engajamento manipulado. A régua é gente de verdade fazendo teste de verdade e dando feedback honesto, não importa como você as encontrou.
O motivo de as comunidades de engine estarem cheias de posts do tipo "preciso de 12 testadores" é aritmética: quem faz o primeiro jogo geralmente não conhece doze pessoas que tenham celular Android, concluam o aceite e ainda estejam participando duas semanas depois. Os amigos instalam, jogam uma vez por educação e somem. Nada disso é defeito de caráter. É só que um favor tem meia-vida de uns três dias e a exigência dura quatorze.
Os grupos de troca de testadores resolvem a contagem e, muitas vezes, não muito mais, porque o parceiro de troca tem o mesmo incentivo que você: aceitar participar, ficar lá e seguir a vida. Isso satisfaz o contador e produz exatamente o padrão de engajamento passivo sobre o qual o Google pergunta no formulário de solicitação. Para um jogo é pior do que para um app, porque as falhas que importam moram várias sessões adiante e um testador recíproco nunca vai chegar até lá.
O que um serviço gerenciado cobre
A PrimeTestLab fornece 12 testadores reais em dispositivos reais, do Android 7 ao 17, participando e mantidos no teste pelos 14 dias completos, com o teste começando em 4-6 horas. Já rodamos isso em 7.400+ apps em 120+ países, com 99,9% de taxa de sucesso, e a rodada tem novo teste grátis ou reembolso total por trás. Os planos começam em $19.99.
Sendo direto sobre o limite, porque um jogo tem partes que ninguém assume no seu lugar: um serviço gerenciado sustenta o lado dos testadores durante a quinzena. Ele não refaz os seus pacotes de assets, não ajusta os seus tempos de frame, não implementa a confirmação no seu código de faturamento nem responde o seu questionário de classificação. Isso é com você, e as seções acima existem para deixar essa parte mais curta. O que desaparece é a correria do recrutamento e o risco de o grupo desmoronar no dia nove.
Recrutar por conta própria x serviço gerenciado
| A exigência do Google | Por conta própria | Serviço gerenciado |
|---|---|---|
| Pelo menos 12 testadores participando | Achar, orientar e cobrar pessoas reais, e depois torcer para que cada uma delas conclua o aceite. | 12 fornecidos e mantidos durante a janela inteira. |
| 14 dias contínuos | Uma saída só custa a rodada se deixar menos de 12 testadores capazes de mostrar, cada um, 14 dias contínuos na hora em que você solicita. | O grupo é monitorado para a janela ficar intacta. |
| Aparelhos reais, gente real | Emuladores e contas paradas são o atalho de sempre, e o motivo de sempre para uma rodada não produzir nada que se possa relatar. | Aparelhos reais, do Android 7 ao 17. |
| Engajamento que dá para contar ao Google | Depende inteiramente de os seus testadores jogarem de fato além do tutorial. | Testadores que jogam o jogo, em vez de deixá-lo parado na tela inicial. |
| Tempo até o primeiro aceite | Dias, dependendo de quem te responder. | O teste começa em 4-6 horas. |
| Custo | O seu tempo, durante a quinzena que você já vai gastar com o build. | A partir de $19.99, com novo teste grátis ou reembolso total. |
Uma coisa que nenhum serviço pode oferecer, e desconfie de quem oferecer: o acesso de produção em si. Quem decide isso é o Google, que pesa a qualidade do seu teste além da contagem e pode pedir mais um ciclo. O que dá para prometer é o grupo de testadores, a quinzena e a garantia por trás disso. Veja os planos e o que cada um inclui →
Perguntas frequentes
Jogos precisam de 12 testadores por 14 dias no Google Play?
Sim, quando o jogo é publicado por uma conta pessoal de desenvolvedor do Google Play criada após 13 de novembro de 2023. O Google exige pelo menos 12 testadores participando continuamente de um teste fechado nos últimos 14 dias, no mínimo, antes que esse desenvolvedor possa solicitar o acesso de produção, e nenhum mínimo de testadores específico para jogos aparece em qualquer lugar da documentação atual. O Google trata apps e jogos dentro do mesmo processo de acesso de produção.
Eu continuo vendo 20 testadores por aí. Em 2026 são 12 ou 20?
São 12. No começo o Google exigia 20 testadores e reduziu oficialmente o mínimo para 12 em 11 de dezembro de 2024, descrevendo a mudança como exigir 12 em vez de 20 testadores. O período contínuo de duas semanas de teste continuou o mesmo. As páginas que ainda citam 20 foram escritas antes dessa mudança.
Todo jogo novo precisa do próprio teste fechado?
Sim, para as contas pessoais de desenvolvedor afetadas. A data de criação da conta decide se o requisito se aplica a você, mas o Google escreve a condição como um teste fechado "para o seu app", e o pedido de acesso de produção é enviado para um pacote individual. Um teste que qualifica um jogo não vale para o próximo jogo que você publicar pela mesma conta.
Meus 12 testadores de jogo precisam jogar todos os dias?
A regra explícita é a participação contínua. O Google exige que os testadores que qualificam continuem participando sem interrupção e diz que o engajamento dos testadores conta quando ele analisa o acesso de produção, mas não publica nenhuma regra do tipo abrir o jogo uma vez por dia ou jogar um número fixo de minutos. Jogo de verdade, significativo e com feedback útil é a meta segura. Cota diária de jogo é folclore da comunidade, não política.
A saída de um testador reinicia os 14 dias inteiros?
Não automaticamente. Quando você faz o pedido, pelo menos 12 testadores precisam ter, cada um, permanecido participando nos 14 dias contínuos anteriores. Se você começou com mais de 12 e ainda tem essa quantidade de testadores que qualificam, uma saída não invalida o teste. Se a saída deixar você com onze, é preciso esperar até que um testador substituto complete o próprio período contínuo de 14 dias. Esse é o argumento para recrutar acima do mínimo.
Posso enviar um build novo do jogo durante o teste de 14 dias?
Pode. A condição publicada pelo Google se baseia no histórico de participação dos testadores, e não em manter um build congelado por 14 dias, então lançar uma nova versão não apaga, por si só, o período contínuo de participação dos testadores. Dê tempo para a nova versão terminar o processamento, peça aos testadores que atualizem e continue documentando o feedback e as correções que ele gerou. O Google observa que mudanças em um teste podem levar algumas horas para ficar disponíveis para os testadores.
Basta manter meu jogo instalado por 14 dias?
Não trate a instalação sozinha como prova de teste. O pré-requisito numérico é a participação contínua, mas o pedido de acesso de produção pergunta como os testadores se envolveram com o jogo, que feedback foi coletado e o que mudou por causa disso. O Google aponta testadores que não se envolveram com o seu app como um motivo para exigir mais testes.
Desinstalar o jogo reinicia o teste de 14 dias?
O Google não publica uma regra separada dizendo que a desinstalação, sozinha, reinicia o período de participação; o requisito numérico explícito é a participação contínua. Mas um jogo desinstalado não gera partida nenhuma, nenhum feedback e nenhuma evidência de teste, e o Google pode exigir mais testes quando o engajamento é insuficiente. Continuar participando sem nunca abrir o jogo não é uma estratégia segura e, em um jogo, também significa que ninguém está exercitando os caminhos de save, de entrega de assets e de desempenho que realmente quebram.
Posso usar o teste interno no lugar do teste fechado com 12 pessoas?
Para esse pré-requisito, não. O teste interno é uma faixa separada que comporta até 100 testadores, mas o requisito do Google para as novas contas pessoais afetadas exige especificamente um teste fechado que qualifique antes do pedido de acesso de produção. O teste interno é útil para uma distribuição inicial rápida; ele não cumpre a etapa obrigatória do teste fechado.
Qual é o tamanho máximo do meu jogo Android no Google Play em 2026?
A Ajuda do Play Console lista 500 MB de módulo base, 500 MB por módulo de recursos, 1,5 GB por pacote de assets, 4 GB acumulados para todos os módulos mais os pacotes de assets install-time, 30 GB acumulados para os pacotes fast-follow e on-demand e um máximo total de 34 GB de download compactado, com no máximo 100 pacotes de assets por bundle. Esses são tamanhos de download compactado calculados pelo Play Console, e não o tamanho do bundle no seu disco. Valores conferidos em 12 de agosto de 2026.
Os testadores precisam comprar um jogo pago durante o teste fechado?
Sim. Testadores de um teste aberto ou fechado ainda precisam comprar um jogo pago. Testadores da faixa de teste interno podem instalar um jogo pago de graça. Esse mecanismo é separado do teste de licença para compras no app, que decide se uma IAP usa as formas de pagamento de teste do Google em vez de cobrar dinheiro de verdade.
Por que o Google Play está cobrando compras no app dos jogadores do meu teste fechado?
Estar na faixa fechada e o teste de licença do faturamento são duas coisas diferentes. O Google afirma que os usuários são cobrados de verdade a menos que o usuário seja um testador de licença, então um testador comum da sua faixa fechada pode ser cobrado com dinheiro real. Adicione as contas destinadas ao teste de compras em Settings e License testing para receber as formas de pagamento de teste do Google, incluindo os cenários de aprovar sempre, recusar sempre e de atraso.
Por que o login do Google Play Games falha no meu jogo em teste fechado?
O Play Games Services tem a própria camada de acesso. Enquanto a configuração do Play Games Services não estiver publicada, os testadores precisam ser autorizados individualmente ou por uma faixa de lançamento ativada no Play Console; caso contrário, diz o Google, eles vão encontrar erros de OAuth e 404. Adicione-os em Grow users, Play Games Services, Setup and management, Testers, e confira se o nome do pacote e a impressão digital do certificado de assinatura correspondem ao build.
Um jogo pequeno ou simples é recusado por funcionalidade mínima?
O Google tem uma política de funcionalidade e qualidade que exige experiências estáveis, responsivas e suficientemente funcionais, e apps ou jogos que travam, não carregam ou são praticamente não funcionais podem violá-la. Nenhuma fonte primária do Google publica um número mínimo fixo de fases, telas, mecânicas ou minutos de jogo. Trate qualquer número específico que você ler como folclore e corrija os problemas funcionais reais.
As loot boxes transformam automaticamente um jogo Android em um app de jogos de azar?
Não. As políticas do Google separam os itens virtuais aleatórios comprados dos jogos de azar com dinheiro real. Jogos que oferecem itens virtuais aleatórios como as loot boxes precisam divulgar claramente as probabilidades antes da compra e perto dela. Pagar dinheiro ou valor comprado por uma chance de ganhar um prêmio do mundo real cai na política separada do Google sobre jogos de azar, jogos e concursos com dinheiro real, que é outro regime, com requisitos próprios de elegibilidade e licenciamento.
Outra pessoa pode fornecer os 12 testadores do meu jogo?
Sim. O requisito de testes do Google não determina como os testadores precisam ser recrutados, então pagar por QA não é automaticamente desqualificante. Leia isso como a ausência de uma proibição, e não como um endosso do Google a serviços de testadores, algo que ele nunca fez. O que viola a política é manipular notas, avaliações, posicionamento ou contagem de instalações por meios ilegítimos, como bots, contas falsas ou instalações fraudulentas. A PrimeTestLab fornece 12 testadores reais em dispositivos reais a partir de $19.99, mantém o grupo participando pelos 14 dias completos e garante a rodada com um novo teste grátis ou reembolso total. Ninguém pode prometer o acesso de produção, porque essa decisão é do Google e ele pesa a qualidade do seu teste, além da contagem.
Conclusão
Resumo
O Google Play não tem cláusula especial para jogos. Uma conta pessoal de desenvolvedor criada depois de 13 de novembro de 2023 precisa de 12 testadores participando por 14 dias contínuos antes de poder solicitar o acesso de produção, tanto faz se ela publica um jogo ou uma calculadora, e o número 20 que ainda circula por aí foi substituído em 11 de dezembro de 2024. Fechar esse contador é o piso, não o veredito: o Google pergunta o que os seus testadores fizeram, o que eles te disseram e o que você mudou. Um jogo enfrenta ainda uma segunda camada que o contador nunca toca, e é aí que a quinzena vale mesmo alguma coisa: pacotes de assets que só dão problema depois que o Play os entrega, frames que travam quando o aparelho esquenta, binários nativos de 64 bits, testadores cobrados de verdade porque ninguém foi adicionado em Settings > License testing, o login do Play Games devolvendo 404 para todo mundo menos para você e a divulgação de probabilidades em itens aleatórios. Teste tudo isso durante a quinzena que você já vai gastar de qualquer jeito. Se a parte dos testadores é a que você não consegue montar, a PrimeTestLab fornece 12 testadores reais a partir de $19.99, com novo teste grátis ou reembolso total. Ver planos de preços →
Fontes primárias
O que nesta página vai envelhecer primeiro
- Os limites de tamanho. A tabela de maior risco daqui. A página de tamanho dedicada do Play Console e algumas páginas mais antigas sobre jogos Android já se contradizem, e os tetos de fast-follow e on-demand parecem ter sido ampliados há pouco tempo. Confira a página de tamanho de novo antes de planejar um lançamento em torno de 30 GB ou 34 GB.
- As datas do faturamento. As janelas de suporte da Play Billing Library mudam de versão para versão, e as datas de 31 de agosto e 1º de novembro desta página mudam de sentido no instante em que passam. Esta página troca o próprio texto nessas datas; a tabela de suporte por trás dela continua precisando de uma releitura.
- As datas-limite de política. O item que mais muda nesta página. O Google moveu os prazos de contatos e localização de 28 de outubro de 2026 para 27 de janeiro de 2027 em uma das suas superfícies em meados de agosto de 2026, sem anúncio, e as newsletters dele seguiram citando a data aposentada depois disso. Resolva qualquer data daqui pelas duas páginas de política ativas do Google, não por uma newsletter ou um artigo, incluindo este.
- Os caminhos do Console. Settings > License testing, Policy > App content e o caminho dos testadores do Play Games Services são a nomenclatura atual, e a navegação do Console muda por conta própria, independentemente da política.
- Os limites do Android vitals. Os valores de crash, ANR e sessão lenta são limites de qualidade que o Google pode revisar no ritmo dele, sem nenhuma relação com os requisitos de teste.
- Os números de testadores. O item de menor risco da lista, mas 20 já virou 12 uma vez. Se algum número daqui divergir da página do Google, a página do Google está certa e esta aqui está velha.
Verificado na documentação do Google em 12 de agosto de 2026. Datas-limite de política reverificadas em 14 de agosto de 2026.