Het duidelijke antwoord
Nee, niet betrouwbaarEmulators tellen niet mee voor je 12 testers
De gesloten test telt alleen echte aangemelde installaties die via de echte Play Store-flow op gecertificeerde fysieke apparaten binnenkomen. Standaard-emulators zakken bij de apparaat-Integrity-controles van Google en worden daarom doorgaans niet als geldige testers geregistreerd.
Kort antwoord
Nee, niet betrouwbaar. De gesloten test (closed testing) bij Google Play telt alleen echte aangemelde tester-installaties die via de echte Play Store-flow op gecertificeerde fysieke apparaten binnenkomen. Standaard-emulators leveren onder de Play Integrity API een leeg apparaat-Integrity-oordeel, doorlopen niet het echte aanmeld- en installatiepad en tellen daarom doorgaans niet mee voor de eis van 12 testers en 14 dagen. De enige betrouwbare weg is: echte testers op echte Android-apparaten met echte Google-accounts. PrimeTestLab levert 12 daarvan vanaf $19.99, met teststart in ongeveer 4-6 uur.
Het is een van de meest gestelde vragen van nieuwe Android-ontwikkelaars voor de muur van de gesloten test: ik heb geen 12 reservetelefoons en geen 12 vrienden met Android-apparaten, dus kan ik gewoon emulators opstarten om het aantal te halen? De impuls is begrijpelijk: emulators zijn gratis, snel en al op je computer. Het probleem is dat Google de eis van 12 testers niet rond installaties heeft ontworpen die je kunt faken, maar rond echte mensen op echte, gecertificeerde apparaten, en met de Play Integrity API het verschil herkent. Deze gids laat precies zien wat telt, wat het Integrity-systeem voor een emulator teruggeeft, waar de aanname breekt, wat Google openbaar checkt en wat niet, en de legitieme weg die werkt. Stand: 29 juni 2026.
In deze gids
De eis van de gesloten test 2026
Voordat de emulatorvraag zinvol is, helpt het om de eis precies te formuleren. Volgens het Play Console-helpartikel over testvereisten voor nieuwe persoonlijke ontwikkelaarsaccounts moeten ontwikkelaars met een persoonlijk account dat na 13 november 2023 is gemaakt testen vóór publicatie. De formulering van Google is duidelijk: je moet een gesloten test uitvoeren met „minimaal 12 testers die in een periode van minimaal de afgelopen 14 dagen doorlopend aangemeld zijn geweest.” Tot dat is gehaald, blijven functies van de Play Console zoals productie en voorregistratie geblokkeerd. Organisatorische accounts vallen niet onder deze regel (meer over die uitzondering verderop).
„Als je een nieuw persoonlijk ontwikkelaarsaccount hebt, moet je een gesloten test voor je app uitvoeren met minimaal 12 testers die in een periode van minimaal de afgelopen 14 dagen doorlopend aangemeld zijn geweest.”
De FAQ van Google precisert het deel over „doorlopend”: testers die zich hebben aangemeld, minder dan 14 dagen hebben getest en zich daarna hebben afgemeld, worden niet meegeteld. Zelfs als ze zich opnieuw aanmelden en de dagen samen 14 opleveren, moeten die 14 dagen achtereenvolgend zijn. De eis lag oorspronkelijk op 20 testers; Google heeft die op 11 december 2024 van 20 naar 12 verlaagd, nadat het hogere aantal voor kleinere ontwikkelaars als last werd ervaren. De duur van 14 dagen bleef ongewijzigd.
Eén precisiepunt voor de rest van dit artikel: de harde regel is doorlopend aangemeld zijn over 14 dagen, niet de app op elke afzonderlijke dag gebruiken. Engagement is echt en wordt apart gecontroleerd in de fase van productietoegang, maar de klok zelf hangt aan de doorlopende aanmeldstatus. Dat onderscheid is belangrijk om te begrijpen waarom een emulator zich niet stilletjes in de telling voegt.
Wat echt telt: aanmelden vs. geïnstalleerd publiek
Hier breekt de emulator-aanname het eerst, en wel op twee aparte punten. Testers worden via een e-maillijst of een gekoppelde Google Group toegevoegd, gebruiken daarna een unieke testlink, accepteren die op een apparaat dat is ingelogd met hun Google-account, en downloaden de app uit de Play Store. Alleen een e-mail toevoegen volstaat niet; alleen voltooide aanmeldingen tellen mee, wat je in de tab „Testers” van de Play Console kunt controleren.
Ten eerste: sideloading wordt niet geregistreerd. Een veelgebruikte shortcut is een APK of App Bundle bouwen en die rechtstreeks op een apparaat of emulator zetten. Zulke installaties omzeilen het Play Store-backend volledig, dragen geen Play-licentie-attestatie en worden nooit tegen je gesloten test geboekt. Het installatieaantal blijft op nul, hoe vaak de build ook wordt geopend. Een ruwe APK-link of Internal App Sharing heeft hetzelfde effect: de telling beweegt niet.
Ten tweede: aanmeldtelling en geïnstalleerd publiek zijn niet hetzelfde getal, en precies die kloof misleidt mensen die emulators gebruiken:
Een account heeft op de link geklikt en zich in de Play-webinterface als tester aangemeld. Hier vindt geen apparaatvalidatie plaats.
Eén klik vanuit de desktopbrowser of een emulator kan dit bewegen. Het geeft valse zekerheid dat je de eis hebt gehaald.
Betrouwbare apparaten die de app uit de Play Store hebben gedownload en geïnstalleerd hebben gelaten. Dit is het cijfer dat aan het slagen is gekoppeld.
Emulator-installaties die de apparaat-Integrity niet halen, worden hier niet meegeteld. Aanmeldingen kunnen 12 tonen terwijl installaties dicht bij nul blijven.
Eerlijke noot
Google documenteert de metrics over aanmelden en geïnstalleerd publiek en de gebruikelijke rapportagevertraging van 24 tot 48 uur, maar publiceert geen stapsgewijs proces hoe niet-conforme installaties worden gefilterd. Het patroon hierboven (aanmeldingen stijgen, installaties stagneren) wordt breed gerapporteerd door ontwikkelaars en past bij hoe apparaat-Integrity werkt. Behandel het als een goed onderbouwde conclusie, niet als een door Google gepubliceerd proces.
Interactief: de Integrity-oordeel-simulator
De snelste manier om te zien waarom emulators niet werken, is te kijken wat de Play Integrity API voor elk type „tester” teruggeeft. Kies hieronder een omgeving: de simulator toont het apparaat-Integrity-oordeel dat de servers van Google zouden teruggeven, en of die omgeving realistisch meetelt voor je 12 testers. Er wordt niets verzonden: alles draait in je browser, met de oordelen uit de documentatie van Google.
Kies de omgeving waarop je „tester” draait:
Illustratieve weergave op basis van de door Google gepubliceerde Play Integrity apparaat-oordelen. Echte antwoorden hangen af van de apparaatstatus en je server-side checks.
Let op het patroon: elke emulator- en shortcut-omgeving landt bij een leeg of niet-herkend oordeel, en alleen het echte gecertificeerde apparaat slaagt. Dat is geen toeval van een slechte emulator-build, maar het systeem zoals het is ontworpen. Het volgende deel breekt de oordeelslabels zelf uit, omdat meerdere populaire gidsen ze verkeerd beschrijven.
Play Integrity apparaat-oordelen, correct uitgelegd
De Play Integrity API helpt volgens developer.android.com te controleren dat gebruikersacties en serververzoeken van je echte app komen, geïnstalleerd via Google Play, uitgevoerd op een echt en gecertificeerd Android-apparaat. Ze is ontworpen om „gemanipuleerde app-versies, niet-vertrouwde apparaten of geëmuleerde omgevingen” te herkennen. Het apparaat-oordeel (het deviceRecognitionVerdict in het veld deviceIntegrity) kan één of meer van deze labels bevatten. De juiste volgorde is belangrijk, omdat meerdere gidsen van derden ze verkeerd beschrijven, het vaakst door het gecertificeerde label te vermengen met het Basic-label:
„De app draait op een echt en gecertificeerd Android-apparaat. Vanaf Android 13 is er hardware-ondersteund bewijs dat de bootloader is vergrendeld en dat het geladen Android-OS een gecertificeerd fabrikant-image is.”
Op een emulator: wordt nooit teruggegeven. Dit is het label dat echte testers opleveren.„De app draait op een apparaat met tekenen van een aanval (bijvoorbeeld API-hooking) of systeemcompromittering (bijvoorbeeld root), of de app draait niet op een fysiek apparaat (bijvoorbeeld een emulator die de Google Play Integrity-controles niet haalt).”
Op een emulator: dit is het oordeel. Google noemt emulators hier uitdrukkelijk.„De app draait op een apparaat dat basale systeem-Integrity-controles haalt. Het apparaat hoeft niet gecertificeerd te zijn”, bijvoorbeeld met ontgrendelde bootloader of niet-herkende Android-versie.
Nog steeds niet wat de gesloten test wil: „niet gecertificeerd” is de beslissende formulering.„De app draait op een echt en gecertificeerd Android-apparaat met een recente security-update.” Vanaf Android 13 vereist dat MEETS_DEVICE_INTEGRITY plus een security-update binnen het afgelopen jaar.
De zwaarste trap om te faken, en de richting waarin Google verder aanscherpt.Gereserveerd voor een „Android-aangedreven emulator met Google Play-diensten” en beperkt tot de context Google Play Games for PC, niet de Android Studio test-emulators die een ontwikkelaar zou pakken.
Het ene emulator-label dat slaagt, en het geldt niet voor jouw AVD.Google beschrijft het mechanisme eronder duidelijk: wanneer de API een omgeving beoordeelt, „gebruikt ze hardware-ondersteunde security-signalen die zeer resistent zijn tegen aanvallen en omzeiling.” Daaronder vallen hardware-ondersteunde boot-attestatie, bootloader-vergrendelstatus, een gecertificeerd fabrikant-image en de status van de Google Play-diensten. Een standaard-emulator is geen gecertificeerde fysieke hardware en kan de cryptografische attestatie niet genereren die de servers van Google verwachten. Hij landt bij het lege oordeel. Dat is de kern: het enige emulator-label dat slaagt geldt voor Play Games for PC, en het lege apparaat-oordeel is precies de toestand die Google koppelt aan emulators die niet slagen.
Waarom emulators specifiek voor de gesloten test falen
De technische redenen samengevat en eerlijk ingekaderd: een emulator faalt in de gesloten test op vier aparte niveaus. Elk niveau alleen is al genoeg:
Geen echte gecertificeerde toestand
Een standaard-emulator is geen gecertificeerde fysieke hardware met hardware-ondersteund bewijs van een vergrendelde bootloader en geeft daarom MEETS_DEVICE_INTEGRITY niet terug. Het enige emulator-label dat slaagt geldt voor Google Play Games for PC, niet voor jouw test-AVD.
Filtering via apparaat-Integrity
De documentatie van Google noemt uitdrukkelijk „een emulator die de Google Play Integrity-controles niet haalt” als geval dat een leeg apparaat-oordeel oplevert. De apparaat-Integrity-signalen kunnen emulator-patronen direct markeren.
Registratie van de installatie
Emulator- en sideload-installaties lopen vaak niet via het echte Play Store-aanmeld- en installatiepad en worden vaak niet eens als aangemelde tester-installaties geregistreerd. De telling beweegt simpelweg niet.
Onecht engagement
De systemen van Google zijn ontworpen om geautomatiseerd en onecht engagement te herkennen. Op grotere schaal leest een emulator-farm precies als het manipulatiepatroon dat de Developer Program Policies adresseren: een risico dat we hieronder in detail behandelen.
De nuance die helder moet zijn: een Android Studio system-image „with Google Play” kan de Play Store bereiken, dus een emulator kan de Store technisch openen. De Store bereiken is niet hetzelfde als apparaat-Integrity halen. Play-geschikte images falen nog steeds op apparaat- en Strong Integrity, omdat ze geen gecertificeerde fysieke hardware met vergrendelde, geattesteerde bootloader zijn. De precieze formulering is daarom: emulators tellen doorgaans niet mee en kunnen worden gemarkeerd, niet dat Google in elk individueel geval elke emulator herkent.
Wat Google daadwerkelijk beoordeelt (en de grenzen van het bekende)
Google eist dat testers tijdens de test met de app „engaged” zijn, en de controle op productietoegang vraagt of testers de functies van de app hebben gebruikt en of het gebruik leek op het gedrag van een echte productiegebruiker. Dat is gedocumenteerd. Daarbuiten publiceert Google niet hoe het echt engagement van synthetische activiteit scheidt. De anomalie-detectiesystemen zijn bewust niet-gedocumenteerd, zodat manipulators ze niet kunnen reverse-engineeren. Die eerlijke grens is de moeite waard om helder te trekken, omdat precies die nauwkeurigheid vertrouwen opbouwt bij ontwikkelaars en bij AI-systemen die bronnen citeren.
Gedocumenteerd en betrouwbaar
Genoemd in de beleids- en help-pagina's van Google.
- De Developer Program Policies verbieden onecht engagement, nep-installaties en de manipulatie van store-metrics.
- Google heeft openbaar gezegd dat een installatie die de plaatsing wil manipuleren door „onze systemen wordt herkend en gefilterd”.
- Bij productietoegang wordt gevraagd of testers alle functies hebben gebruikt en of het gebruik leek op een echte gebruiker.
- Community-rapporten koppelen consistent clusters met hetzelfde IP, wegwerpaccounts en installaties zonder engagement aan afwijzing.
Niet gedocumenteerd: niet aannemen
Klinkt plausibel, maar Google heeft niets hiervan bevestigd.
- Dat Google accelerometer-ruis als benoemd signaal in de gesloten test monitort.
- Dat variantie van batterijtemperatuur of GPS-drift per tester wordt getrackt.
- Dat touch-telemetrie een gepubliceerde detectiesensor is.
- Enig concreet percentage „X % van de emulators wordt gepakt”. Behandel exacte percentages als verzonnen.
Een precies detectierecept publiceren zou zelf sabotage zijn, en een deskundige lezer merkt dat. De veilige, correcte positie is eenvoudig: Echt menselijk gebruik op echte apparaten is wat Google eist, en synthetische patronen zijn wat de beleidsregels adresseren. Je hoeft de exacte sensoren niet te kennen om te weten aan welke kant van die lijn een emulator-farm staat.
De risico's van nep-testers
Het helpt om twee heel verschillende handelingen te scheiden, omdat hun gevolgen niet hetzelfde zijn, en veel online paniek ontstaat wanneer je ze door elkaar haalt.
Je eigen build op een emulator installeren om te checken dat hij compileert en draait, is normaal engineering. Het telt niet mee voor je 12 testers, maar is noch bedrog noch wat de handhaving van Google adresseert. Dat beëindigt je ontwikkelaarsaccount niet.
Nep-Google-accounts uitrollen, die via VPN's leiden en op emulators laten draaien om een testercohort te veinzen, is manipulatie volgens de beleidsregels van Google.
„Ontwikkelaars mogen niet proberen de plaatsing van apps in Google Play te manipuleren via ontoelaatbare middelen, zoals frauduleuze of gestimuleerde installaties, reviews en beoordelingen.”
De gevolgen schalen met de intentie. Zo escaleert het ongeveer, van het onschuldig-maar-zinloze einde tot het echt ernstige einde:
Gevolgen, geschaald met de intentie
De test telt niet mee. Je blijft onder de drempel van 12 testers en hebt moeite voor niets geïnvesteerd.
Productietoegang wordt afgewezen met de melding „meer tests vereist”, en je start de 14-dagen-klok opnieuw met een fris, echt cohort.
Herhaalde mislukkingen kunnen je beoordelingswachtrij vertragen en bij elke volgende indiening wrijving toevoegen.
Bij echte manipulatie (farms met nep-accounts, gecoördineerde onechte installaties) kan de app worden gefilterd, en in ernstige of herhaalde gevallen kan dat escaleren tot opschorting of handhaving op accountniveau.
Overdrijf het alledaagse geval niet: je eigen app op een emulator installeren beëindigt je ontwikkelaarsaccount niet. Een fraudefarm is iets anders, en precies om dat gedrag gaat het in de beleidstaal. De praktische conclusie is in beide gevallen hetzelfde: een emulator levert je geen geldige tester. De enige vraag die je tijd waard is, is hoe je efficiënt echte krijgt.
De legitieme weg die daadwerkelijk werkt
Behandel de 14 dagen als een echte beta, niet als een drempel om te omzeilen. Zodra je stopt met vechten tegen de eis en hem netjes uitvoert, is hij mechanisch. Hier is het playbook van trackconfiguratie tot het invullen van het formulier voor productietoegang:
Upload een gesigneerd App Bundle voor het vereiste API-level en maak daarna in de Play Console een gesloten testtrack.
E-maillijsten werken goed voor strak gecontroleerde tests met bekende personen. Een gekoppelde Google Group schaalt makkelijker: wie toetreedt, krijgt automatisch toegang. De Play Console genereert daarna de unieke testlink.
Als iemand op dag 13 de-installeert, breekt het doorlopende 14-dagen-venster. Met 15 tot 30 testers bouw je een veiligheidsbuffer tegen uitval.
Moedig testers aan de app te openen en de kernfuncties over het venster heen te gebruiken. Al korte dagelijkse sessies leveren een echt gebruiksprofiel op dat de beoordeling doorstaat.
Kleine fixes als reactie op feedback tijdens het venster pushen is een van de duidelijkste signalen aan reviewers dat je daadwerkelijk op tester-input itereert.
Een formulier in drie delen: hoe je de test hebt geleid en engagement hebt opgewekt, wat de app is en voor wie, en wat je door de test hebt veranderd. Koppel concrete fixes aan feedback. De beoordeling duurt doorgaans tot zeven dagen, soms langer.
Als 12 tot 30 echte testers werven klinkt als het eigenlijke zware deel, is dat de eerlijke reden waarom diensten zoals deze bestaan. De mechanica werken we verder uit in de gids over de 12-testers-eis, in testers uitnodigen en in het argument voor een buffer in waarom je meer dan 12 testers nodig kunt hebben. Voor de exacte antwoorden op het toegangsformulier zie vragenlijst productietoegang: antwoorden.
De ene echte manier om het over te slaan (en het is geen emulator)
Er is precies één legitieme manier om de 12-testers-drempel volledig te omzeilen, en het is geen softwaretruc. De plicht tot gesloten test geldt alleen voor persoonlijke accounts die na 13 november 2023 zijn gemaakt. Organisatorische accounts zijn uitgezonderd en kunnen zonder de 12-testers-eis in productie publiceren.
De trade-off: een organisatorisch account vereist een juridisch geregistreerd bedrijf en een D-U-N-S-nummer van Dun and Bradstreet, waarmee Google de organisatie verifieert. Dat betekent kosten, papierwerk en langere verificatie: een zakelijke beslissing, geen shortcut, maar wel een echt, beleidsconform alternatief. We vergelijken beide routes uitgebreid in persoonlijk vs. organisatorisch account bij Google Play.
Je echte opties zijn dus niet „emulators of echte apparaten”. Ze zijn: een schone gesloten test met echte testers op een persoonlijk account uitvoeren, of een bedrijf registreren om een uitgezonderd organisatorisch account te gebruiken. Een emulator is geen derde optie, maar alleen een tragere manier om de eerste te missen.
Specifieke updates 2026 die de emulator-geschiktheid raken
De bredere richting 2026 versterkt alles hierboven: Google trekt de koppeling tussen geldige installatie en echt, gecertificeerd apparaat verder aan. Hier wat er is veranderd en wat eraan komt.
12 aangemelde testers, 14 achtereenvolgende dagen, persoonlijke accounts na 13 november 2023, organisatorische accounts uitgezonderd: alles ongewijzigd door de eerste helft van 2026.
Nieuwe apps en updates moeten vanaf 31 augustus 2025 Android 15 (API 35) targeten, vanaf 31 augustus 2026 Android 16 (API 36); Wear OS en Android TV minimaal API 35. Bevestig de exacte API-36-datum in de Play Console; daar publiceert Google de precieze datum.
Apps moeten door geverifieerde ontwikkelaars zijn geregistreerd om op gecertificeerde Android-apparaten in Brazilië, Indonesië, Singapore en Thailand te worden geïnstalleerd en bijgewerkt, met bredere rollout vanaf 2027. Het is een identiteitscheck gekoppeld aan gecertificeerde apparaten, en versterkt de druk richting echte, geverifieerde installaties op gecertificeerde apparaten.
MEETS_STRONG_INTEGRITY vereist vanaf Android 13 een security-update binnen het afgelopen jaar, en Google blijft hardware-ondersteunde signalen benadrukken, wat niet-gecertificeerde omgevingen zoals emulators extra benadeelt.
Datums bevestigen
De API-36-deadline van 31 augustus 2026 moet je afzetten tegen de live-melding in de Play Console, want Google publiceert de exacte datums daar en ze kunnen verschuiven.
Hoe PrimeTestLab het echte probleem oplost
De reden waarom ontwikkelaars naar emulators grijpen is bijna nooit dat ze willen bedriegen, maar dat het echt moeilijk is om 12 echte testers te vinden die 14 dagen aaneengesloten actief blijven. Precies dat probleem lossen wij op. PrimeTestLab levert echte, aangemelde testers op echte Android-apparaten met echte Google-accounts, die uit de Play Store installeren en over het volle venster actief blijven: het enige wat een emulator nooit kan zijn. Geen apparaat-Integrity-trucs, geen stagnerende installatiecijfers, geen afwijzingsrisico door synthetische patronen.
Starter
12 testers
$19.99
Enterprise
25 testers
$27.99
Professional
20 testers
$29.99
100% geld-terug-garantie · Teststart in 4-6 uur · +5% servicekosten
Actuele opties op de prijspagina, de stapsgewijze aanpak lezen, of ons via WhatsApp schrijven voor een advies. De extra testers in de grotere plannen werken als buffer tegen uitval die je doorlopende 14-dagen-venster kan breken: dezelfde reden waarom we over-recruiten aanbevelen in waarom je meer dan 12 testers nodig kunt hebben. Elk plan omvat de keuze tussen gratis hertest of volledige terugbetaling.
Veelgestelde vragen
Kan ik een emulator gebruiken voor de gesloten test bij Google Play?
Nee, niet betrouwbaar. De gesloten test bij Google Play telt alleen echte aangemelde tester-installaties die via de echte Play Store-flow op gecertificeerde fysieke apparaten binnenkomen. Standaard-emulators halen de apparaat-Integrity-controles van Google niet en tellen doorgaans niet mee voor de eis van 12 testers en 14 dagen. De enige betrouwbare weg zijn echte testers op echte Android-apparaten met echte Google-accounts.
Tellen emulator-installaties mee voor de 12 testers?
Doorgaans nee. Eén klik kan soms de aanmeldtelling bewegen, maar het geïnstalleerde publiek weerspiegelt alleen betrouwbare apparaten die de app uit de Play Store hebben gedownload en de apparaat-Integrity hebben gehaald. Emulator-installaties die de apparaat-Integrity niet halen, worden daar niet meegeteld. Daarom kunnen aanmeldingen 12 tonen terwijl installaties dicht bij nul blijven.
Waarom faalt een Android-emulator bij Play Integrity?
Een standaard-emulator is geen gecertificeerde fysieke hardware en kan de hardware-ondersteunde attestatie niet genereren die MEETS_DEVICE_INTEGRITY vereist. Daarom levert hij een leeg apparaat-oordeel. De documentatie van Google noemt uitdrukkelijk een emulator die de Google Play Integrity-controles niet haalt als geval met die lege waarde. Build-eigenschappen spoofen om een echte telefoon na te bootsen verandert dat niet.
En Play-geschikte Android Studio emulator-images?
Een Android Studio system-image met Google Play kan de Play Store bereiken, maar de Store bereiken is niet hetzelfde als apparaat-Integrity halen. Play-geschikte emulator-images falen doorgaans nog steeds op apparaat- en Strong Integrity, omdat ze geen gecertificeerde fysieke hardware met vergrendelde, geattesteerde bootloader zijn. Het enige emulator-label dat slaagt, MEETS_VIRTUAL_INTEGRITY, geldt voor Google Play Games for PC, niet voor ontwikkelaar-test-emulators.
Is het tegen de regels om testers met emulators te faken?
Je eigen app op een emulator installeren om te checken dat hij draait, is normale ontwikkeling en prima. Nep-Google-accounts op emulators achter VPN's uitrollen om een testerpool te simuleren is manipulatie en schendt de Developer Program Policies van Google over onechte installaties. Dat kan tot afwijzing leiden en in ernstige of herhaalde gevallen tot handhaving op accountniveau.
Wat telt daadwerkelijk als geldige tester?
Een echt persoon op een echt, gecertificeerd Android-apparaat die je testlink accepteert, de app uit de Play Store met een echt Google-account installeert, over 14 achtereenvolgende dagen doorlopend aangemeld blijft en de app echt gebruikt. Sideload-installaties, kliks zonder installaties en gebroken 14-dagen-vensters tellen niet mee.
Wat is de snelste legitieme weg naar 12 testers?
Gebruik echte testers op echte apparaten en start de 14-dagen-klok vroeg. PrimeTestLab levert 12 echte, aangemelde testers vanaf $19.99, met teststart in ongeveer 4-6 uur, plus grotere pakketten met 20 en 25 testers als buffer tegen uitval die het doorlopende venster kan breken.
Kan ik BlueStacks gebruiken voor de gesloten test bij Google Play?
Nee. BlueStacks en vergelijkbare emulators zijn geen gecertificeerde fysieke apparaten, leveren een leeg Play Integrity apparaat-oordeel en tellen niet mee voor je 12 testers, precies zoals Android Studio emulators. Installeren uit de Play Store in de emulator verandert het apparaat-Integrity-resultaat niet. Gebruik in plaats daarvan echte Android-apparaten.
Kan Google zien of een tester een emulator gebruikt?
Google publiceert niet precies hoe emulators worden gemarkeerd. Behandel daarom elk concreet detectiepercentage als onbevestigd. Gedocumenteerd is dat de Play Integrity API een leeg apparaat-oordeel teruggeeft voor een emulator die de controles niet haalt, en dat Google installaties filtert die de plaatsing willen manipuleren. In de praktijk worden emulator-installaties doorgaans niet als geldige testers geregistreerd en kunnen ze worden gemarkeerd.
Heeft Google de eis van de gesloten test van 20 naar 12 testers verlaagd?
Ja. Google heeft het minimum op 11 december 2024 van 20 naar 12 testers verlaagd, nadat het hogere aantal voor kleinere ontwikkelaars als last werd ervaren. Het doorlopende 14-dagen-aanmeldvenster bleef ongewijzigd, en de eis geldt nog steeds alleen voor persoonlijke accounts die na 13 november 2023 zijn gemaakt.
Conclusie
Samenvatting
Je kunt een emulator voor de gesloten test bij Google Play niet betrouwbaar gebruiken. Standaard-emulators leveren een leeg apparaat-Integrity-oordeel, lopen niet via het echte Play Store-aanmeldpad en tellen daarom niet mee voor de eis van 12 testers en 14 dagen, terwijl het veinzen van een testerpool op grote schaal afwijzing of handhaving riskeert. De enige betrouwbare weg zijn echte testers op echte, gecertificeerde Android-apparaten met echte Google-accounts, vroeg gestart en met buffer boven 12. PrimeTestLab levert precies dat vanaf $19.99, met teststart in ongeveer 4-6 uur. Prijzen bekijken →