Zo maak je een Google Play-ontwikkelaarsaccount in 2026

De test van 14 dagen is het enige onderdeel van deze lijst dat van andere mensen afhangt, en precies daar lopen soloontwikkelaars vast. Het is het deel dat PrimeTestLab voor je uitvoert, en het komt aan bod bij hoe wij helpen aan het eind van dit artikel.

De meeste stappenplannen voor deze zoekvraag stoppen bij de betaalbevestiging, en de meeste klopten ook op het moment dat ze werden geschreven. Het probleem is wat Google er daarna bij heeft gezet: een identiteitscontrole die je documenten vergelijkt met een betalingsprofiel waar je misschien al jaren niet naar hebt gekeken, een apparaatverificatie voor nieuwe persoonlijke accounts, en een drempel voor productie waar de aanmaakdatum van je account je in trekt, waarna je hem app voor app moet nemen. Het resultaat is een vertrouwde reeks forumberichten, en ze beginnen allemaal hetzelfde. Ik heb de $ 25 betaald, waarom kan ik dan niets publiceren.

Dit artikel volgt de volgorde waarin de beslissingen je echt raken: wat je klaar moet hebben voordat je betaalt, wat elk accounttype moet aanleveren, wat de console vraagt en in welke volgorde, welke gegevens met welk record moeten overeenkomen, en wat een nieuw persoonlijk account Google nog schuldig is nadat het betaalbewijs binnen is. Waar Google een getal publiceert, staat erbij uit welk Help-antwoord het komt. Waar Google niets publiceert, zegt dit artikel dat gewoon, in plaats van een cijfer te lenen van een leverancierspagina die het ook niet weet. Alles hier is gecontroleerd aan de hand van de eigen documentatie van Google en is actueel per 13 augustus 2026.

Wat je klaarzet voordat je Google betaalt

De betaling van $ 25 wordt gezien als hét moment van commitment, omdat het de enige stap is die je bankrekening raakt. Het is het verkeerde ding om zenuwachtig van te worden. De stappen die je echt moeilijk terugdraait, zijn de stappen die niets kosten: het Google-account waarmee je toevallig bent ingelogd wordt de eigenaar van het account, en hoewel Google inmiddels een beperkte manier documenteert om het eigendom aan iemand anders over te dragen, is die niet voor elk account beschikbaar en is het geen schakelaar in de instellingen. De wettelijke identiteit die je invult, wordt datgene waarmee elk document dat je later uploadt wordt vergeleken, en een deel ervan wordt gepubliceerd op Google Play. Bij geen van beide wordt je gevraagd of je het zeker weet.

Over de kosten zelf zegt dit artikel één ding en gaat dan verder: het is $ 25, eenmalig per ontwikkelaarsaccount, geen jaarlijks abonnement en niet per app. De volledige uitleg over wat die kosten wel en niet dekken, staat in het artikel over de vereisten voor publiceren op Google Play.

Wat Google openbaar toont

Dit is het deel van de beslissing dat wordt overgeslagen, en het deel waar mensen met spijt op terugkomen. Een deel van wat je in het aanmeldformulier invult, staat bij je vermelding op Google Play en is voor iedereen te lezen. Een persoonlijk account is geen anoniem account, en zodra je monetiseert, wordt er meer zichtbaar.

Scroll de tabel zijwaarts om alle kolommen te zien

De checklist vóór registratie

De lijst hieronder zijn de vereisten van Google, geordend naar het moment waarop je ze nodig hebt en niet naar de Helppagina waar ze staan, en hij is bewust in drie fasen gesplitst. Fase 01 is wat het aanmeldformulier vraagt, en dat is de enige fase die het oordeel meeweegt. Fase 02 en fase 03 zijn echte vereisten die pas komen nadat je geld is overgemaakt, en een checklist die ze tot één score mengt, vertelt je dat je je niet kunt registreren voordat je 12 testers hebt gevonden, en dat is simpelweg onwaar. Twee regels brengen echte wachttijd mee, en het zijn allebei regels voor organisaties. Dat is de praktische reden om een organisatorische aanmelding nooit te starten op de dag dat je ertoe besluit.

Gereedheidscheck vóór betaling

De drie besluiten die je moeilijk terugdraait

Al het andere op die lijst herstel je met een formulier. Deze drie niet, of niet goedkoop.

Dit alles maakt goedkeuring niet zeker. Het haalt de mislukkingen weg die Google daadwerkelijk documenteert, en dat is iets anders en nuttigers. Wat het niet kan wegnemen, is het wachten: Google publiceert precieze tijden voor de smalle onderdelen van het proces en helemaal niets voor de identiteitsbeoordeling als geheel, waarover meer in het onderdeel over verificatie hieronder.

Persoonlijk of organisatorisch bij het aanmelden

Het eerste dat je moet weten, is dat dit geen systeem van niveaus is. Google zegt dat de twee accounttypen toegang hebben tot dezelfde algemene functionaliteit, en beide kunnen monetiseren via een betalingsprofiel. Niemand koopt een betere Play Console door zich als organisatie te registreren. Wat verschilt, is wat je moet aanleveren om binnen te komen, en welke verplichtingen je daarna volgen.

Vier categorieën waarin Google de keuze voor je maakt

Google noemt vier soorten apps waarvan de ontwikkelaars een organisatorisch account zouden moeten gebruiken, ongeacht hoe die ontwikkelaars zichzelf zien:

Valt je app in een van die groepen, dan is de vraag over het accounttype al beantwoord en wordt de levertijd van het D-U-N-S-nummer onderdeel van je bouwplanning in plaats van een bijzaak achteraf.

Wat elk type moet aanleveren

Deze tabel gaat alleen over de aanmeldbalie: waar Google elk type om vraagt, en wat elk type daarna met zich meedraagt. Of een organisatorisch account het waard is om er een bedrijf voor op te richten, is een andere vraag met voor bijna iedereen een ander antwoord, en die komt uitgebreid aan bod in persoonlijk of organisatorisch account.

Scroll de tabel zijwaarts om alle kolommen te zien

Kun je het accounttype later nog wijzigen?

Dit is het feit dat het vaakst verkeerd staat in wat je verder hebt gelezen. Jarenlang luidde het standaardadvies dat je het accounttype één keer kiest en dan voorgoed vastzit, en dat een ontwikkelaar die later een bedrijf startte een tweede account helemaal opnieuw moest registreren. De huidige documentatie van Google zegt dat niet. Die beschrijft een route voor omzetting, en maakt duidelijk onderscheid tussen de richting die wel wordt ondersteund en de richting die dat niet wordt.

Wat de omzetting werkelijk inhoudt

Het mechanisme is een wijziging van je betalingsprofiel en niet een schakelaar in Play Console, en juist daarom lees je er in de documentatie makkelijk overheen. Je maakt een Google Payments-profiel van het type organisatie of stapt daarnaar over, doorloopt de verificatie die bij dat profiel hoort, wat voor een organisatie het D-U-N-S-nummer en de organisatiedocumentatie betekent, en koppelt het aan het ontwikkelaarsaccount. De levertijd van het D-U-N-S-nummer geldt hier precies zoals bij de aanmelding, dus ook omzetten doe je niet even op één dag.

En de eigenaar, die vroeger voorgoed vastlag

Dit is de bewering die je het hardst moet bijstellen, want hij was lange tijd waar en wordt overal herhaald, ook in oudere versies van dit artikel. Google documenteert inmiddels een selfservice-overdracht van eigendom. Alleen de huidige accounteigenaar kan die starten, en het pad is Play Console, Users and permissions, zoek de persoon aan wie je het account wilt overdragen, Manage, en dan Make account owner. Daarna staat de overdracht zeven dagen in de wacht voordat hij wordt afgerond, en de beoogde eigenaar kan worden gevraagd om zijn identiteit te verifiëren en gegevens voor het betalingsprofiel aan te leveren.

Bij de voorwaarden wringt het nog steeds. Google beperkt de directe route tot organisatorische accounts en persoonlijke accounts die niet monetiseren, en zegt dat individuele ontwikkelaars die hun apps monetiseren er op dit moment niet voor in aanmerking komen. Juist de ontwikkelaar die dit het hardst wil, de solopublisher die zich als persoon registreerde, ging verdienen en het account nu bij zijn bedrijf wil onderbrengen, valt er dus buiten. Zijn route is onveranderd: een nieuw ontwikkelaarsaccount, helemaal opnieuw geverifieerd, met de apps die ernaartoe worden overgedragen.

Nog een waarschuwing in dezelfde lijn: een organisatietype kiezen waar je geen recht op hebt, is geen papieren sluiproute. Een organisatorisch account wordt geverifieerd tegen een echt bedrijfsregister dat door een derde partij wordt bijgehouden, en dat verzinnen is een beleidsprobleem en geen slimme omweg.

Aanmelden bij Play Console, stap voor stap

De registratie begint op play.google.com/console/signup. Zorg voordat je klikt dat je zeker weet met welk Google-account je browser is ingelogd, want dat is het besluit waar de flow je nooit op laat terugkomen.

De acht controlepunten

1. 01
   Log in met het Google-account dat eigenaar wordt van het account

   De eigenaar moet minstens 18 zijn. Het eigendom kun je achteraf overdragen, maar alleen in de gevallen die Google documenteert: organisatorische accounts en persoonlijke accounts die niet monetiseren, gestart door de huidige eigenaar, zeven dagen in de wacht, met verificatie van de nieuwe eigenaar. Een persoonlijk account dat monetiseert valt op dit moment buiten die route, dus voor veel ontwikkelaars is het account waarmee je toevallig bent ingelogd feitelijk nog steeds het definitieve account. Google vraagt om een Google-account en zegt nergens dat het een gmail.com-adres moet zijn, wat de tutorials ook beweren.

   Gaat mis wanneer: je bent ingelogd in een persoonlijk browserprofiel en registreert daarop het account van het bedrijf.

2. 02
   Kies persoonlijk of organisatorisch

   Persoonlijk is de optie van Google voor persoonlijk gebruik, waaronder studenten, hobbyisten en amateurontwikkelaars. Organisatorisch is voor bedrijven en organisaties. Vier app-categorieën stuurt Google door naar een organisatorisch account: financiële producten en diensten, gezondheidsapps waaronder medische apps en apps voor onderzoek met menselijke deelnemers, apps met goedkeuring voor VpnService, en overheidsapps.

   Gaat mis wanneer: een organisatorische aanmelding wordt gestart voordat het D-U-N-S-nummer bestaat.

3. 03
   Maak of selecteer een Google Payments-profiel van hetzelfde type

   De registratie koppelt aan een Google Payments-profiel, en het profieltype moet overeenkomen met het accounttype dat je hebt gekozen. Een bestaand persoonlijk profiel kan geen organisatorische registratie dragen. De identiteit op dit profiel is de referentie waarmee elk document dat je later uploadt wordt vergeleken, dus open het en lees het voordat je verdergaat.

   Gaat mis wanneer: een oud betalingsprofiel nog een adres bevat waar je jaren geleden bent weggegaan.

4. 04
   Vul je wettelijke gegevens, contactgegevens en openbare ontwikkelaarsgegevens in

   Typ de wettelijke naam en het adres precies zoals je identiteitsbewijs ze afdrukt. Je geeft een contact-e-mailadres en telefoonnummer op waarmee Google jou bereikt; die worden geverifieerd maar niet openbaar getoond, en daarnaast een openbaar e-mailadres voor ontwikkelaars dat wel op Google Play wordt getoond. Organisatorische accounts geven ook een openbaar telefoonnummer voor ontwikkelaars op. Telefoonnummers vul je in internationale notatie in.

   Gaat mis wanneer: het openbare e-mailadres voor ontwikkelaars een privéadres is dat je liever niet publiceert.

5. 05
   Accepteer de overeenkomst en betaal eenmalig $ 25

   Je accepteert de Google Play Developer Distribution Agreement en betaalt de eenmalige registratiekosten. Ze worden per ontwikkelaarsaccount gerekend, niet per app, en ze worden niet jaarlijks verlengd. De pagina van Google over geaccepteerde betaalmethoden noemt de kaartnetwerken die het accepteert, met regionale verschillen, en vermeldt dat prepaidkaarten niet worden geaccepteerd.

   Gaat mis wanneer: er wordt betaald op identiteitsgegevens die zijn gegokt in plaats van gecontroleerd. Google waarschuwt dat onjuiste identiteitsgegevens ertoe kunnen leiden dat de kosten niet worden terugbetaald.

6. 06
   Verifieer je contact-e-mailadres en telefoonnummer

   Google stuurt een code van zes cijfers naar het e-mailadres en een code van zes cijfers naar de telefoon, per sms of via een spraakoproep. Dit zijn de privécontactgegevens, de gegevens waarmee Google jou bereikt en niet de gegevens die bij je vermelding in de store staan.

   Gaat mis wanneer: de sms niet aankomt. Het gedocumenteerde antwoord van Google is de optie met een spraakoproep, daarna controles van signaal en provider, en niet een nieuw account aanmaken.

7. 07
   Doorloop de identiteitsverificatie

   Aan een persoonlijk account kan een officieel identiteitsbewijs van de overheid worden gevraagd, als het gekoppelde betalingsprofiel nog niet is geverifieerd. Aan een organisatorisch account kunnen het D-U-N-S-nummer, een officieel document van de organisatie en een identiteitsbewijs van een vertegenwoordiger worden gevraagd, en voor nieuw aangemaakte organisatorische accounts geldt een aanvullende eis rond websiteverificatie. Alles wat je indient, moet overeenkomen met het betalingsprofiel.

   Gaat mis wanneer: het document en het profiel op één regel van elkaar afwijken. Google noemt die overeenkomst als vereiste, en het is de fout die de meeste threads in de Help Community over dit onderwerp vult.

8. 08
   Verifieer een echt Android-apparaat, bij een nieuw persoonlijk account

   Nieuwe persoonlijke accounts ronden een apparaatcontrole af in de mobiele Play Console-app voordat een app beschikbaar kan worden gesteld op Google Play. Google eist een fysiek, niet-geroot apparaat met Android 10 of hoger, en zegt dat de controle zelf minder dan een minuut duurt.

   Gaat mis wanneer: je volledig op een emulator ontwikkelt en zelf geen geschikte telefoon hebt. Google staat toe dat hetzelfde apparaat meer dan één account verifieert, dus er een lenen is een gedocumenteerde optie.

Wat er na het achtste controlepunt komt

Die acht ronden het account af. Ze ronden niet de route naar een gepubliceerde app af, en het is de moeite waard om precies te zijn over de volgorde van wat daarna komt, want veel pagina’s wekken de indruk dat je de test met 12 testers moet doen voordat je een app mag aanmaken. Het tegenovergestelde is waar. Je maakt eerst de app, rondt de instellingen, de vermelding in de store en de verklaringen af, uploadt een build en publiceert een release naar een gesloten track, want de kwalificerende test draait op die release. Pas dan gaat de klok van 14 dagen lopen. Als die afloopt, kom je in aanmerking om productietoegang aan te vragen, beoordeelt Google de aanvraag, en gaat de release naar productie uit nadat die toegang is verleend.

Er is één kanttekening bij die volgorde, en die zit in het verschil tussen een test voorbereiden en een test uitvoeren. De verificatie van je account blokkeert nog steeds de release zelf: Google zegt dat een ontwikkelaarsaccount geverifieerd moet zijn voordat apps ter beoordeling kunnen worden ingediend, en bij een nieuw persoonlijk account moet de controle op een echt apparaat zijn afgerond voordat een app beschikbaar kan worden gesteld op Google Play. De app aanmaken, hem configureren en de vermelding in de store schrijven kun je dus allemaal doen terwijl de identiteitsbeoordeling nog loopt. De release naar de gesloten track publiceren waar de klok van 14 dagen op loopt, niet. Reken op de overlap die je werkelijk krijgt, en dat is voorbereiding en geen verstreken testdagen. Geverifieerd

Twee beweringen die je elders tegenkomt, zijn het benoemen waard zodat je ze meteen kunt wegwuiven. De eerste is dat je voor de aanmelding een adres nodig hebt dat eindigt op @gmail.com: de aanmeldpagina van Google vraagt om een Google-account, en dat kun je aanmaken op een adres dat je al hebt. De tweede is dat Google een ontwikkelaarsaccount “doorgaans activeert” binnen 24 tot 48 uur. Zo’n toezegging staat nergens in de huidige documentatie van Google, en een lanceerplan daarop bouwen is precies hoe een releasedatum in het openbaar verschuift. Geen gepubliceerde SLA

Documenten, regels voor overeenkomst en de vertraging die niemand publiceert

Bij de verificatie houdt het proces op een formulier te zijn en wordt het een vergelijking. Google leest je document niet om te ontdekken wie je bent. Het legt je document naast een record dat het al heeft, en waar een organisatie in het spel is, naast een tweede record dat bij Dun and Bradstreet ligt. Google formuleert de eis onomwonden: wat je indient moet overeenkomen met de gegevens in je gekoppelde betalingsprofiel. In de threads van de Help Community die voor dit artikel zijn bekeken, kwamen de afwijzingen met een aanwijsbare oorzaak allemaal neer op records die het oneens waren over een naam, een adres of één ontbrekende adresregel.

Waar elk accounttype om wordt gevraagd

Scroll de tabel zijwaarts om alle kolommen te zien

De regel van exacte overeenkomst, voordat je uploadt

De regel is simpel te formuleren en simpel te overtreden: de wettelijke identiteit op het document, de identiteit in het gekoppelde Google Payments-profiel en, bij een organisatie, de identiteit op het Dun and Bradstreet-record moeten alle drie overeenkomen. Niet herkenbaar dezelfde persoon zijn. Overeenkomen. Een ontbrekende tweede voornaam, een straat die aan de ene kant is afgekort en aan de andere kant voluit staat, een appartementnummer dat wel op het document staat maar nooit in het profiel is beland, een accent dat is weggelaten omdat een formulier het niet accepteerde: elk daarvan is genoeg om een document terug te krijgen.

De tool hieronder is een tekstvergelijking, geen goedkeuringscontrole en geen nabootsing van de beoordeling van Google. Google publiceert de eis dat de gegevens moeten overeenkomen; het publiceert niet welke vergelijking het werkelijk uitvoert, hoe het omgaat met afkortingen of leestekens, hoe het translitereert, of wat het verder meeweegt. Deze tool leest dus de twee teksten die je geeft en benoemt het verschil dat hij kan zien. Alles wat hij je vertelt, gaat over je eigen tekst.

Consistentiechecker voor je profiel

Wat Google wel van een tijd voorziet, en wat het openlaat

Hier verzinnen concurrerende pagina’s getallen. Verschillende tutorials die nu goed scoren, noemen een identiteitsbeoordeling van “een paar uur tot twee werkdagen” of een account dat “doorgaans binnen 24 tot 48 uur wordt geactiveerd”. Geen van beide cijfers staat in de huidige documentatie van Google. Wat Google wél publiceert, is veel smaller en veel bruikbaarder, omdat elk gepubliceerd cijfer bij een specifieke handeling hoort en niet bij het hele proces.

Scroll de tabel zijwaarts om alle kolommen te zien

De controle op een Android-apparaat

Deze raakt een specifieke en groeiende groep: ontwikkelaars die bouwen op een emulator, op een laptop van de zaak, of op een apparaat dat juist geroot is omdat ze nu eenmaal het type zijn dat Android-apps maakt. Er is geen route via de desktop. De controle draait in de mobiele Play Console-app, op echte hardware.

Timing speelt hier op één specifieke manier: dit is een drempel voor het beschikbaar stellen van een app en niet voor het aanmaken van het account. Je kunt je registreren, je identiteit laten verifiëren en de app bouwen zonder dit te doen, en er dan op het slechtst denkbare moment achter komen. Het kost een minuut als je de hardware hebt en een week als je er nog een moet vinden, en dat is precies het argument om het op dag één te doen.

Wat een nieuw persoonlijk account meekrijgt

Dit is het onderdeel dat mensen verrast, en het verrast ze omdat het op twee niveaus tegelijk werkt. Of de regel jou überhaupt raakt, wordt bepaald door je account: persoonlijk, gemaakt na de peildatum. Maar wat je vervolgens moet doen, wordt bepaald door de app, want Google formuleert het zo dat je een gesloten test moet uitvoeren voor je app, en de aanvraag voor productietoegang gaat daarna over die app, de test die je ervoor hebt uitgevoerd en hoe klaar die is. Je kunt de app dus eerst bouwen, alles goed doen, de beoordeling doorstaan en toch merken dat productie niet beschikbaar is, omdat de verplichting met het account binnenkwam en op de app moet worden ingelost. De peildatum geldt sinds 13 november 2023, dat is 1.027 dagen geleden, dus tenzij je werkt met een ontwikkelaarsaccount dat je jaren geleden hebt opgezet, geldt hij voor jou.

Hoe de regel op 12 uitkwam

Er circuleren twee getallen, en maar één daarvan is actueel. Lees je een pagina waar 20 testers staat, dan lees je een pagina van vóór december 2024 of een pagina die daarvan heeft overgeschreven.

1. 13 nov 2023
   De peildatum

   Persoonlijke ontwikkelaarsaccounts die na deze datum zijn gemaakt, vallen onder de testvereisten. De datum staat onveranderd op de huidige beleidspagina van Google.

2. Eind 2023
   Begonnen met 20 testers

   De eis begon met minimaal 20 testers gedurende 14 dagen. De eigen communitydocumentatie van Google legt het oorspronkelijke aantal vast, naast threads uit de Help Community van diezelfde periode. Historisch

3. 11 dec 2024
   Verlaagd naar 12 testers

   Google kondigde de verlaging aan in een bericht op de Play Developer Community met de titel “Reduced testing requirements for Personal developer accounts”. De duur van twee weken bleef staan. Achtergrond: waarom Google van 20 testers naar 12 ging.

4. 13 aug 2026
   Huidige regel: 12 testers, 14 aaneengesloten dagen

   Minimaal 12 testers die doorlopend aangemeld zijn geweest gedurende minimaal de afgelopen 14 dagen, voordat een persoonlijk account dat eronder valt productietoegang kan aanvragen. Wat dat van dag tot dag betekent, staat in de regel van 14 aaneengesloten dagen.

Waarom de andere tracks niet meetellen

Een veelgebruikte poging om hieromheen te werken is een track kiezen die makkelijker te vullen is. Dat werkt niet, en de reden staat in de formulering: het beleid vraagt specifiek om een gesloten test.

Scroll de tabel zijwaarts om alle kolommen te zien

De volledige vergelijking van de drie testtracks, inclusief wanneer elk daarvan echt het juiste middel is, staat in interne, gesloten en open tests vergeleken. Bij het aanmaken van je account is het smaller: alleen de gesloten track haalt de drempel, en die kost minimaal twee weken echte kalendertijd die je niet kunt indikken.

Wat een afmelding je werkelijk kost

De veelgehoorde versie van deze regel is dat één keer onder de 12 zakken het venster breekt en dat alles dan opnieuw begint. Dat is niet wat de voorwaarde van Google zegt, en het verschil is echt geld waard in verspilde weken.

De toets wordt aangelegd op het moment dat je de aanvraag doet: er moeten dan minimaal 12 testers aangemeld zijn, en elk van die 12 moet de afgelopen 14 dagen doorlopend aangemeld zijn geweest. Google zegt uitdrukkelijk dat testers die zich aanmelden, korter dan 14 dagen testen, zich afmelden en zich daarna weer aanmelden, niet meetellen, omdat de 14 dagen aaneengesloten moeten zijn. Samen levert dat drie gevolgen op die de meeste pagina’s verkeerd hebben:

• Meer dan 12 is een buffer, geen opsmuk. Als 15 testers voldoen en er eentje vertrekt, voldoen er nog 14 en loopt er niets vertraging op. Pas wanneer er minder dan 12 zijn die elk de volle ononderbroken 14 dagen kunnen aantonen, moet je wachten.
• Een vervanger begint bij nul. De nieuwe tester erft de dagen niet die de vertrokken tester al had gemaakt. Zijn eigen 14 aaneengesloten dagen beginnen op de dag dat hij zich aanmeldt.
• De testers die bleven, houden hun historie. Als één persoon vertrekt, zet dat de klok van niemand anders terug, en juist dat heeft de versie van “alles begint opnieuw” het hardst mis.

Wat er gebeurt als de 14 dagen erop zitten

Je komt in aanmerking om de aanvraag te doen. Google vraagt je vervolgens naar de test die je hebt uitgevoerd: hoe testers de app hebben gebruikt, welke feedback je hebt verzameld, wat je daardoor hebt aangepast, voor wie de app bedoeld is en waarom hij klaar is. Het is een geschreven aanvraag met een beoordeling van vlees en bloed erachter, geen teller die om middernacht op dag veertien omslaat. De vragen zelf, en hoe je ze zonder opvulsel beantwoordt, staan in het artikel over de vragenlijst voor productietoegang.

Nog iets over de betrokkenheid van testers, want daar tieren verzonnen regels welig. De meetbare drempel is doorlopend aangemeld zijn: 12 testers, aangemeld, gedurende 14 ononderbroken dagen. Google publiceert op de huidige beleidspagina geen quotum voor dagelijks gebruik, en elke pagina die je vertelt dat elke tester de app een vast aantal minuten per dag moet openen, beschrijft iets wat Google nergens heeft opgeschreven. Betrokkenheid wordt apart beoordeeld, via wat je in de aanvraag rapporteert, en niet als een getalsmatige drempel boven op het aantal testers. Geverifieerd

Wees ook voorzichtig met de stellige versie van het verhaal over waar de testers vandaan komen. De gepubliceerde eis van Google schrijft geen enkele wervingsbron voor, en de eigen richtlijnen wijzen eerst naar je persoonlijke en professionele netwerk, met vrienden, familie, collega’s en klasgenoten met naam genoemd, en daarna naar communities waar je waarschijnlijke gebruikers al zitten. Dat is een richtlijn en geen beperkte lijst, dus een legitieme testdienst wordt er niet door uitgesloten. Wat het niet is, is een algemeen “het maakt Google niet uit wie je testers zijn”: Google vraagt om een diverse, representatieve groep en verwacht echte betrokkenheid en feedback, en installaties, ratings of reviews manipuleren is een beleidsprobleem, hoe je de mensen ook hebt gevonden. Geverifieerd

Aanmeldproblemen en hoe je ze oplost

Tien symptomen, met de gedocumenteerde oplossing per stuk

De situaties hieronder zijn de situaties waarvoor Google oplossingen publiceert, verwoord zoals ontwikkelaars ze in de Help Community werkelijk beschrijven en niet zoals de beleidspagina’s ze noemen. Staat jouw symptoom er niet bij, dan is dat ook iets waard: meestal betekent het dat het antwoord niet gedocumenteerd is, en dan is de eerlijke volgende stap de support van Play Console in plaats van een gok op een forum.

Stagnatiewijzer

Als het antwoord niet op die lijst staat

In de threads van de Help Community uit 2026 zit een patroon dat geen enkele lijst met oplossingen kan verhelpen: ontwikkelaars die een impasse in de verificatie beschrijven, waarbij het account niet geverifieerd kan worden en supporttickets sluiten zonder inhoudelijk antwoord. Die meldingen zijn echt en komen vaak genoeg voor om ze eerlijk te noemen, maar ze zijn ook zelfselecterend, want een ontwikkelaar bij wie de verificatie gewoon slaagt, schrijft er geen bericht over. Niets in dit artikel kan je een uitweg uit die lus beloven. Wat het wél kan, is je uit de lussen houden die een gedocumenteerde oorzaak hebben, en dat is de meerderheid. Gemeld door de community

Nog één onderscheid om vast te houden, want het veroorzaakt een hele categorie misplaatste paniek: de identiteitscontrole op je ontwikkelaarsaccount is niet hetzelfde als het aparte, ecosysteembrede verificatieprogramma voor Android-ontwikkelaars met zijn eigen tijdlijn in 2026. Dit artikel gaat over het afronden van de verificatie in Play Console. Dat andere programma, en wat het betekent voor installaties buiten Google Play om, komt aan bod in het artikel over verificatie van Android-ontwikkelaars.

Belangrijke vereisten in 2026 die je eerste release kunnen blokkeren

Het aanmaken van een account en de vereisten voor apps zijn twee gescheiden systemen, en het is zo gebeurd dat je het ene afrondt terwijl je stilletjes op het andere strandt. Je kunt een keurig geverifieerd ontwikkelaarsaccount hebben en toch niets kunnen uitbrengen, omdat de build zelf niet aan een actuele vereiste voldoet. De rijen hieronder zijn de vereisten die een gloednieuw account daadwerkelijk raken; welke daarvan voor jou gelden, hangt af van wat je app doet.

• 31 aug 2026
  Nieuwe apps en updates moeten zich richten op Android 16 (API 36)

  Geldt voor mobiele indieningen, zowel nieuwe apps als updates van bestaande apps. Andere apparaatvormen hebben hun eigen niveaus. De volledige uitsplitsing per apparaattype staat in het artikel over het target-API-niveau.

  Van kracht
• 31 aug 2026
  Apps die Google Play Billing gebruiken, moeten op Billing Library 8 of hoger draaien

  In het uitfaseringsschema van Google valt de deadline voor nieuwe apps en updates op Play Billing Library 7 op deze datum, met een eindpunt voor uitstel op 1 november 2026. Het raakt alleen APK-bestanden die het recht com.android.vending.BILLING nodig hebben, dus heeft je eerste app geen in-app-aankopen of abonnementen, dan geldt het niet voor jou. Heeft hij die wel, dan is dit een afhankelijkheid in je build die je liever nu ontdekt dan bij het indienen.

  Van kracht
• 30 sep 2026
  Registratie van Play-packagenamen

  Elk Play-package moet geregistreerd zijn, maar nieuwe apps die in Play Console worden gemaakt, worden normaal gesproken automatisch geregistreerd. Meestal is dit dus een status om te bevestigen en geen taak om uit te voeren. Bevestig het ook echt in plaats van het aan te nemen. Dit staat los van het ecosysteembrede verificatieprogramma voor Android-ontwikkelaars, dat aan bod komt in het artikel over verificatie van Android-ontwikkelaars.

  Meestal automatisch
• 1 nov 2026
  Einde van het venster voor uitstel

  Hetzelfde eindpunt geldt voor beide vereisten van 31 augustus: de overstap naar het target-API-niveau en die naar de Play Billing Library. Uitstel vraag je aan, het gaat niet vanzelf, en het wordt zichtbaar via de beleidsstatus en meldingen in Play Console. Registreer je nu een account, ga er dan van uit dat je bouwt naar de actuele vereiste en niet naar uitstel.

  Als het wordt verleend
• Voorwaardelijk
  Contactenrechten, alleen als je app contacten leest

  Het nieuwe Contacts Permissions-beleid van Google regelt brede toegang tot de contacten van een gebruiker voor apps die zich richten op Android 17 (API 37) en hoger. Beide bronnen van Google noemen nu dezelfde ingangsdatum, 27 januari 2027: de deadlinetabel in Play Console en de beleidspagina op Android Developers komen overeen, allebei opnieuw opgehaald op 14 augustus 2026. In eerdere communicatie van Google circuleerde voor dit beleid de datum 28 oktober 2026; die datum is achterhaald. Het volledige gedateerde register staat in het artikel over de beleidsupdates van 2026. Geverifieerd

  Meeste apps: negeren

Dat zijn de data in 2026 die een gloednieuw account het waarschijnlijkst raken, en dit artikel houdt daar bewust op in plaats van een beleidskalender te worden. Dat is geen belofte dat niets anders op die kalender jou kan raken: er landen het hele jaar door categoriespecifieke beleidsregels, en welke daarvan jouw app raken, hangt volledig af van wat je app doet. Wil je het volledige gedateerde register, dan is het artikel over beleidsupdates daarvoor bedoeld, en dat is de pagina om te raadplegen voordat je bouwt in plaats van erna.

Hoe PrimeTestLab helpt

Kijk nog eens naar de lijst met voorbereidingen aan het begin van dit artikel. Elke regel daarop kun je alleen afwerken, op je eigen tempo, met één uitzondering. Het identiteitsbewijs, het betalingsprofiel, de codes, de apparaatcontrole: allemaal solowerk. 12 mensen vinden die een onafgemaakte app installeren, zich met het juiste Google-account aanmelden en twee weken aangemeld blijven zonder af te haken, is geen solowerk, en dat is de reden dat een eis van twee weken standaard uitloopt tot twee maanden.

Zelf doen of uit handen geven

Beide kolommen voldoen aan dezelfde eis van Google. Het verschil zit in waar het werk en het risico liggen. De eerste kolom is eerlijk gelabeld: alleen de eerste twee rijen zijn genummerde voorwaarden die Google ook echt publiceert. Betrokkenheid is iets wat de beoordelaar van je aanvraag voor productietoegang meeweegt en geen drempel die je kunt halen, en spreiding over apparaten is goede QA-praktijk die Google aanmoedigt maar niet omzet in een aantal apparaten dat je moet halen.

Scroll de tabel zijwaarts om alle kolommen te zien

We hebben deze test uitgevoerd voor 7.400+ apps in 120+ landen, en we doen dit inmiddels 5+ jaar. Ons cijfer van 99,9% is een percentage afgeronde tests, en het is goed om precies te zijn over wat dat meet: bij de beheerde test bleef het vereiste aantal aangemelde testers ononderbroken staan gedurende de volle 14 dagen. Het is geen goedkeuringspercentage. Wat je ervoor krijgt, is een afgeronde gesloten test die voldoet aan de eis die Google daadwerkelijk heeft opgeschreven. Je koopt er geen productietoegang mee, en niemand kan je die verkopen: Google beoordeelt de aanvraag daarna en beslist erover, en precies daarom houdt de eerlijke versie van dit aanbod op waar hij ophoudt.

Wil je het werven liever zelf doen, dan is dat een legitieme keuze en dit artikel gaat niet net doen alsof dat niet zo is. Zeven legitieme manieren om 12 testers te vinden behandelt de routes die werken, en of een betaalde testdienst het waard is is geschreven om je te helpen ertegen te beslissen waar dat het juiste antwoord is.

Veelgestelde vragen

De kern

De test van 14 dagen is het enige onderdeel van dit alles waar je andere mensen voor nodig hebt, en dat is precies het deel dat PrimeTestLab voor je uitvoert. Bekijk de pakketten →