Resposta rápida
Um emulador pode contar para os 12 testadores?O requisito fala em testadores e participação contínua, não em tipo de dispositivo
Use um emulador para testar o seu app. Não use emuladores para fabricar os participantes do seu teste fechado. O requisito publicado pelo Google é de 12 testadores participando por 14 dias contínuos, e os requisitos e a documentação técnica revisados para este guia não especificam se a participação a partir de um emulador conta para esse mínimo. A nossa recomendação, que vem da experiência de conduzir esses testes para desenvolvedores, é mais firme do que a documentação precisa ser: rodar o seu build em um emulador é desenvolvimento comum e não tem problema nenhum; colocar instâncias de emulador no lugar das doze pessoas não é um atalho que nós tomaríamos; e criar contas Google falsas para participar a partir delas é manipulação e, na nossa experiência, o tipo de teste que é devolvido ou rejeitado. Acompanhe o seu progresso no Play Console e recrute pessoas que vão usar o app e contar o que encontraram.
| A pergunta | O que decide | Onde está a resposta |
|---|---|---|
| Um emulador consegue rodar e ajudar a testar o meu app? | A imagem do sistema que você escolhe e o próprio app. | Documentação do emulador do Android Studio. É para isso que a ferramenta existe. |
| Um testador consegue abrir a minha versão de teste fechado em um emulador? | A conta Google, se a participação foi aceita, a versão publicada e as restrições que você definiu. | Configuração do teste no Play Console. Elegibilidade da conta, disponibilidade da versão, compatibilidade e as verificações de dispositivo que você configurou. |
| O que o Play Integrity informa sobre ele? | O estado do dispositivo, a versão do Android e os campos que o seu próprio app ou backend lê. | Documentação do Play Integrity. Ele responde ao seu app e ao seu backend; o Play Console reporta isso separadamente. |
| Essa pessoa conta para os 12? | Se o testador está participando do seu teste fechado, de forma contínua, por 14 dias. | O requisito de teste, que não diz nada sobre tipo de dispositivo ou integridade. |
Neste guia
O que o Google exige e a quem isso se aplica
Requisito do GoogleA Ajuda do Play Console diz que um desenvolvedor com conta pessoal criada após 13 de novembro de 2023 precisa realizar um teste fechado antes de publicar em produção, com um mínimo de 12 testadores participando continuamente por pelo menos 14 dias (requisitos de teste de apps). Até que isso seja cumprido, Produção e Pré-registro permanecem bloqueados. Cumprir o requisito torna você elegível para solicitar o acesso; a aprovação é uma análise separada. Contas de organização não estão sujeitas à regra. O requisito em si é destrinchado em o requisito dos 12 testadores explicado.
Para uma conta pessoal de desenvolvedor criada após 13 de novembro de 2023, o app precisa de um teste fechado com pelo menos 12 testadores participando continuamente por 14 dias antes que o desenvolvedor possa solicitar acesso de produção.
O Google também explica o que significa continuamente. Testadores que aceitam participar, testam por menos de 14 dias e depois saem do teste não contam para o requisito, e se alguém voltar a participar mais tarde, os 14 dias ainda precisam ser consecutivos. O mínimo era 20 até que o Google o reduziu para 12 em 11 de dezembro de 2024, mudança que ele acrescentou ao anúncio de 2023. A duração de 14 dias não mudou.
Leia o requisito como está escrito: ele trata do status de participação
Repare em quais substantivos o requisito usa e em quais não usa. Ele fala em testadores e em participação contínua, não em modelo de dispositivo, estado de certificação ou veredito de integridade. Daí decorrem duas leituras erradas. Desinstalar não é a mesma ação que sair do teste, então uma desinstalação não interrompe automaticamente a janela. E uma pessoa que sai não zera as outras: a continuidade é acompanhada por inscrição.
A verificação de dispositivo do desenvolvedor é outra tarefa
O Google exige um dispositivo Android físico em um único ponto, e é fácil confundir isso com uma regra para testadores. Contas pessoais de desenvolvedor novas precisam concluir a verificação de dispositivo em um dispositivo Android físico sem root, com Android 10 ou superior, conectado com a conta do titular (requisitos de verificação de dispositivo). O Google diz que você pode ser solicitado a verificar novamente mais tarde, não necessariamente no mesmo dispositivo. De todo modo, trata-se do titular da conta comprovando acesso a um dispositivo, e isso não diz nada sobre o que os seus testadores usam.
O requisito se aplica a você?
Ele se aplica a contas pessoais criadas após 13 de novembro de 2023. Contas pessoais mais antigas e contas de organização ficam fora dele, então "abra uma conta de organização" é uma diferença de elegibilidade, não um atalho esperto. Uma conta de organização precisa de uma organização registrada que o Google verifica, normalmente com um número D-U-N-S, que pode ser solicitado sem custo. Comparamos as duas em conta pessoal vs. conta de organização no Google Play.
Emuladores contam para os 12 testadores?
Nada na documentação revisada aqui responde a isso com um sim ou um não, e é por isso que o restante deste guia separa o que é declarado do que é inferido. As afirmações cabem em uma de quatro categorias, e o erro comum é promover discretamente uma afirmação de uma categoria mais baixa para uma mais alta.
Uma regra que você precisa cumprir: 12 testadores, 14 dias contínuos, a data de corte de 13 de novembro de 2023, e o fato de que cumpri-la permite solicitar o acesso.
Descrições precisas de comportamento: vereditos de integridade, imagens do sistema, configuração de testes. Escritas com um propósito diferente do de decidir quem conta.
Tópicos na Comunidade de Desenvolvedores do Google Play e no Reddit. A resposta recomendada no tópico que citamos aconselha usar outras pessoas em dispositivos Android físicos em vez de emuladores. Vale a leitura, mas a página avisa que o conteúdo pode não ter sido verificado, e um domínio do Google não é política.
O nosso próprio julgamento: recrute acima do mínimo e não fabrique participação com emuladores ou contas falsas. Conselho de quem faz esse trabalho, não uma regra, e nós vendemos ajuda com testes.
Documentado e seguro para citar
Declarado nas políticas, nas páginas de ajuda ou na documentação para desenvolvedores do Google.
- O requisito em si: 12 testadores participando por 14 dias contínuos, para contas pessoais criadas após 13 de novembro de 2023.
- A solicitação de acesso de produção pergunta como o teste foi conduzido, o que é o app e o que você mudou por causa dos testes.
- As Políticas do Programa para Desenvolvedores proíbem manipular posicionamento, classificações, avaliações ou números de instalação por meios ilegítimos.
- O Google recomenda testar em hardware físico antes de lançar, e documenta o teste em emulador em várias versões e tamanhos de tela.
Não especificado: não presuma
Parece plausível, mas está ausente da documentação revisada aqui.
- Que um veredito do Play Integrity decide se um testador conta para os 12.
- Qualquer sinal de detecção nomeado: ruído do acelerômetro, variação da temperatura da bateria, deriva do GPS, telemetria de toque, agrupamento de IPs ou idade da conta.
- Qualquer número específico do tipo "X% dos emuladores são pegos". Trate percentuais exatos como não comprovados, não como medições.
- Um atraso universal de relatório, um número obrigatório de sessões diárias ou um número obrigatório de atualizações durante a janela.
Testadores participando, público instalado e acesso de produção
Boa parte dessa discussão gira, na verdade, em torno de três números do Play Console que são tratados como se fossem intercambiáveis. Não são.
| O que você está vendo | O que significa | O que não diz |
|---|---|---|
| Testadores participando | Contas que aceitaram o link de participação desta faixa. É o substantivo em torno do qual o requisito foi escrito, junto com o tempo em que elas permanecem participando. | Se alguém instalou, abriu o app ou deu um feedback útil. |
| Público instalado | O Google o define como usuários com o seu app instalado em pelo menos um dispositivo que eles usaram nos últimos 30 dias. O dispositivo precisa ter sido usado; o app, não. | É uma métrica de público, não o contador do acesso de produção, e não uma contagem de dispositivos que passaram em uma verificação de segurança. |
| A lista de verificação do acesso de produção | O item do Painel que informa quantos testadores estão participando e por quantos dias contínuos. É com base nisso que o requisito é medido. | Por que uma pessoa específica está ou não nela. Para isso, confira a inscrição. |
Cumprir o mínimo não é o mesmo que fazer um teste convincente. O Google pode pedir mais testes quando o engajamento dos testadores não é suficiente, mesmo depois de 12 testadores terem participado por 14 dias contínuos. Ele não publica nenhuma cota diária de sessões, então o objetivo é um teste que gerou uso real e feedback real, não atividade fabricada para parecer movimentada.
Instalar fora do Play é um caminho à parte, e ele não inscreve ninguém. Um Android App Bundle é um formato de publicação, não um arquivo instalável, então o que é instalado dessa forma é um APK gerado a partir dele. E não importa como o arquivo chega (instalação manual, link compartilhado, compartilhamento interno de apps), ele não aceita o seu link de participação em nome de ninguém.
Uma diferença entre dois desses números é um sintoma, não um diagnóstico. Doze participantes com um público instalado baixo tem explicações comuns: pessoas aceitaram participar e nunca instalaram, instalaram em um dispositivo que não usam há algum tempo, o relatório está atrasado ou a versão não está disponível para elas.
O que podemos e o que não podemos dizer aqui
O Google publica o requisito de teste e as definições dessas métricas, mas não uma explicação para cada resultado individual de contagem, nem um atraso universal de relatório. Leia a documentação da métrica específica, mantenha um atraso observado separado de uma garantia publicada e percorra a lista de verificação abaixo.
Se um testador não consegue encontrar ou instalar a sua versão de teste fechado
Verifique estes problemas de configuração antes de atribuir a causa ao ambiente. Eles valem tanto para dispositivos físicos quanto para emuladores.
-
01
A conta Google errada
A conta que aceitou o link de participação precisa ser a conta conectada no dispositivo e selecionada na Play Store. Em um celular com várias contas Google, verifique isso primeiro quando alguém relatar "app não disponível".
-
02
A participação nunca foi concluída
A sua lista de e-mails ou o Grupo do Google vinculado torna alguém elegível; não inscreve a pessoa. Ela ainda precisa abrir o link de participação e aceitá-lo, e a inclusão no grupo pode levar algum tempo para ter efeito. Uma versão de teste fechado também não aparece na busca da Play Store, então os testadores chegam a ela pelo link de participação e pelo link da loja que você envia.
-
03
Uma faixa em conflito
Se a conta também está no seu teste interno, peça à pessoa que saia desse teste antes de aceitar participar do fechado. Onde as faixas se sobrepõem, um usuário elegível recebe o maior código de versão compatível disponível para ele, que pode não ser a versão que você está acompanhando (configuração do teste).
-
04
Nenhuma versão ativa nessa faixa
Uma faixa fechada precisa de uma versão publicada que de fato tenha sido lançada, na versão e no percentual que você acha que tem. Um rascunho não é distribuído a ninguém. Um lançamento interrompido encerra a distribuição adicional, mas os testadores que já receberam essa versão ainda podem tê-la instalada, então confira qual versão está sendo entregue. O Google também observa que um novo link de teste, e as alterações feitas nele depois, podem levar algumas horas para ficar disponíveis.
-
05
As suas próprias configurações de disponibilidade
A disponibilidade por país e as restrições de dispositivo são definidas por você. Para países, o Google considera o país da conta do Google Play do testador, que nem sempre é onde a pessoa está. E se você ativou as verificações de dispositivo baseadas em integridade na página do app na loja, elas podem impedir alguns dispositivos de ver ou instalar o app: uma restrição de acesso que você configurou, não uma evidência sobre quais testadores contam.
-
06
O ambiente ou o próprio build
Só depois dos cinco itens acima. Um emulador com a imagem do sistema errada não consegue nem fazer login na Play Store, e o Android Studio publica os problemas conhecidos de imagens específicas.
-
07
É o seu app que está bloqueando, não a Store
Se o download funciona e depois o app se recusa a rodar, isso é uma imposição do seu próprio app, não a disponibilidade no Play. Verifique o que o seu app ou backend faz com a resposta do Play Integrity antes de concluir que o testador não consegue obter o seu build.
Se a contagem ainda parecer errada, temos guias dedicados: testadores adicionados, mas zero participando, o app não está disponível para um testador e acesso de testadores via Grupo do Google. Cada um cobre as causas de configuração mais comuns e as verificações adicionais a fazer.
Quando o teste em emulador ajuda
Emuladores são bons, e o Google desenvolve um. Ele vem dentro do Android Studio, e o Google recomenda testar em várias versões do Android e tamanhos de tela. O erro não é usar um emulador; é esperar que ele faça um trabalho para o qual nunca foi feito.
Recomendação da PrimeTestLabIteração rápida enquanto você desenvolve. Versões do Android e tamanhos de tela que você não tem. Tablets, idiomas, modo escuro, layouts da direita para a esquerda. Reproduzir uma falha sob demanda.
Julgamento independente. Uma máquina rodando cinco dispositivos virtuais continua sendo a opinião de uma única pessoa.
Como o app se comporta no hardware que as pessoas têm: desempenho, bateria, câmera, notificações, mudanças de rede, a versão do Android do próprio fabricante. O Google recomenda testar em hardware antes de lançar.
Uma garantia de elegibilidade. Bons celulares não cumprem um requisito escrito sobre testadores.
A parte que nenhuma ferramenta fornece: alguém que aceita participar, mantém o app instalado, experimenta os fluxos em que você não pensou e conta o que o confundiu.
Cobertura de dispositivos. Doze testadores podem ter celulares parecidos, e é por isso que as verificações em emulador continuam tendo o seu lugar.
Imagens do Android Studio, imagens com Play Store e BlueStacks
Nem todos os emuladores são iguais, e a diferença está na imagem do sistema. Uma imagem AOSP não tem apps do Google. Uma imagem Google APIs adiciona os serviços do Google, mas não a Play Store. Uma imagem Google Play inclui a Store, e o Android Studio marca com o logotipo do Play os perfis de dispositivo compatíveis com ela, documentando esses perfis de telefone como compatíveis com o CTS. O perfil e a imagem do sistema são escolhas separadas ao criar o dispositivo virtual, e você precisa da imagem Play para fazer login e instalar dentro dele. O BlueStacks também documenta o login na Play Store. Nada disso resolve a elegibilidade: chegar à Store e ser contado como testador são resultados separados.
Se você não tem um celular Android, mas quer ajudar alguém a testar
Esta é uma situação diferente de um desenvolvedor fabricando um grupo de testadores, e ela merece uma resposta direta em vez de uma acusação. Ajudar um amigo a testar na máquina que você tem não é engano. O que ninguém pode prometer é o resultado, porque o Google não publica como cada participante é contado. Se isso for importante, pegue um celular Android emprestado ou use um mais antigo que seja compatível. Se você usar um emulador mesmo assim, avise o desenvolvedor para que ele possa planejar o teste de acordo.
Laboratórios de dispositivos na nuvem e relatórios de pré-lançamento
O Firebase Test Lab executa o seu app em dispositivos na infraestrutura do Google, e o relatório de pré-lançamento do Play Console percorre o seu build automaticamente. Ambos são QA automatizado legítimo. Nenhum deles é um participante: uma execução automatizada não aceita participar, não permanece participando por 14 dias e não conta que a tela de integração não fez sentido.
O que o Play Integrity estabelece e o que não estabelece
Documentação técnica do GoogleO Play Integrity é a tecnologia sobre a qual a maior parte dessa discussão se apoia, então vale a pena saber para que ele serve. Segundo o developer.android.com, a API "helps you check that user actions and server requests are coming from your genuine app, installed by Google Play, running on a genuine and certified Android device" (vereditos de integridade). O público dessa resposta é o seu app e o seu próprio backend. O Play Console também reporta a você as respostas de integridade, e uma configuração separada da página do app na loja pode restringir quais dispositivos podem instalar. Nada disso é o requisito do teste fechado, e nada disso deve ser lido como se fosse.
"The app is running on a genuine and certified Android device." No Android 13 e superior, isso vem com prova respaldada por hardware de que o bootloader está bloqueado e o sistema operacional é uma imagem certificada do fabricante; versões anteriores podem se apoiar em uma avaliação por software.
Como o dispositivo aparece para a API. Não é uma afirmação sobre inscrição.Documentado como um dispositivo com "signs of attack (such as API hooking) or system compromise (such as being rooted)", ou um app "not running on a physical device (such as an emulator that does not pass Google Play integrity checks)". O campo pode carregar vários rótulos, então isso é um rótulo ausente, não um valor chamado "em branco".
Cobre várias situações diferentes, então não pode ser lido de trás para frente até uma única causa."The app is running on a device that passes basic system integrity checks. The device may not be certified." Opcional, aqui, significa que o desenvolvedor escolhe se quer receber o rótulo, o que não tem nada a ver com um testador aceitar participar.
Uma configuração de resposta, não uma inscrição."The app is running on a genuine and certified Android device with a recent security update." No Android 13 e superior, isso significa integridade do dispositivo mais atualizações de segurança recentes nas partições relevantes; o Android 12 e inferior é avaliado pela integridade de inicialização respaldada por hardware, sem o mesmo teste de atualização recente.
Um padrão alto para o seu próprio backend. Não é um limite do teste fechado.Documentado para um "Android-powered emulator with Google Play services", no contexto do Google Play Games para PC, que é uma superfície de distribuição com requisitos próprios.
Não é um veredito sobre os emuladores de teste do Android Studio, em nenhuma direção.Dispositivo, reconhecimento do app e licenciamento são campos separados
Três campos são citados como se fossem um só, e misturá-los é onde começa a maior parte da confusão. O campo de dispositivo descreve o ambiente. O campo de reconhecimento do app descreve se o binário em execução corresponde ao que o Google Play distribuiu. O campo de licenciamento descreve o direito de uso e pode reportar sem licença quando a conta não tem direito ao app no Play. Um build instalado fora do Play é uma questão de licenciamento e distribuição, não um veredito de hardware.
Estes exemplos explicam terminologia. Nada aqui entra em contato com o Google, mede o seu dispositivo, verifica participação ou prevê o acesso de produção. As respostas reais dependem do app, da configuração dele e do ambiente.
| Ambiente | O que uma resposta pode mostrar | O que isso diz e o que não diz |
|---|---|---|
| Celular certificado, bootloader bloqueado | O campo do dispositivo pode incluir MEETS_DEVICE_INTEGRITY e, com uma atualização de segurança recente, MEETS_STRONG_INTEGRITY. | Que o dispositivo satisfaz a API. Não se essa pessoa aceitou o seu link de participação. |
| Emulador padrão do Android Studio | O Google documenta um emulador que não passa nas verificações do Play como um dos motivos para nenhum rótulo de reconhecimento de dispositivo ser retornado. | Que o seu próprio backend pode reagir ao resultado. Um rótulo ausente não identifica, por si só, um emulador, e não diz nada sobre a inscrição de ninguém. |
| Build instalado fora do Play | Campos diferentes respondem a isso: o reconhecimento do app, para a correspondência de pacote e certificado, e o licenciamento, que pode reportar sem licença quando a conta não tem direito ao app no Play. | Esses campos descrevem o reconhecimento do app e o direito de uso da conta. Leia-os separadamente: eles não são um registro completo de como a cópia atual foi instalada, e não inscrevem ninguém. |
Portanto, o resumo é estreito: o Play Integrity diz muito ao seu próprio backend sobre o ambiente em que o seu app roda, e nada nessa documentação diz que esses vereditos decidem quais testadores contam.
Um caminho prático e a recuperação depois dos emuladores
Trate os 14 dias como um beta de verdade, não como um obstáculo. Os passos abaixo combinam o processo publicado pelo Google com as nossas próprias recomendações: recrutar acima do mínimo e organizar o feedback dessa forma são sugestões, não cotas extras do Google. O objetivo é um teste genuíno, não esperar o calendário avançar.
Recomendação da PrimeTestLabEnvie um App Bundle assinado, crie uma faixa de teste fechado e publique uma versão nela. Nada mais funciona até que uma versão esteja ativa nessa faixa.
Uma lista de e-mails serve para um grupo pequeno e conhecido; um Grupo do Google vinculado escala com mais facilidade. De qualquer forma, cada pessoa ainda precisa aceitar o link de participação por conta própria.
Conselho, não regra. As pessoas perdem o interesse, trocam de celular ou saem do teste, e um substituto não herda o histórico de ninguém: os 14 dias dele começam quando ele se inscreve. Recrutar 15 a 30 pessoas dá folga.
Dê aos testadores algo específico para experimentar e um lugar fácil para relatar. Nenhuma cota de sessões diárias ou de capturas de tela é publicada, então não fabrique atividade.
Publique as mudanças que os testes justificaram e mantenha um registro curto do que foi relatado e do que você fez. Nenhum número obrigatório de atualizações é publicado, então não publique mudanças só para cumprir uma suposta cota de atualizações.
O formulário pergunta como você conduziu o teste e engajou os testadores, o que é o app e para quem ele é, e o que você mudou como resultado. Responda com base nas suas anotações. A análise costuma levar sete dias ou menos, mas pode demorar mais.
Se você já rodou o seu teste em emuladores
-
Abra a lista de verificação do acesso de produção no seu Painel e leia o que ela diz: quantos testadores, quantos dias contínuos. Esse é o estado real do seu teste.
-
Percorra a lista de diagnóstico acima para qualquer pessoa inscrita que não esteja aparecendo como você espera. Corrija a configuração antes de concluir qualquer coisa sobre dispositivos.
-
Mantenha o progresso que você tem legitimamente. Nada do que o Google publica diz que um teste é zerado por causa do ambiente que um testador usou.
-
Adicione participantes genuínos e deixe cada novo testador completar os próprios 14 dias consecutivos de participação. O tempo dele não herda o de ninguém, então o teste pode precisar ir além da data final que você tinha em mente. Se o seu app tiver problemas reais, esta também é a parte que os encontra.
Se recrutar pessoas é a parte difícil, comece pelas opções gratuitas em sete formas legítimas de encontrar 12 testadores. A partir daí: como convidar testadores, a regra dos 14 dias consecutivos, como atualizar o app durante o teste e o questionário de acesso de produção.
Participação genuína e o que quebra as regras
Boa parte do medo aqui vem de misturar três ações muito diferentes. Elas não são a mesma coisa, e as consequências delas também não.
Instalar o seu próprio build em um emulador para verificar se ele compila, roda e tem a aparência certa é engenharia normal, na ferramenta que o Google distribui para isso. Não é engano, e não é o alvo da fiscalização.
Este é o caso que os desenvolvedores nos pedem para resgatar depois que deu errado. O Google não publica nenhuma regra de contagem de emuladores, então não podemos dizer que isso é contra as regras. O que podemos dizer é o que nós fazemos: não montamos um teste dessa forma e desaconselhamos. O acesso de produção é julgado com base em evidências de um teste real, e, na nossa experiência, um grupo montado com dispositivos virtuais é o tipo que é devolvido para mais testes, ou rejeitado.
Criar contas Google falsas e aceitar participar a partir delas, em emuladores ou em qualquer outra coisa, é um ato completamente diferente. A política do Google sobre classificações, avaliações e instalações proíbe tentar manipular posicionamento, classificações, avaliações ou números de instalação por meios ilegítimos.
Então a linha prática é sobre engano, não sobre virtualização: não crie contas nem automatize atividade para deturpar quem está participando. O Google proíbe a manipulação ilegítima de instalações e de outras métricas da loja. Essa política, por si só, não estabelece uma regra de contagem específica para emuladores.
Uma correção que vale a pena fazer: uma resposta de "mais testes necessários" não estabelece, por si só, uma ação de fiscalização contra a sua conta. Leia a mensagem específica e continue testando como ela orienta, em vez de inferir penalidades automáticas para análises futuras. O que fazer depois dessa negativa destrincha o assunto.
A conclusão prática é a mesma nos três casos. Um emulador não dá a você uma pessoa a mais, então a única pergunta que vale o seu tempo é como encontrar pessoas reais de forma eficiente.
Onde a PrimeTestLab entra
Aviso comercialNós vendemos ajuda com testes fechados, então leia esta seção sabendo disso. Os desenvolvedores recorrem a emuladores porque encontrar uma dúzia de pessoas que permaneçam participando por duas semanas é genuinamente difícil, não porque queiram trapacear. Essa é a parte que nós fazemos.
O que fazemos
Recrutamos e coordenamos 12 ou mais testadores reais, mantemos todos inscritos pelos 14 dias completos e substituímos quem desistir. O teste começa em cerca de 4-6 horas.
O que não vamos afirmar
Que algum serviço possa garantir a decisão do Google, ou que contratar testadores elimine a análise. O acesso de produção é julgado com base no seu teste e no seu app.
Se você prefere não pagar
É uma escolha totalmente razoável, e os caminhos gratuitos em sete formas legítimas de conseguir 12 testadores funcionam. Eles custam tempo em vez de dinheiro.
Todos os planos incluem garantia de reembolso. Você também pode ler o processo passo a passo antes de decidir.
Perguntas frequentes
Posso usar um emulador no teste fechado do Google Play?
Use um para testar o seu app: é para isso que o Google o desenvolve. O requisito publicado é de 12 testadores participando por 14 dias contínuos, e nenhuma documentação revisada aqui diz se um participante que usa emulador conta para ele. A nossa recomendação vai além da documentação: testar o seu build em um emulador não tem problema, usar instâncias de emulador como testadores substitutos não é algo que nós faríamos, e aceitar participar a partir de contas Google falsas é manipulação que pode levar à rejeição do acesso de produção.
Uma falha no Play Integrity significa que um testador não conta?
A documentação revisada para este guia não diz isso. O Play Integrity responde ao seu próprio app e backend sobre o ambiente em que o app está rodando, e o Google o documenta separadamente do requisito do teste fechado. Trate a cadeia que vai do veredito de integridade até a contagem de testadores como uma inferência, não como um processo publicado.
Preciso de 12 pessoas, 12 contas ou 12 celulares?
O requisito é escrito sobre testadores participando continuamente por 14 dias, o que na prática significa 12 pessoas com as próprias contas Google que aceitam o seu link de participação. Você não precisa ter doze celulares, e nenhuma documentação do Google exige hardware premium ou uma variedade de fabricantes. Se você mesmo pode ser um dos doze é um assunto tratado em usar as próprias contas como testadores.
Não tenho um celular Android. Ainda posso ajudar alguém a testar um app?
Querer ajudar não é engano, e é diferente de um desenvolvedor fabricando um grupo de testadores. Ninguém pode prometer honestamente como a sua participação será contada. Pegar um dispositivo Android emprestado é o caminho de menor risco; se você usar um emulador mesmo assim, avise o desenvolvedor para que ele possa se planejar.
Posso usar o BlueStacks no teste fechado do Google Play?
O BlueStacks documenta o login na Play Store, e uma imagem do Android Studio com Play Store também consegue chegar à loja. Isso confirma que o acesso à Play Store é possível, não que a sua versão de teste fechado específica estará disponível: isso ainda depende da conta, da faixa e da versão publicada. Também não resolve nada sobre elegibilidade, porque nenhuma documentação do Google declara se esse participante conta. Trate a página de um fornecedor como autoridade sobre aquele produto e nada mais, em nenhuma das direções.
A verificação de dispositivo do desenvolvedor é o mesmo que o teste fechado?
Não. A verificação de dispositivo é o titular da conta comprovando acesso a um dispositivo Android físico sem root, com Android 10 ou superior, na configuração da conta, e o Google pode pedi-la de novo mais tarde. O teste fechado trata de pessoas aceitando participar de uma faixa de teste. Outro ator, outro propósito, outra página de ajuda.
Desinstalar o app significa que o testador saiu do teste?
Desinstalar e sair do teste são ações diferentes. O requisito é escrito sobre o status contínuo de participação, então não presuma que uma desinstalação interrompe a janela ou que uma pessoa saindo zera as outras. Se o progresso parecer errado, confira primeiro a lista de verificação do acesso de produção e as inscrições.
Conclusão
Resumo
Emuladores são uma ferramenta de teste legítima e um substituto ruim para participantes. O requisito é de 12 testadores participando por 14 dias contínuos, e a documentação revisada aqui não especifica se um participante que usa emulador conta. Então abra a sua lista de verificação do acesso de produção, percorra as verificações de configuração antes de culpar o hardware e use o restante da janela para recrutar pessoas que vão realmente usar o app. A nossa recomendação, que a documentação não precisa declarar por nós: fabricar participação com emuladores ou contas falsas não vale o risco de rejeição. Comece pelas formas gratuitas de encontrar 12 testadores →
Documentação oficial do Google
Discussão da comunidade, não documentação
A resposta recomendada ali aconselha usar outras pessoas em dispositivos Android físicos em vez de emuladores, e um Especialista em Produtos a endossou, o que vale a pena saber. Ainda assim, é discussão da comunidade: nenhuma política é citada, e a página avisa que o conteúdo pode não ter sido verificado.