En bref
Un émulateur peut-il compter parmi les 12 testeurs ?L’exigence parle de testeurs et d’inscription continue, pas d’un type d’appareil
Utilisez un émulateur pour tester votre application. N’utilisez pas d’émulateurs pour fabriquer les participants de votre test fermé. L’exigence publiée par Google est de 12 testeurs inscrits pendant 14 jours sans interruption, et ni les exigences ni la documentation technique consultées pour ce guide ne précisent si une participation depuis un émulateur compte dans ce minimum. Notre propre recommandation, tirée des tests que nous menons pour des développeurs, est plus tranchée que la documentation n’a besoin de l’être : exécuter votre version sur un émulateur relève du développement ordinaire et ne pose aucun problème ; faire tenir à des instances d’émulateur le rôle des douze personnes n’est pas un raccourci que nous prendrions ; et créer de faux comptes Google pour s’inscrire depuis ces instances est une manipulation, et d’après notre expérience le genre de test qui est renvoyé pour tests supplémentaires ou refusé. Suivez votre progression dans Play Console et recrutez des personnes qui utiliseront l’application et vous diront ce qu’elles ont constaté.
| La question | Ce qui la tranche | Où trouver la réponse |
|---|---|---|
| Un émulateur peut-il exécuter mon application et m’aider à la tester ? | L’image système que vous choisissez, et l’application elle-même. | La documentation de l’émulateur Android Studio. C’est précisément à cela que sert l’outil. |
| Un testeur peut-il y ouvrir ma version fermée ? | Le compte Google, l’acceptation ou non de l’inscription, la version publiée et les restrictions que vous avez définies. | La configuration du test dans Play Console. Éligibilité du compte, disponibilité de la version, compatibilité et contrôles d’appareil que vous avez configurés. |
| Que rapporte Play Integrity à son sujet ? | L’état de l’appareil, la version d’Android et les champs que votre propre application ou votre backend lit. | La documentation de Play Integrity. Elle répond à votre application et à votre backend ; Play Console en rend compte séparément. |
| Cette personne compte-t-elle parmi les 12 ? | Le fait qu’un testeur soit inscrit à votre test fermé, sans interruption, pendant 14 jours. | L’exigence de test, qui ne dit rien du type d’appareil ni de l’intégrité. |
Dans ce guide
Ce que Google exige, et à qui cela s’applique
Exigence GoogleL’aide de Play Console indique qu’un développeur disposant d’un compte personnel créé après le 13 novembre 2023 doit mener un test fermé avant de publier en production, avec au moins 12 testeurs inscrits sans interruption pendant au moins 14 jours (exigences de test des applications). Tant que ce n’est pas le cas, les canaux Production et Préinscription restent verrouillés. Remplir cette condition vous rend éligible pour faire la demande ; l’approbation relève d’un examen distinct. Les comptes d’organisation ne sont pas soumis à cette règle. L’exigence elle-même est détaillée dans notre guide sur l’exigence des 12 testeurs.
Pour un compte de développeur personnel créé après le 13 novembre 2023, l’application doit passer par un test fermé avec au moins 12 testeurs inscrits sans interruption pendant 14 jours avant que le développeur puisse demander l’accès en production.
Google précise aussi ce que signifie sans interruption. Les testeurs qui s’inscrivent, testent moins de 14 jours puis se désinscrivent ne comptent pas pour l’exigence, et si quelqu’un se réinscrit plus tard, les 14 jours doivent toujours être consécutifs. Le minimum était de 20 jusqu’à ce que Google l’abaisse à 12 le 11 décembre 2024, un changement ajouté à son annonce de 2023. La durée de 14 jours n’a pas changé.
Lisez l’exigence telle qu’elle est écrite : elle porte sur le statut d’inscription
Observez les noms que l’exigence emploie, et ceux qu’elle n’emploie pas. Elle parle de testeurs et d’inscription continue, pas d’un modèle d’appareil, d’un état de certification ni d’un verdict d’intégrité. Deux contresens en découlent. Désinstaller n’est pas la même action que se désinscrire : une désinstallation n’interrompt donc pas automatiquement la période. Et le départ d’une personne ne remet pas les autres à zéro : la continuité est suivie inscription par inscription.
La vérification de l’appareil du développeur est une autre démarche
Google exige bien un appareil Android physique à un endroit précis, et il est facile de le confondre avec une règle sur les testeurs. Les nouveaux comptes de développeur personnels doivent effectuer une vérification de l’appareil sur un appareil Android physique non rooté sous Android 10 ou version ultérieure, connecté avec le compte du titulaire (exigences de vérification de l’appareil). Google indique qu’une nouvelle vérification peut vous être demandée plus tard, pas nécessairement sur le même appareil. Dans tous les cas, c’est le titulaire du compte qui prouve qu’il a accès à un appareil, et cela ne dit rien de ce qu’utilisent vos testeurs.
L’exigence vous concerne-t-elle seulement ?
Elle s’applique aux comptes personnels créés après le 13 novembre 2023. Les comptes personnels plus anciens et les comptes d’organisation n’y sont pas soumis : « passez à un compte d’organisation » relève donc d’une différence d’éligibilité, pas d’un contournement astucieux. Un compte d’organisation exige une organisation enregistrée que Google vérifie, généralement au moyen d’un numéro D-U-N-S, qui peut être demandé sans frais. Nous comparons les deux dans compte Google Play personnel ou d’organisation.
Les émulateurs comptent-ils parmi les 12 testeurs ?
Rien dans la documentation consultée ici n’y répond par oui ou par non, et c’est pourquoi la suite de ce guide sépare ce qui est énoncé de ce qui est déduit. Chaque affirmation relève de l’une de quatre catégories, et l’erreur habituelle consiste à faire discrètement passer une affirmation d’une catégorie inférieure à une catégorie supérieure.
Une règle à satisfaire : 12 testeurs, 14 jours sans interruption, la date limite du 13 novembre 2023, et le fait que la remplir vous permet de faire la demande.
Des descriptions exactes de comportements : verdicts d’intégrité, images système, configuration des tests. Écrites dans un autre but que de décider qui compte.
Des fils de discussion sur la communauté des développeurs Google Play et sur Reddit. La réponse recommandée dans le fil que nous citons conseille de faire appel à d’autres personnes sur des appareils Android physiques plutôt qu’à des émulateurs. À lire, mais la page avertit que le contenu peut ne pas être vérifié, et un nom de domaine Google n’est pas une règle.
Notre propre jugement : recrutez au-delà du minimum, et ne fabriquez pas de participation avec des émulateurs ou de faux comptes. Un conseil issu de notre pratique, pas une règle, et nous vendons de l’aide au test.
Documenté et citable sans risque
Énoncé dans les règles, les pages d’aide ou la documentation pour les développeurs de Google.
- L’exigence elle-même : 12 testeurs inscrits pendant 14 jours sans interruption, pour les comptes personnels créés après le 13 novembre 2023.
- La demande d’accès en production interroge sur le déroulement du test, la nature de l’application et ce que vous avez modifié grâce aux tests.
- Le Règlement du programme pour les développeurs interdit de manipuler le classement, les notes, les avis ou le nombre d’installations par des moyens illégitimes.
- Google recommande de tester sur du matériel physique avant la sortie, et documente le test sur émulateur à travers les versions d’Android et les tailles d’écran.
Non précisé : ne présumez rien
Plausible, et pourtant absent de la documentation consultée ici.
- Qu’un verdict Play Integrity décide si un testeur compte parmi les 12.
- Tout signal de détection nommé : bruit de l’accéléromètre, variance de la température de la batterie, dérive du GPS, télémétrie tactile, regroupement d’adresses IP ou ancienneté du compte.
- Tout chiffre précis du type « X % des émulateurs sont détectés ». Traitez les pourcentages exacts comme non étayés plutôt que comme des mesures.
- Un délai de remontée universel, un nombre requis de sessions quotidiennes ou un nombre requis de mises à jour pendant la période.
Testeurs inscrits, audience installée et accès en production
L’essentiel de ce débat porte en réalité sur trois chiffres de Play Console que l’on traite comme interchangeables. Ils ne le sont pas.
| Ce que vous regardez | Ce que cela signifie | Ce que cela ne vous dit pas |
|---|---|---|
| Testeurs inscrits | Les comptes qui ont accepté le lien d’activation de ce canal. C’est le nom autour duquel l’exigence est rédigée, avec la durée pendant laquelle ils restent inscrits. | Si quelqu’un a installé l’application, l’a ouverte ou vous a fait un retour utile. |
| Audience installée | Google la définit comme les utilisateurs ayant votre application installée sur au moins un appareil utilisé au cours des 30 derniers jours. C’est l’appareil qui doit avoir été utilisé, pas nécessairement l’application. | C’est une mesure d’audience, pas le compteur de l’accès en production, ni un décompte d’appareils ayant réussi un contrôle de sécurité. |
| La liste de contrôle de l’accès en production | L’élément du tableau de bord qui indique combien de testeurs sont inscrits, et depuis combien de jours sans interruption. C’est sur cela que l’exigence est mesurée. | Pourquoi une personne précise y figure ou non. Pour cela, vérifiez les inscriptions. |
Atteindre le minimum n’équivaut pas à un test convaincant. Google peut demander des tests supplémentaires lorsque l’engagement des testeurs est insuffisant, même une fois 12 testeurs inscrits pendant 14 jours sans interruption. Il ne publie aucun quota de sessions quotidiennes : l’objectif est un test qui a produit une utilisation réelle et des retours réels, pas une activité fabriquée pour paraître soutenue.
Installer en dehors de Play est un chemin distinct, et il n’inscrit personne. Un Android App Bundle est un format de publication, pas un fichier installable : ce qui s’installe par cette voie est un APK généré à partir de celui-ci. Et quelle que soit la manière dont le fichier arrive (installation manuelle, lien partagé, partage interne d’applications), cela ne fait accepter votre lien d’activation à personne.
Un écart entre deux de ces chiffres est un symptôme, pas un diagnostic. Douze inscriptions avec une audience installée faible a des explications ordinaires : des personnes se sont inscrites sans jamais installer l’application, elles l’ont installée sur un appareil qu’elles n’ont pas utilisé récemment, les rapports ont du retard, ou la version ne leur est pas disponible.
Ce que nous pouvons et ne pouvons pas vous dire ici
Google publie l’exigence de test et les définitions de ces indicateurs, mais pas l’explication de chaque résultat de comptage individuel, ni un délai de remontée universel. Lisez la documentation de l’indicateur concerné, distinguez un délai observé d’une garantie publiée, et suivez la liste de vérification ci-dessous.
Si un testeur ne trouve pas ou ne peut pas installer votre version fermée
Vérifiez ces problèmes de configuration avant d’attribuer le problème à l’environnement. Ils concernent aussi bien les appareils physiques que les émulateurs.
-
01
Le mauvais compte Google
Le compte qui a accepté le lien d’activation doit être celui qui est connecté sur l’appareil et sélectionné dans le Play Store. Sur un téléphone avec plusieurs comptes Google, vérifiez cela en premier quand quelqu’un signale « application non disponible ».
-
02
L’inscription n’a jamais été finalisée
Votre liste d’adresses e-mail ou votre groupe Google associé rend une personne éligible ; il ne l’inscrit pas. Elle doit encore ouvrir le lien d’activation et l’accepter, et l’appartenance à un groupe peut mettre un peu de temps à prendre effet. Une version fermée n’apparaît pas non plus dans la recherche du Play Store : les testeurs y accèdent par le lien d’activation et le lien vers la fiche que vous leur donnez.
-
03
Un canal en conflit
Si le compte figure aussi dans votre test interne, demandez à la personne de quitter ce test avant de s’inscrire au test fermé. Lorsque des canaux se chevauchent, un utilisateur éligible reçoit le code de version compatible le plus élevé qui lui est disponible, et ce n’est pas forcément la version que vous surveillez (configuration des tests).
-
04
Aucune version active sur ce canal
Un canal fermé a besoin d’une version publiée et réellement déployée, avec le numéro de version et le pourcentage que vous croyez. Un brouillon n’est distribué à personne. Un déploiement interrompu arrête toute nouvelle distribution, mais les testeurs qui avaient déjà reçu cette version peuvent toujours l’avoir installée : vérifiez donc quelle version est réellement servie. Google précise aussi qu’un nouveau lien de test, et ses modifications ultérieures, peuvent mettre quelques heures à devenir disponibles.
-
05
Vos propres paramètres de disponibilité
La disponibilité par pays et les restrictions d’appareils relèvent de vos réglages. Pour les pays, Google se base sur le pays du compte Google Play du testeur, qui n’est pas toujours l’endroit où il se trouve. Et si vous avez activé les contrôles d’appareils de la fiche Play Store fondés sur l’intégrité, ils peuvent empêcher certains appareils de voir ou d’installer l’application : une restriction d’accès que vous avez configurée, pas une preuve de quels testeurs comptent.
-
06
L’environnement ou la version elle-même
Seulement après les cinq points précédents. Un émulateur avec la mauvaise image système ne peut tout simplement pas se connecter au Play Store, et Android Studio publie les problèmes connus de certaines images.
-
07
C’est votre application qui bloque, pas le Play Store
Si le téléchargement fonctionne et que l’application refuse ensuite de s’exécuter, c’est votre propre contrôle qui s’applique, pas la disponibilité sur Play. Vérifiez ce que votre application ou votre backend fait de la réponse de Play Integrity avant de conclure que le testeur ne peut pas obtenir votre version.
Si le décompte semble toujours faux, nous avons des guides dédiés : testeurs ajoutés mais aucun inscrit, l’application n’est pas disponible pour un testeur et accès des testeurs via un groupe Google. Chacun couvre les causes de configuration courantes et les vérifications supplémentaires à effectuer.
Quand le test sur émulateur est utile
Les émulateurs sont de bons outils, et Google en fabrique un. Il est livré avec Android Studio, et Google recommande de tester sur plusieurs versions d’Android et tailles d’écran. L’erreur n’est pas d’utiliser un émulateur ; c’est d’attendre de lui un travail pour lequel il n’a jamais été conçu.
Recommandation PrimeTestLabItérer vite pendant le développement. Des versions d’Android et des tailles d’écran que vous ne possédez pas. Tablettes, langues, mode sombre, mises en page de droite à gauche. Reproduire un plantage à la demande.
Un jugement indépendant. Une machine qui fait tourner cinq appareils virtuels reste l’avis d’une seule personne.
Le comportement de l’application sur le matériel que les gens possèdent : performances, batterie, appareil photo, notifications, changements de réseau, version d’Android propre au fabricant. Google recommande de tester sur du matériel avant la sortie.
Une garantie d’éligibilité. De bons téléphones ne satisfont pas une exigence rédigée à propos de testeurs.
Ce que l’outillage ne peut pas fournir : quelqu’un qui s’inscrit, garde l’application installée, essaie les parcours auxquels vous n’aviez pas pensé et vous dit ce qui l’a dérouté.
La couverture des appareils. Douze testeurs peuvent posséder des téléphones similaires, et c’est pour cela que les vérifications sur émulateur gardent toute leur place.
Images Android Studio, images avec Play et BlueStacks
Tous les émulateurs ne se valent pas, et la différence tient à l’image système. Une image AOSP n’a aucune application Google. Une image Google APIs ajoute les services Google, mais pas le Play Store. Une image Google Play inclut le Play Store, et Android Studio marque du logo Play les profils d’appareil qui la prennent en charge, en documentant ces profils de téléphone comme conformes CTS. Le profil et l’image système sont deux choix distincts à la création de l’appareil virtuel, et il vous faut l’image Play pour vous connecter et installer à l’intérieur. BlueStacks documente aussi la connexion au Play Store. Rien de tout cela ne règle la question de l’éligibilité : atteindre le Play Store et être compté comme testeur sont deux résultats distincts.
Si vous n’avez pas de téléphone Android mais voulez aider quelqu’un à tester
La situation est différente de celle d’un développeur qui fabrique une cohorte, et elle mérite une réponse franche plutôt qu’une accusation. Aider un ami à tester sur la machine que vous possédez n’est pas une tromperie. Ce que personne ne peut vous promettre, c’est le résultat, parce que Google ne publie pas la manière dont chaque participant est compté. Si cela a de l’importance, empruntez un téléphone Android ou utilisez un ancien modèle compatible. Si vous utilisez malgré tout un émulateur, dites-le au développeur pour qu’il puisse organiser son test en conséquence.
Laboratoires d’appareils dans le cloud et rapports pré-lancement
Firebase Test Lab exécute votre application sur des appareils de l’infrastructure de Google, et le rapport pré-lancement de Play Console explore automatiquement votre version. Les deux sont des outils d’assurance qualité automatisée parfaitement légitimes. Aucun n’est un participant : une exécution automatisée ne s’inscrit pas, ne reste pas inscrite 14 jours et ne vous dit pas que l’écran d’accueil n’avait aucun sens.
Ce que Play Integrity établit, et ce qu’il n’établit pas
Documentation technique GooglePlay Integrity est la technologie sur laquelle repose l’essentiel de ce débat ; il vaut donc la peine de savoir à quoi elle sert. Selon developer.android.com, l’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 » (verdicts d’intégrité). Le destinataire de cette réponse est votre application et votre propre backend. Play Console vous remonte aussi les réponses d’intégrité, et un paramètre distinct de la fiche Play Store peut restreindre les appareils autorisés à installer. Rien de tout cela n’est l’exigence du test fermé, et rien ne doit être lu comme tel.
« The app is running on a genuine and certified Android device. » Sur Android 13 et versions ultérieures, cela s’accompagne d’une preuve matérielle que le bootloader est verrouillé et que le système est une image certifiée du fabricant ; les versions antérieures peuvent reposer sur une évaluation logicielle.
L’apparence de l’appareil pour l’API. Pas une affirmation sur l’inscription.Documenté comme un appareil présentant des « signs of attack (such as API hooking) or system compromise (such as being rooted) », ou une application « not running on a physical device (such as an emulator that does not pass Google Play integrity checks) ». Le champ peut porter plusieurs libellés : il s’agit donc d’un libellé absent, pas d’une valeur qui s’appellerait « vide ».
Il couvre plusieurs situations différentes et ne peut donc pas être lu à rebours vers une cause unique.« The app is running on a device that passes basic system integrity checks. The device may not be certified. » Facultatif signifie ici que le développeur choisit de recevoir ou non ce libellé, ce qui n’a rien à voir avec l’inscription d’un testeur.
Un paramètre de réponse, pas une inscription.« The app is running on a genuine and certified Android device with a recent security update. » Sur Android 13 et versions ultérieures, cela signifie l’intégrité de l’appareil plus des mises à jour de sécurité récentes sur les partitions concernées ; Android 12 et versions antérieures sont évaluées sur l’intégrité matérielle du démarrage, sans le même critère de mise à jour récente.
Une barre haute pour votre propre backend. Pas un seuil du test fermé.Documenté pour un « Android-powered emulator with Google Play services », dans le contexte de Google Play Games on PC, une surface de distribution qui a ses propres exigences.
Pas un verdict sur les émulateurs de test d’Android Studio, dans un sens comme dans l’autre.Appareil, reconnaissance de l’application et licence sont des champs distincts
Trois champs sont cités comme s’ils n’en faisaient qu’un, et c’est en les mélangeant que naît l’essentiel de la confusion. Le champ appareil décrit l’environnement. Le champ reconnaissance de l’application indique si le binaire en cours d’exécution correspond à ce que Google Play a distribué. Le champ licence décrit le droit d’utilisation et peut signaler une absence de licence lorsque le compte n’a aucun droit Play pour l’application. Une version installée en dehors de Play relève de la licence et de la distribution, pas d’un verdict matériel.
Ces exemples expliquent la terminologie. Rien ici ne contacte Google, ne mesure votre appareil, ne vérifie une participation ni ne prédit l’accès en production. Les réponses réelles dépendent de l’application, de sa configuration et de l’environnement.
| Environnement | Ce qu’une réponse peut afficher | Ce que cela vous dit, et ce que cela ne vous dit pas |
|---|---|---|
| Téléphone certifié, bootloader verrouillé | Le champ appareil peut inclure MEETS_DEVICE_INTEGRITY, et MEETS_STRONG_INTEGRITY avec une mise à jour de sécurité récente. | Que l’appareil satisfait l’API. Pas si cette personne a accepté votre lien d’activation. |
| Émulateur Android Studio standard | Google documente un émulateur qui ne passe pas les contrôles Play comme l’une des raisons pour lesquelles aucun libellé de reconnaissance d’appareil n’est renvoyé. | Que votre propre backend peut réagir au résultat. Un libellé absent n’identifie pas à lui seul un émulateur, et il ne dit rien de l’inscription de qui que ce soit. |
| Version installée en dehors de Play | D’autres champs répondent à cela : la reconnaissance de l’application pour la correspondance du package et du certificat, et la licence, qui peut signaler une absence de licence lorsque le compte n’a aucun droit Play. | Ces champs décrivent la reconnaissance de l’application et les droits du compte. Lisez-les séparément : ils ne constituent pas un historique complet de la façon dont la copie actuelle a été installée, et ils n’inscrivent personne. |
Le résumé est donc étroit : Play Integrity en dit beaucoup à votre propre backend sur l’environnement dans lequel votre application s’exécute, et rien dans cette documentation ne dit que ces verdicts décident quels testeurs comptent.
Une méthode concrète, et comment se rattraper après des émulateurs
Considérez les 14 jours comme une vraie bêta plutôt que comme un obstacle. Les étapes ci-dessous combinent le processus publié par Google et nos propres recommandations : recruter au-delà du minimum et organiser les retours de cette manière sont des suggestions, pas des quotas Google supplémentaires. L’objectif est un vrai test, pas une attente que le calendrier avance.
Recommandation PrimeTestLabImportez un App Bundle signé, créez un canal de test fermé et publiez-y une version. Rien d’autre ne fonctionne tant qu’une version n’est pas active sur ce canal.
Une liste d’adresses e-mail convient à un petit groupe connu ; un groupe Google associé s’adapte plus facilement. Dans les deux cas, chaque personne accepte encore elle-même le lien d’activation.
Un conseil, pas une règle. Les gens se lassent, changent de téléphone ou se désinscrivent, et un remplaçant n’hérite de l’historique de personne : ses 14 jours commencent à son inscription. Recruter 15 à 30 personnes vous laisse de la marge.
Donnez aux testeurs quelque chose de précis à essayer et un moyen simple de vous répondre. Aucun quota de sessions quotidiennes ni de captures d’écran n’est publié : ne fabriquez donc pas d’activité.
Publiez les changements que les tests ont justifiés, et gardez une trace courte de ce qui a été signalé et de ce que vous avez fait. Aucun nombre de mises à jour requis n’est publié : ne publiez donc pas de changements uniquement pour respecter un quota supposé.
Le formulaire demande comment vous avez mené le test et mobilisé les testeurs, ce qu’est l’application et à qui elle s’adresse, et ce que vous avez modifié en conséquence. Répondez à partir de vos notes. L’examen prend généralement sept jours ou moins, et il peut durer plus longtemps.
Si vous avez déjà mené votre test sur des émulateurs
-
Ouvrez la liste de contrôle de l’accès en production sur votre tableau de bord et lisez ce qu’elle indique : combien de testeurs, combien de jours sans interruption. C’est l’état réel de votre test.
-
Parcourez la liste de diagnostic ci-dessus pour toute personne inscrite qui n’apparaît pas comme vous l’attendez. Corrigez la configuration avant de conclure quoi que ce soit sur les appareils.
-
Conservez la progression que vous avez légitimement acquise. Rien de ce que Google publie ne dit qu’un test est remis à zéro à cause de l’environnement utilisé par un testeur.
-
Ajoutez de vrais participants et laissez chaque nouveau testeur accomplir ses propres 14 jours consécutifs d’inscription. Son temps n’hérite de celui de personne, et le test peut donc devoir se prolonger au-delà de la date de fin que vous aviez en tête. Si votre application a de vrais problèmes, c’est aussi l’étape qui les révèle.
Si le recrutement est la partie difficile, commencez par les options gratuites de sept moyens légitimes de trouver 12 testeurs. Ensuite : comment inviter des testeurs, la règle des 14 jours consécutifs, mettre à jour votre application pendant le test et le questionnaire d’accès en production.
Participation réelle et ce qui enfreint vraiment les règles
Une grande partie de la crainte vient ici de la confusion entre trois actions très différentes. Elles ne sont pas les mêmes, et leurs conséquences non plus.
Installer votre propre version sur un émulateur pour vérifier qu’elle compile, s’exécute et s’affiche correctement est de l’ingénierie normale, sur l’outil que Google fournit pour cela. Ce n’est pas une tromperie, et ce n’est pas ce que visent les sanctions.
C’est le cas que les développeurs nous demandent de rattraper une fois que cela a mal tourné. Google ne publie aucune règle de comptage des émulateurs, nous ne pouvons donc pas vous dire que c’est contraire aux règles. Nous pouvons vous dire ce que nous faisons : nous ne construisons pas de test de cette manière, et nous le déconseillons. L’accès en production est jugé sur les preuves d’un vrai test, et d’après notre expérience, une cohorte assemblée à partir d’appareils virtuels est le genre de test qui est renvoyé pour tests supplémentaires, ou refusé.
Créer de faux comptes Google et s’inscrire depuis ceux-ci, sur des émulateurs ou sur n’importe quoi d’autre, est un acte tout à fait différent. Le règlement de Google sur les notes, les avis et les installations interdit de tenter de manipuler le classement, les notes, les avis ou le nombre d’installations par des moyens illégitimes.
La ligne pratique porte donc sur la tromperie, pas sur la virtualisation : ne créez pas de comptes et n’automatisez pas d’activité pour travestir qui participe. Google interdit la manipulation illégitime des installations et des autres indicateurs de la boutique. Ce règlement n’établit pas, à lui seul, une règle de comptage propre aux émulateurs.
Une correction mérite d’être faite : une réponse « tests supplémentaires requis » n’établit pas à elle seule une mesure d’application contre votre compte. Lisez le message précis et continuez à tester comme il l’indique, plutôt que d’en déduire des pénalités automatiques pour les examens futurs. Que faire après ce refus détaille la marche à suivre.
La conclusion pratique est la même dans les trois cas. Un émulateur ne vous donne pas une personne de plus : la seule question qui mérite votre temps est donc comment en trouver de vraies, efficacement.
Le rôle de PrimeTestLab
Transparence commercialeNous vendons de l’aide au test fermé, lisez donc cette section en le sachant. Les développeurs se tournent vers les émulateurs parce que trouver une douzaine de personnes qui resteront inscrites pendant deux semaines est réellement difficile, pas parce qu’ils veulent tricher. C’est cette partie que nous prenons en charge.
Ce que nous faisons
Recruter et coordonner 12 vrais testeurs ou plus, les garder inscrits pendant les 14 jours complets et remplacer toute personne qui abandonne. Le test démarre en de 4 à 6 heures environ.
Ce que nous ne prétendrons pas
Qu’un service, quel qu’il soit, puisse garantir la décision de Google, ou que faire appel à des testeurs supprime l’examen. L’accès en production est jugé sur votre test et votre application.
Si vous préférez ne pas payer
C’est un choix parfaitement raisonnable, et les voies gratuites de sept moyens légitimes d’obtenir 12 testeurs fonctionnent. Elles coûtent du temps plutôt que de l’argent.
Chaque formule inclut une garantie de remboursement. Vous pouvez aussi lire le processus étape par étape avant de décider.
Questions fréquentes
Peut-on utiliser un émulateur pour le test fermé Google Play ?
Utilisez-en un pour tester votre application : c’est pour cela que Google le fournit. L’exigence publiée est de 12 testeurs inscrits pendant 14 jours sans interruption, et aucune documentation consultée ici ne dit si un participant sur émulateur compte pour ce minimum. Notre propre recommandation va plus loin que la documentation : tester votre version sur un émulateur ne pose aucun problème, utiliser des instances d’émulateur comme testeurs de substitution n’est pas quelque chose que nous ferions, et s’inscrire depuis de faux comptes Google est une manipulation qui peut faire refuser l’accès en production.
Un échec Play Integrity signifie-t-il qu’un testeur ne compte pas ?
La documentation consultée pour ce guide ne le dit pas. Play Integrity renseigne votre propre application et votre backend sur l’environnement dans lequel l’application s’exécute, et Google la documente séparément de l’exigence du test fermé. Considérez l’enchaînement du verdict d’intégrité au décompte des testeurs comme une déduction, pas comme un processus publié.
Me faut-il 12 personnes, 12 comptes ou 12 téléphones ?
L’exigence est rédigée à propos de testeurs inscrits sans interruption pendant 14 jours, ce qui signifie en pratique 12 personnes disposant chacune de leur propre compte Google et acceptant votre lien d’activation. Vous n’avez pas besoin de posséder douze téléphones, et aucune documentation Google n’exige du matériel haut de gamme ni un éventail de fabricants. La question de savoir si vous pouvez être vous-même l’un des douze est traitée dans utiliser vos propres comptes comme testeurs.
Je n’ai pas de téléphone Android. Puis-je quand même aider quelqu’un à tester son application ?
Vouloir aider n’est pas une tromperie, et c’est différent d’un développeur qui fabrique une cohorte. Personne ne peut honnêtement vous promettre la manière dont votre participation sera comptée. Emprunter un appareil Android est la voie la moins risquée ; si vous utilisez malgré tout un émulateur, dites-le au développeur pour qu’il puisse s’organiser en conséquence.
Peut-on utiliser BlueStacks pour le test fermé Google Play ?
BlueStacks documente la connexion au Play Store, et une image Android Studio avec Play peut aussi atteindre le Play Store. Cela confirme que l’accès au Play Store est possible, pas que votre version fermée en particulier sera disponible : cela dépend toujours du compte, du canal et de la version. Cela ne règle pas non plus l’éligibilité, car aucune documentation Google ne précise si un tel participant compte. Considérez la page d’un éditeur comme une référence sur ce produit et rien de plus, dans un sens comme dans l’autre.
La vérification de l’appareil du développeur est-elle la même chose que le test fermé ?
Non. La vérification de l’appareil consiste, pour le titulaire du compte, à prouver l’accès à un appareil Android physique non rooté sous Android 10 ou version ultérieure, à la création du compte, et Google peut la redemander plus tard. Le test fermé concerne des personnes qui s’inscrivent à un canal de test. Autre acteur, autre objectif, autre page d’aide.
Désinstaller l’application signifie-t-il qu’un testeur a quitté le test ?
Désinstaller et se désinscrire sont deux actions différentes. L’exigence est rédigée à propos d’un statut d’inscription continu : ne présumez donc pas qu’une désinstallation interrompt la période, ni que le départ d’une personne remet les autres à zéro. Si la progression semble incorrecte, vérifiez d’abord la liste de contrôle de l’accès en production et les inscriptions.
Conclusion
L’essentiel
Les émulateurs sont un outil de test légitime et un piètre substitut aux participants. L’exigence est de 12 testeurs inscrits pendant 14 jours sans interruption, et la documentation consultée ici ne précise pas si un participant sur émulateur compte. Ouvrez donc votre liste de contrôle de l’accès en production, passez en revue les vérifications de configuration avant d’incriminer le matériel, et consacrez le reste de la période à recruter des personnes qui utiliseront vraiment l’application. Notre propre recommandation, que la documentation n’a pas à formuler à notre place : fabriquer de la participation avec des émulateurs ou de faux comptes ne vaut pas le risque de refus. Commencez par les moyens gratuits de trouver 12 testeurs →
Documentation officielle de Google
Discussion communautaire, pas de la documentation
La réponse recommandée y conseille de faire appel à d’autres personnes sur des appareils Android physiques plutôt qu’à des émulateurs, et un Product Expert l’a approuvée, ce qui mérite d’être su. Cela reste une discussion communautaire : aucun règlement n’est cité, et la page avertit que le contenu peut ne pas être vérifié.