De korte versie
Kan een emulator meetellen voor de 12 testers?De vereiste noemt testers en doorlopende aanmelding, geen apparaattype
Gebruik een emulator om je app te testen. Gebruik geen emulators om de deelnemers aan je gesloten test te fabriceren. De gepubliceerde vereiste van Google is 12 testers die 14 dagen doorlopend aangemeld zijn, en de vereisten en technische documentatie die voor deze gids zijn bekeken, leggen niet vast of deelname via een emulator meetelt voor dat minimum. Onze eigen aanbeveling, uit het uitvoeren van deze tests voor ontwikkelaars, is stelliger dan de documentatie hoeft te zijn: je build op een emulator draaien is gewone ontwikkeling en volkomen prima; emulatorinstanties de plaats laten innemen van de twaalf mensen is geen shortcut die wij zouden nemen; en nep-Google-accounts aanmaken om je daarmee aan te melden is manipulatie, en in onze ervaring precies het soort test dat wordt teruggestuurd of afgewezen. Controleer je voortgang in Play Console en werf mensen die de app gaan gebruiken en je vertellen wat ze tegenkwamen.
| De vraag | Wat het bepaalt | Waar het antwoord staat |
|---|---|---|
| Kan een emulator mijn app draaien en helpen testen? | De systeemimage die je kiest, en de app zelf. | De documentatie van de Android Studio-emulator. Daar is het gereedschap voor bedoeld. |
| Kan een tester mijn gesloten build erop openen? | Het Google-account, of de aanmelding is geaccepteerd, de gepubliceerde release en de beperkingen die je zelf hebt ingesteld. | De testconfiguratie in Play Console. Geschiktheid van het account, beschikbaarheid van de release, compatibiliteit en de apparaatcontroles die je hebt ingesteld. |
| Wat rapporteert Play Integrity erover? | De apparaatstatus, de Android-versie en de velden die je eigen app of backend uitleest. | De documentatie van Play Integrity. Die geeft antwoord aan je eigen app en backend; Play Console rapporteert er los daarvan over. |
| Telt die persoon mee voor de 12? | Of een tester 14 dagen lang doorlopend is aangemeld voor je gesloten test. | De testvereiste, die niets zegt over apparaattype of integriteit. |
In deze gids
Wat Google vereist, en voor wie het geldt
Google-vereisteVolgens de Play Console Help moet een ontwikkelaar met een persoonlijk account dat na 13 november 2023 is aangemaakt een gesloten test uitvoeren voordat de app naar productie kan, met minimaal 12 testers die minstens 14 dagen doorlopend aangemeld zijn (vereisten voor het testen van apps). Tot daaraan is voldaan, blijven Productie en Pre-registratie vergrendeld. Voldoe je eraan, dan kun je productietoegang aanvragen; de goedkeuring is een aparte beoordeling. Organisatorische accounts vallen niet onder de regel. De vereiste zelf wordt uitgelegd in de vereiste van 12 testers uitgelegd.
Voor een persoonlijk ontwikkelaarsaccount dat na 13 november 2023 is aangemaakt, heeft de app een gesloten test nodig met minimaal 12 testers die 14 dagen doorlopend aangemeld zijn, voordat de ontwikkelaar productietoegang kan aanvragen.
Google legt ook uit wat doorlopend betekent. Testers die zich aanmelden, minder dan 14 dagen testen en zich dan afmelden, tellen niet mee voor de vereiste, en als iemand zich later opnieuw aanmeldt, moeten de 14 dagen nog steeds aaneengesloten zijn. Het minimum was 20 totdat Google het op 11 december 2024 verlaagde naar 12, de wijziging die het toevoegde aan zijn aankondiging uit 2023. De duur van 14 dagen veranderde niet.
Lees de vereiste zoals die er staat: het gaat om aanmeldstatus
Let op welke begrippen de vereiste gebruikt en welke niet. Ze noemt testers en doorlopende aanmelding, geen apparaatmodel, certificeringsstatus of integriteitsverdict. Daaruit volgen twee misverstanden. De app verwijderen is niet dezelfde handeling als je afmelden, dus een verwijdering betekent niet automatisch een onderbroken periode. En als één persoon vertrekt, begint de teller van de anderen niet opnieuw: continuïteit wordt per aanmelding bijgehouden.
Apparaatverificatie van de ontwikkelaar is een andere taak
Op één plek vereist Google wél een fysiek Android-apparaat, en dat is makkelijk aan te zien voor een testerregel. Nieuwe persoonlijke ontwikkelaarsaccounts moeten apparaatverificatie doorlopen op een niet-geroot fysiek Android-apparaat met Android 10 of hoger, ingelogd als de accounteigenaar (vereisten voor apparaatverificatie). Google zegt dat je later opnieuw om verificatie gevraagd kunt worden, niet per se op hetzelfde apparaat. Hoe dan ook bewijst de accounteigenaar daarmee toegang tot een apparaat, en het zegt niets over wat je testers gebruiken.
Geldt de vereiste überhaupt voor jou?
Ze geldt voor persoonlijke accounts die na 13 november 2023 zijn aangemaakt. Oudere persoonlijke accounts en organisatorische accounts vallen erbuiten, dus ‘neem een organisatorisch account’ is een verschil in geschiktheid, geen slimme omweg. Een organisatorisch account vereist een geregistreerde organisatie die Google verifieert, meestal met een D-U-N-S-nummer, dat kosteloos kan worden aangevraagd. We vergelijken beide in persoonlijk versus organisatorisch Google Play-account.
Tellen emulators mee voor de 12 testers?
Niets in de hier bekeken documentatie beantwoordt dat met ja of nee, en daarom houdt de rest van deze gids uit elkaar wat er staat en wat wordt afgeleid. Beweringen vallen in een van vier categorieën, en de gebruikelijke fout is er stilletjes een uit een lagere categorie naar een hogere te promoveren.
Een regel waaraan je moet voldoen: 12 testers, 14 aaneengesloten dagen, de peildatum 13 november 2023, en dat je na het voldoen eraan kunt aanvragen.
Nauwkeurige beschrijvingen van gedrag: integriteitsverdicts, systeemimages, testconfiguratie. Geschreven met een ander doel dan beslissen wie meetelt.
Threads op de Google Play Developer Community en Reddit. Het aanbevolen antwoord in de thread die we aanhalen, adviseert andere mensen op fysieke Android-apparaten in te zetten in plaats van emulators. Het lezen waard, maar de pagina waarschuwt dat de inhoud ongeverifieerd kan zijn, en een Google-hostnaam is geen beleid.
Ons eigen oordeel: werf boven het minimum, en fabriceer geen deelname met emulators of nepaccounts. Advies uit het doen van dit werk, geen regel, en wij verkopen testhulp.
Gedocumenteerd en veilig om aan te halen
Staat in het beleid, de helppagina’s of de ontwikkelaarsdocumentatie van Google.
- De vereiste zelf: 12 testers die 14 aaneengesloten dagen aangemeld zijn, voor persoonlijke accounts die na 13 november 2023 zijn aangemaakt.
- De aanvraag voor productietoegang vraagt hoe de test is verlopen, wat de app is en wat je op basis van het testen hebt veranderd.
- Het Developer Program-beleid verbiedt het manipuleren van plaatsing, beoordelingen, reviews of installatiecijfers met onrechtmatige middelen.
- Google raadt aan om vóór de release op fysieke hardware te testen, en documenteert emulatortests op verschillende versies en schermformaten.
Niet vastgelegd: ga er niet van uit
Klinkt plausibel, en ontbreekt in de hier bekeken documentatie.
- Dat een Play Integrity-verdict bepaalt of een tester meetelt voor de 12.
- Elk met naam genoemd detectiesignaal: ruis van de versnellingsmeter, variatie in batterijtemperatuur, gps-drift, touchtelemetrie, IP-clustering of accountleeftijd.
- Elk specifiek cijfer in de trant van ‘X% van de emulators wordt betrapt’. Behandel exacte percentages als ongefundeerd, niet als metingen.
- Een universele rapportagevertraging, een vereist aantal dagelijkse sessies, of een vereist aantal updates tijdens de periode.
Aangemelde testers, geïnstalleerd publiek en productietoegang
Het grootste deel van deze discussie gaat eigenlijk over drie getallen in Play Console die als inwisselbaar worden behandeld. Dat zijn ze niet.
| Waar je naar kijkt | Wat het betekent | Wat het je niet vertelt |
|---|---|---|
| Aangemelde testers | Accounts die de aanmeldlink voor deze track hebben geaccepteerd. Dit is het begrip waar de vereiste om draait, samen met hoe lang ze aangemeld blijven. | Of iemand de app heeft geïnstalleerd, geopend of je bruikbare feedback heeft gegeven. |
| Geïnstalleerd publiek | Google definieert het als gebruikers die je app geïnstalleerd hebben op minstens één apparaat dat ze in de afgelopen 30 dagen hebben gebruikt. Het apparaat moet gebruikt zijn; de app niet per se. | Het is een publieksstatistiek, niet de teller voor productietoegang, en geen aantal apparaten dat een beveiligingscontrole heeft doorstaan. |
| De checklist voor productietoegang | Het item op het Dashboard dat aangeeft hoeveel testers aangemeld zijn, en voor hoeveel aaneengesloten dagen. Hieraan wordt de vereiste afgemeten. | Waarom een specifieke persoon er wel of niet in zit. Controleer daarvoor de aanmeldingen. |
Aan het minimum voldoen is niet hetzelfde als een overtuigende test. Google kan om verder testen vragen als de betrokkenheid van de testers onvoldoende is, ook als er al 12 testers 14 aaneengesloten dagen aangemeld zijn geweest. Google publiceert geen quotum voor dagelijkse sessies, dus het doel is een test die echt gebruik en echte feedback heeft opgeleverd, geen activiteit die is gefabriceerd om druk te lijken.
Installeren buiten Play om is een apart pad, en het meldt niemand aan. Een Android App Bundle is een publicatieformaat, geen installeerbaar bestand, dus wat op die manier wordt geïnstalleerd, is een APK die eruit is gegenereerd. En hoe het bestand ook aankomt (handmatige installatie, gedeelde link, interne app-sharing), het accepteert voor niemand je aanmeldlink.
Een verschil tussen twee van deze getallen is een symptoom, geen diagnose. Twaalf aanmeldingen naast een laag geïnstalleerd publiek heeft gewone verklaringen: mensen hebben zich aangemeld en nooit geïnstalleerd, ze hebben geïnstalleerd op een apparaat dat ze de laatste tijd niet gebruiken, de rapportage loopt achter, of de release is voor hen niet beschikbaar.
Wat we je hier wel en niet kunnen vertellen
Google publiceert de testvereiste en de definities van deze statistieken, maar geen verklaring voor elke afzonderlijke teluitkomst, en geen universele rapportagevertraging. Lees de documentatie van de specifieke statistiek, houd een waargenomen vertraging gescheiden van een gepubliceerde garantie, en werk de checklist hieronder door.
Als een tester je gesloten build niet kan vinden of installeren
Controleer deze configuratieproblemen voordat je het probleem aan de omgeving toeschrijft. Ze gelden net zo goed voor fysieke apparaten als voor emulators.
-
01
Het verkeerde Google-account
Het account dat de aanmeldlink heeft geaccepteerd, moet het account zijn dat op het apparaat is ingelogd en in de Play Store is geselecteerd. Op een telefoon met meerdere Google-accounts controleer je dat als eerste wanneer iemand ‘app niet beschikbaar’ meldt.
-
02
De aanmelding is nooit afgerond
Je mailinglijst of gekoppelde Google Groep maakt iemand geschikt; ze meldt die persoon niet aan. Diegene moet de aanmeldlink nog steeds openen en accepteren, en het kan even duren voordat een groepslidmaatschap doorwerkt. Een gesloten build staat ook niet in de zoekresultaten van de Play Store, dus testers bereiken hem via de aanmeldlink en de Store-link die jij ze geeft.
-
03
Een conflicterende track
Zit het account ook in je interne test, vraag die persoon dan om die test te verlaten voordat hij zich aanmeldt voor de gesloten test. Waar tracks overlappen, krijgt een geschikte gebruiker de hoogste compatibele versiecode die voor hem beschikbaar is, en dat is niet per se de release die jij in de gaten houdt (testconfiguratie).
-
04
Geen live release op die track
Een gesloten track heeft een gepubliceerde release nodig die ook echt is uitgerold, op de versie en het percentage die je denkt. Een concept wordt aan niemand gedistribueerd. Een gepauzeerde uitrol stopt verdere distributie, maar testers die die versie al hebben ontvangen, kunnen hem nog geïnstalleerd hebben, dus controleer welke versie wordt aangeboden. Google merkt ook op dat een nieuwe testlink, en latere wijzigingen daaraan, een paar uur nodig kunnen hebben om beschikbaar te worden.
-
05
Je eigen beschikbaarheidsinstellingen
Beschikbaarheid per land en apparaatbeperkingen stel jij zelf in. Voor landen kijkt Google naar het land van het Google Play-account van de tester, en dat is niet altijd waar die persoon zich bevindt. En als je op integriteit gebaseerde apparaatcontroles voor de Store-vermelding hebt ingeschakeld, kunnen die sommige apparaten verhinderen de app te zien of te installeren: een toegangsbeperking die jij hebt ingesteld, geen bewijs over welke testers meetellen.
-
06
De omgeving of de build zelf
Pas na de vijf hierboven. Een emulator met de verkeerde systeemimage kan überhaupt niet inloggen bij de Play Store, en Android Studio publiceert bekende problemen voor specifieke images.
-
07
Je app blokkeert het, niet de Store
Als de download werkt en de app daarna weigert te draaien, is dat je eigen handhaving, geen kwestie van beschikbaarheid in Play. Controleer wat je app of backend doet met het Play Integrity-antwoord voordat je concludeert dat de tester je build niet kan krijgen.
Ziet de telling er nog steeds verkeerd uit, dan hebben we aparte stappenplannen: testers toegevoegd maar nul aangemeld, de app is niet beschikbaar voor een tester en testertoegang via Google Groepen. Elk behandelt de gangbare configuratieoorzaken en de verdere controles die je kunt uitvoeren.
Wanneer testen op een emulator helpt
Emulators zijn goed, en Google bouwt er zelf een. Hij zit in Android Studio, en Google raadt aan om op verschillende Android-versies en schermformaten te testen. De fout is niet dat je een emulator gebruikt; de fout is dat je verwacht dat hij werk doet waarvoor hij nooit bedoeld was.
Aanbeveling van PrimeTestLabSnel itereren tijdens het bouwen. Android-versies en schermformaten die je niet bezit. Tablets, talen, donkere modus, lay-outs van rechts naar links. Een crash op afroep reproduceren.
Een onafhankelijk oordeel. Eén machine met vijf virtuele apparaten is nog steeds de mening van één persoon.
Hoe de app zich gedraagt op hardware die mensen bezitten: prestaties, batterij, camera, meldingen, netwerkwisselingen, de eigen Android-build van de fabrikant. Google raadt aan om vóór de release op hardware te testen.
Een garantie over geschiktheid. Goede telefoons voldoen niet aan een vereiste die over testers gaat.
Het deel dat tooling niet kan leveren: iemand die zich aanmeldt, de app geïnstalleerd houdt, de flows probeert waar jij niet aan dacht, en je vertelt wat verwarrend was.
Apparaatdekking. Twaalf testers kunnen best vergelijkbare telefoons hebben, en daarom blijven emulatorchecks hun plek verdienen.
Android Studio-images, images met Play en BlueStacks
Niet alle emulators zijn hetzelfde, en het verschil zit in de systeemimage. Een AOSP-image heeft geen Google-apps. Een Google APIs-image voegt Google-services toe, maar geen Play Store. Een Google Play-image bevat de Store, en Android Studio markeert de apparaatprofielen die dat ondersteunen met het Play-logo en documenteert die telefoonprofielen als CTS-conform. Het profiel en de systeemimage zijn aparte keuzes wanneer je het virtuele apparaat aanmaakt, en je hebt de Play-image nodig om erin in te loggen en te installeren. BlueStacks documenteert het inloggen bij de Play Store ook. Niets daarvan beslist over geschiktheid: de Store bereiken en als tester meegeteld worden zijn twee verschillende uitkomsten.
Als je geen Android-telefoon hebt maar iemand wilt helpen testen
Dit is een andere situatie dan een ontwikkelaar die een testergroep fabriceert, en ze verdient een eerlijk antwoord in plaats van een beschuldiging. Een vriend helpen testen op de machine die je bezit is geen bedrog. Wat niemand je kan beloven, is de uitkomst, omdat Google niet publiceert hoe elke deelnemer wordt geteld. Als het ertoe doet, leen dan een Android-telefoon of gebruik een ouder compatibel toestel. Gebruik je toch een emulator, zeg dat dan tegen de ontwikkelaar, zodat die de test daarop kan afstemmen.
Cloudapparaatlabs en pre-launch-rapporten
Firebase Test Lab draait je app op apparaten in de infrastructuur van Google, en het pre-launch-rapport van Play Console crawlt je build automatisch. Beide zijn legitieme geautomatiseerde QA. Geen van beide is een deelnemer: een geautomatiseerde run meldt zich niet aan, blijft geen 14 dagen aangemeld en vertelt je niet dat het onboardingscherm nergens op sloeg.
Wat Play Integrity wel en niet vaststelt
Technische documentatie van GooglePlay Integrity is de technologie waarop het grootste deel van deze discussie rust, dus het loont om te weten waarvoor ze dient. Volgens developer.android.com is het doel van de 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’ (integriteitsverdicts). Het publiek voor dat antwoord is je app en je eigen backend. Play Console rapporteert integriteitsantwoorden ook aan jou terug, en een aparte instelling van de Store-vermelding kan beperken welke apparaten mogen installeren. Niets daarvan is de vereiste voor de gesloten test, en niets ervan moet zo worden gelezen.
‘The app is running on a genuine and certified Android device.’ Op Android 13 en hoger komt dat met hardwarematig onderbouwd bewijs dat de bootloader vergrendeld is en het OS een gecertificeerde fabrikantsimage is; eerdere versies kunnen op een softwarematige beoordeling berusten.
Hoe het apparaat eruitziet voor de API. Geen uitspraak over aanmelding.Gedocumenteerd als een apparaat met ‘signs of attack (such as API hooking) or system compromise (such as being rooted)’, of een app ‘not running on a physical device (such as an emulator that does not pass Google Play integrity checks)’. Het veld kan meerdere labels bevatten, dus dit is een ontbrekend label, geen waarde die ‘leeg’ heet.
Het dekt verschillende situaties, dus je kunt het niet terugredeneren naar één oorzaak.‘The app is running on a device that passes basic system integrity checks. The device may not be certified.’ Optioneel betekent hier dat de ontwikkelaar kiest of hij het label wil ontvangen, wat niets te maken heeft met een tester die zich aanmeldt.
Een antwoordinstelling, geen aanmelding.‘The app is running on a genuine and certified Android device with a recent security update.’ Op Android 13 en hoger betekent dat apparaatintegriteit plus recente beveiligingsupdates op de relevante partities; Android 12 en lager wordt beoordeeld op hardwarematig onderbouwde bootintegriteit, zonder dezelfde test op recente updates.
Een hoge lat voor je eigen backend. Geen drempel voor de gesloten test.Gedocumenteerd voor een ‘Android-powered emulator with Google Play services’, in de context van Google Play Games op pc, een distributiekanaal met eigen vereisten.
Geen verdict over Android Studio-testemulators, in geen van beide richtingen.Apparaat, app-herkenning en licentie zijn aparte velden
Drie velden worden aangehaald alsof ze één veld zijn, en dat door elkaar halen is waar de meeste verwarring begint. Het veld apparaat beschrijft de omgeving. Het veld app-herkenning beschrijft of de draaiende binary overeenkomt met wat Google Play heeft gedistribueerd. Het veld licentie beschrijft het gebruiksrecht en kan ‘unlicensed’ melden als het account geen Play-recht op de app heeft. Een build die buiten Play om is geïnstalleerd, is een verhaal over licentie en distributie, geen hardwareverdict.
Deze voorbeelden leggen terminologie uit. Niets hier maakt contact met Google, meet je apparaat, verifieert deelname of voorspelt productietoegang. Echte antwoorden hangen af van de app, de configuratie en de omgeving.
| Omgeving | Wat een antwoord kan tonen | Wat dat je wel en niet vertelt |
|---|---|---|
| Gecertificeerde telefoon, vergrendelde bootloader | Het apparaatveld kan MEETS_DEVICE_INTEGRITY bevatten, en MEETS_STRONG_INTEGRITY bij een recente beveiligingsupdate. | Dat het apparaat voldoet voor de API. Niet of die persoon je aanmeldlink heeft geaccepteerd. |
| Standaard Android Studio-emulator | Google documenteert een emulator die de Play-controles niet doorstaat als een van de redenen waarom er geen apparaatherkenningslabel wordt teruggegeven. | Dat je eigen backend op het resultaat kan reageren. Een ontbrekend label wijst op zichzelf geen emulator aan, en het zegt niets over iemands aanmelding. |
| Build buiten Play om geïnstalleerd | Andere velden beantwoorden dit: app-herkenning voor het matchen van pakket en certificaat, en licentie, die ‘unlicensed’ kan melden als het account geen Play-recht heeft. | Deze velden beschrijven app-herkenning en het gebruiksrecht van het account. Lees ze los van elkaar: ze zijn geen volledig verslag van hoe het huidige exemplaar is geïnstalleerd, en ze melden niemand aan. |
De samenvatting is dus smal: Play Integrity vertelt je eigen backend veel over de omgeving waarin je app draait, en niets in deze documentatie zegt dat die verdicts bepalen welke testers meetellen.
Een praktische aanpak, en herstel na emulators
Behandel de 14 dagen als een echte bèta in plaats van een hindernis. De stappen hieronder combineren het gepubliceerde proces van Google met onze eigen aanbevelingen: boven het minimum werven en feedback op deze manier organiseren zijn suggesties, geen extra quota van Google. Het doel is een echte test, niet wachten tot de kalender is doorgelopen.
Aanbeveling van PrimeTestLabUpload een gesigneerde App Bundle, maak een gesloten testtrack aan en publiceer er een release op. Niets anders werkt totdat er een release live staat op die track.
Een mailinglijst past bij een kleine, bekende groep; een gekoppelde Google Groep schaalt makkelijker. Hoe dan ook accepteert iedere persoon de aanmeldlink nog steeds zelf.
Advies, geen regel. Mensen verliezen hun interesse, wisselen van telefoon of melden zich af, en een vervanger erft niemands geschiedenis: zijn 14 dagen beginnen bij zijn aanmelding. Met 15 tot 30 mensen heb je speelruimte.
Geef testers iets concreets om te proberen en een makkelijke plek om terug te koppelen. Er is geen quotum voor dagelijkse sessies of screenshots gepubliceerd, dus fabriceer geen activiteit.
Breng de wijzigingen uit die het testen rechtvaardigde, en houd kort bij wat er is gemeld en wat je hebt gedaan. Er is geen vereist aantal updates gepubliceerd, dus publiceer geen wijzigingen alleen om aan een vermeend updatequotum te voldoen.
Het formulier vraagt hoe je de test hebt uitgevoerd en testers hebt betrokken, wat de app is en voor wie, en wat je als gevolg daarvan hebt veranderd. Beantwoord het vanuit je aantekeningen. De beoordeling duurt meestal zeven dagen of minder, maar kan langer duren.
Als je je test al op emulators hebt uitgevoerd
-
Open de checklist voor productietoegang op je Dashboard en lees wat er staat: hoeveel testers, hoeveel aaneengesloten dagen. Dat is de werkelijke stand van je test.
-
Werk de diagnoselijst hierboven door voor iedereen die is aangemeld maar niet laat zien wat je verwacht. Repareer de configuratie voordat je iets concludeert over apparaten.
-
Houd de voortgang die je rechtmatig hebt. Niets wat Google publiceert zegt dat een test opnieuw begint vanwege de omgeving die een tester gebruikte.
-
Voeg echte deelnemers toe en laat elke nieuwe tester zijn eigen 14 aaneengesloten dagen van aanmelding volmaken. Zijn tijd erft niet die van iemand anders, dus de test moet misschien doorlopen tot na de einddatum die je in gedachten had. Als je app echte problemen heeft, is dit ook het deel dat ze vindt.
Als het werven van mensen het lastige deel is, begin dan met de gratis opties in zeven legitieme manieren om 12 testers te vinden. Vandaaruit: testers uitnodigen, de regel van 14 aaneengesloten dagen, je app updaten tijdens het testen en de vragenlijst voor productietoegang.
Echte deelname, en wat de regels wél schendt
Veel van de angst hier komt doordat drie heel verschillende handelingen op één hoop worden gegooid. Ze zijn niet hetzelfde, en hun gevolgen ook niet.
Je eigen build op een emulator installeren om te controleren dat hij compileert, draait en er goed uitziet, is normaal engineeringwerk, op het gereedschap dat Google daarvoor levert. Het is geen bedrog, en het is niet waar handhaving op gericht is.
Dit is het geval waarbij ontwikkelaars ons vragen om hulp nadat het is misgegaan. Google publiceert geen telregel voor emulators, dus we kunnen je niet vertellen dat het tegen de regels is. We kunnen je wel vertellen wat wij doen: wij bouwen een test niet op deze manier, en we raden het af. Productietoegang wordt beoordeeld op bewijs van een echte test, en in onze ervaring is een groep die uit virtuele apparaten is samengesteld precies het soort test dat wordt teruggestuurd voor meer testen, of afgewezen.
Nep-Google-accounts aanmaken en je daarmee aanmelden, op emulators of op wat dan ook, is een heel andere handeling. Het beleid van Google over beoordelingen, reviews en installaties verbiedt pogingen om plaatsing, beoordelingen, reviews of installatiecijfers met onrechtmatige middelen te manipuleren.
De praktische grens gaat dus over bedrog, niet over virtualisatie: maak geen accounts aan en automatiseer geen activiteit om een verkeerd beeld te geven van wie er meedoet. Google verbiedt onrechtmatige manipulatie van installaties en andere Store-statistieken. Dat beleid vestigt op zichzelf geen telregel die specifiek over emulators gaat.
Eén correctie die de moeite waard is: een reactie ‘meer testen vereist’ betekent op zichzelf geen handhavingsmaatregel tegen je account. Lees het specifieke bericht en blijf testen zoals het aangeeft, in plaats van automatische straffen bij toekomstige beoordelingen te veronderstellen. Wat je doet na die afwijzing ontleedt het.
De praktische les is voor alle drie dezelfde. Een emulator levert je geen extra persoon op, dus de enige vraag die je tijd waard is, is hoe je efficiënt echte mensen vindt.
Waar PrimeTestLab past
Commercieel belangWij verkopen hulp bij de gesloten test, dus lees dit onderdeel met dat in gedachten. Ontwikkelaars grijpen naar emulators omdat een dozijn mensen vinden die twee weken aangemeld blijven echt moeilijk is, niet omdat ze willen valsspelen. Dat is het deel dat wij doen.
Wat we doen
12 of meer echte testers werven en coördineren, ze de volle 14 dagen aangemeld houden en iedereen vervangen die afhaakt. Het testen begint binnen ongeveer 4 tot 6 uur.
Wat we niet zullen claimen
Dat welke dienst dan ook de beslissing van Google kan garanderen, of dat testers inhuren de beoordeling overbodig maakt. Productietoegang wordt beoordeeld op je test en je app.
Als je liever niet betaalt
Dat is een volkomen redelijke keuze, en de gratis routes in zeven legitieme manieren om 12 testers te krijgen werken. Ze kosten tijd in plaats van geld.
Elk pakket heeft een geld-terug-garantie. Je kunt vóór je beslist ook het stapsgewijze proces lezen.
Veelgestelde vragen
Kan ik een emulator gebruiken voor de gesloten test bij Google Play?
Gebruik er een om je app te testen: daar bouwt Google hem voor. De gepubliceerde vereiste is 12 testers die 14 aaneengesloten dagen aangemeld zijn, en geen enkele hier bekeken documentatie zegt of een deelnemer op een emulator daarvoor meetelt. Onze eigen aanbeveling gaat verder dan de documentatie: je build op een emulator testen is prima, emulatorinstanties als vervangende testers inzetten is iets wat wij niet zouden doen, en je aanmelden vanaf nep-Google-accounts is manipulatie waardoor productietoegang kan worden afgewezen.
Betekent een mislukte Play Integrity-controle dat een tester niet meetelt?
De documentatie die voor deze gids is bekeken, zegt dat niet. Play Integrity geeft je eigen app en backend antwoord over de omgeving waarin de app draait, en Google documenteert het los van de vereiste voor de gesloten test. Behandel de keten van integriteitsverdict naar testertelling als een afleiding, niet als een gepubliceerd proces.
Heb ik 12 mensen, 12 accounts of 12 telefoons nodig?
De vereiste gaat over testers die 14 dagen doorlopend aangemeld zijn, wat in de praktijk 12 mensen betekent met hun eigen Google-account die je aanmeldlink accepteren. Je hoeft geen twaalf telefoons te bezitten, en geen enkele Google-documentatie vereist dure hardware of een spreiding over fabrikanten. Of je zelf een van de twaalf kunt zijn, wordt behandeld in je eigen accounts als testers gebruiken.
Ik heb geen Android-telefoon. Kan ik toch iemand helpen zijn app te testen?
Willen helpen is geen bedrog, en het is iets anders dan een ontwikkelaar die een testergroep fabriceert. Niemand kan eerlijk beloven hoe je deelname wordt geteld. Een Android-apparaat lenen is de route met het minste risico; gebruik je toch een emulator, zeg dat dan tegen de ontwikkelaar, zodat die er rekening mee kan houden.
Kan ik BlueStacks gebruiken voor de gesloten test bij Google Play?
BlueStacks documenteert het inloggen bij de Play Store, en een Android Studio-image met Play kan de Store ook bereiken. Dat bevestigt dat toegang tot de Play Store mogelijk is, niet dat jouw specifieke gesloten build beschikbaar zal zijn: dat hangt nog altijd af van het account, de track en de release. Het beslist ook niets over geschiktheid, omdat geen enkele Google-documentatie vermeldt of zo’n deelnemer meetelt. Beschouw een leverancierspagina als autoriteit over dat product en niets meer, in geen van beide richtingen.
Is apparaatverificatie van de ontwikkelaar hetzelfde als de gesloten test?
Nee. Bij apparaatverificatie bewijst de accounteigenaar bij het instellen van het account toegang tot een niet-geroot fysiek Android-apparaat met Android 10 of hoger, en Google kan er later opnieuw om vragen. De gesloten test gaat over mensen die zich aanmelden voor een testtrack. Andere persoon, ander doel, andere helppagina.
Betekent het verwijderen van de app dat een tester de test heeft verlaten?
Verwijderen en afmelden zijn verschillende handelingen. De vereiste gaat over doorlopende aanmeldstatus, dus ga er niet van uit dat een verwijdering de periode onderbreekt of dat één vertrekkende persoon de anderen terugzet naar nul. Ziet de voortgang er verkeerd uit, controleer dan eerst de checklist voor productietoegang en de aanmeldingen.
Conclusie
Samenvatting
Emulators zijn een legitiem testgereedschap en een slechte vervanger voor deelnemers. De vereiste is 12 testers die 14 aaneengesloten dagen aangemeld zijn, en de hier bekeken documentatie legt niet vast of een deelnemer op een emulator meetelt. Open dus je checklist voor productietoegang, werk de configuratiecontroles door voordat je de hardware de schuld geeft, en besteed de rest van de periode aan het werven van mensen die de app echt gaan gebruiken. Onze eigen aanbeveling, die de documentatie niet voor ons hoeft uit te spreken: deelname fabriceren met emulators of nepaccounts is het risico op afwijzing niet waard. Begin met de gratis manieren om 12 testers te vinden →
Officiële documentatie van Google
Communitydiscussie, geen documentatie
Het aanbevolen antwoord daar adviseert andere mensen op fysieke Android-apparaten in te zetten in plaats van emulators, en een Product Expert heeft het onderschreven, wat goed is om te weten. Het blijft communitydiscussie: er wordt geen beleid aangehaald, en de pagina waarschuwt dat de inhoud ongeverifieerd kan zijn.