Publicatievereisten van Google Play voor nieuwe ontwikkelaars in 2026

Google Play werkt niet met één goedkeuring. Het houdt een release tegen achter een keten van losse poorten, en elke poort heeft zijn eigen regel over wie hij raakt. Een flink deel van wat hierna komt, geldt dus niet voor jou.

Elke vereiste hieronder draagt dezelfde vier dingen: voor wie die geldt, wat je doet, waaruit blijkt dat het klaar is en de officiële pagina waar het vandaan komt. Waar de eigen pagina’s van Google elkaar tegenspreken, en dat gebeurt hier op twee punten, krijg je beide versies in plaats van onze gok.

Publicatievereisten van Google Play in één oogopslag

Hieronder staat elke poort, met de regel die bepaalt of hij jou raakt en het bewijs in Play Console dat het klaar is. Rijen met de markering voorwaardelijk slaan sommige ontwikkelaars volledig over.

De volgorde waarin dit echt gebeurt

Acht fasen, en de volgorde is geen voorkeur: drie ervan zijn harde voorwaarden voor de fase erna.

1. Kies je ontwikkelaarsaccount en verifieer het Accounttype, de kosten, identiteit en de apparaatcontrole als Console die toont.
2. Maak de app aan en bereid een build voor die voldoet App-record en applicatie-ID, App Bundle en ondertekening, doel-API-niveau, preflight van de build.
3. Controleer de Android-ontwikkelaarsregistratie Een statuscontrole in Play Console zodra de app en het pakket bestaan.
4. Rond de Store-vermelding en het materiaal af Tekstlimieten, verplichte afbeeldingen, het iconenmasker, verklaringen over materiaal dat met AI is gemaakt.
5. Rond App-content en toegang voor beoordelaars af Privacy, Gegevensbeveiliging, verwijdering, classificatie, doelgroep, advertenties, de twee universele verklaringen en inloginstructies.
6. Voer de kwalificerende gesloten test uit 12 testers aangemeld gedurende 14 aaneengesloten dagen. Alleen voor persoonlijke accounts die na 13 nov. 2023 zijn gemaakt.
7. Vraag productietoegang aan De driedelige vragenlijst over je test, je app en je gereedheid.
8. Dien de productierelease in en publiceer die Landen, prijzen, de bundel, releaseopmerkingen, indienen ter beoordeling en daarna publicatie.

1. Kies je ontwikkelaarsaccount en verifieer het

Je hebt een Google-account met verificatie in twee stappen nodig, en bij de registratie ga je akkoord met de Developer Distribution Agreement en de servicevoorwaarden van Play Console. Daarna moeten er drie dingen rond zijn voordat je kunt publiceren: de kosten, je identiteit en, waar Console die toont, een apparaatcontrole.

Wat de kosten van US$ 25 wel en niet zijn

De kosten betaal je uitsluitend met een creditcard of debetkaart. Welke kaarttypen worden geaccepteerd, verschilt per land, en Google zegt expliciet dat prepaidkaarten niet worden geaccepteerd.

Persoonlijk of organisatorisch, en wanneer de keuze al vaststaat

Stel eerst de vraag over de categorie, want voor sommige apps valt er niets te kiezen.

Raakt geen van die categorieën jouw app, dan is de keuze aan jou. Beide typen kunnen publiceren en geld verdienen, dus een deel van het verschil is simpelweg wat Google over jou verifieert. Maar het is niet alleen papierwerk: een persoonlijk account dat na 13 november 2023 is gemaakt, moet ook een kwalificerende gesloten test draaien, en dat is de langste vaste stap in deze gids. Uitgebreidere vergelijking: persoonlijke versus organisatorische accounts.

Wat accountverificatie vraagt, en waarom de doorlooptijd verschilt

Google verifieert op accountniveau wie je bent voordat je kunt publiceren. Een persoonlijk account levert een officieel identiteitsbewijs van de overheid aan; een organisatie levert daarnaast organisatiegegevens aan. Wat er precies wordt gevraagd, kan afhangen van wat je betalingsprofiel al verifieert, en daarom krijgen twee mensen die dezelfde gids volgen niet dezelfde vragen. Je ontwikkelaarsidentiteit verifiëren

Google publiceert geen gegarandeerde verwerkingstijd voor de identiteitsbeoordeling van een Play-account, en de veelgeciteerde ‘tot 5 dagen’ is er geen: dat cijfer komt uit de betalingsdocumentatie van Google en niet van de Play-pagina over identiteit. Werk de taken af die Console toont en houd rekening met extra documentcontroles. Verificatie van je betaalmethode staat daar weer los van: dat is een verkoperscontrole die hoort bij het ontvangen van betalingen, geen stap die elke ontwikkelaar van een gratis app moet starten. Accountgegevens en verkoperscontroles

Klaar als: Play Console toont de taak voor identiteitsverificatie niet meer voor je account. Behandel ingediend en goedgekeurd als twee verschillende statussen: een ingediend document deblokkeert het publiceren nog niet.

Apparaatverificatie: de poort die de meeste gidsen missen

Nieuwe persoonlijke ontwikkelaarsaccounts hebben een aparte apparaattaak. Je bevestigt toegang tot een niet-gerooteerd fysiek mobiel Android-apparaat met Android 10 of hoger, via de mobiele app van Play Console en ingelogd als accounteigenaar. Vereisten voor apparaatverificatie

Wat het niet is: de identiteitscontrole, de kwalificerende gesloten test of een regel over je testers. Nergens staat dat de 12 mensen in je gesloten test aan die apparaatspecificatie moeten voldoen. Het is een eigen item op de pagina Home in Console, en met een emulator rond je het niet af.

Klaar als: De taak voor apparaatverificatie verdwijnt van je pagina Home in Play Console.

Later van accounttype wisselen

Je kunt een persoonlijk ontwikkelaarsaccount omzetten naar een organisatorisch account via de verificatieprocedure van Google: verifieer de website van de organisatie, maak of kies het betalingsprofiel en verifieer dat, en rond de wijziging daarna af in het bestaande account. Google adviseert om na de omzetting minstens 72 uur te wachten voordat je nieuwe apps indient. De andere kant op, van organisatorisch naar persoonlijk, heb je wel een nieuw account nodig. Accounttype omzetten

2. Maak je app aan en bereid een build voor die voldoet

Twee helften: het app-record dat je in Play Console aanmaakt, en het bestand dat je erin uploadt. Eén beslissing hier volgt de app zijn hele leven, dus die dertig seconden nu zijn goed besteed.

De beslissingen die definitief zijn

Als je de app in Play Console aanmaakt, leg je de naam, de standaardtaal, het type app of game en de status gratis of betaald vast. De applicatie-ID is iets anders: die staat in je buildconfiguratie en niet in dat formulier in Console, en de twee komen samen bij het uploaden. Controleer de applicatie-ID dus in je build voordat je uploadt, in plaats van aan te nemen dat een leeg record in Console die al heeft vastgelegd. Je app maken en instellenApplicatie-ID

Android App Bundle en de twee rollen bij ondertekening

Voor een gewone nieuwe openbare app accepteert Google Play de Android App Bundle (.aab) in plaats van een APK, en gebruikt de app Play App Signing. Die reikwijdte noemen we bewust één keer en niet als absolute regel: oudere apps die daarvoor in aanmerking komen hebben nog APK-workflows, App Bundles zijn sinds juni 2023 verplicht voor alle Android TV-apps, en distributie van privé-apps voor bedrijven werkt weer anders. App BundlesPrivé-apps

Play App Signing splitst twee rollen, en dat is niet hetzelfde als twee fysieke sleutels die je zelf bewaart. De app-ondertekeningssleutel wordt door Google beheerd en ondertekent wat gebruikers installeren. De uploadsleutel ondertekent je bundel vóór het uploaden, zodat Google weet dat die van jou komt. Beide rollen kunnen op dezelfde sleutel draaien of op aparte sleutels; een aparte uploadsleutel is de aanbevolen opzet, omdat die opnieuw kan worden ingesteld als je hem kwijtraakt. Je app ondertekenen

Doel-API-niveau, per formfactor

Dit is de vereiste die een upload het vaakst regelrecht blokkeert, en het is niet één getal: het verschilt per soort inzending.

Google beschrijft verlengingsperiodes die in bepaalde gevallen tot 1 november 2026 lopen, maar of jouw specifieke app daarvoor in aanmerking komt, wordt in Play Console bepaald. Vereisten voor doel-API-niveau De details over de migratie staan in de gids over het doel-API-niveau.

Preflight: wat een ogenschijnlijk geldige bundel alsnog afwijst

Twee controles vangen projecten op die er verder afgerond uitzien. Beide zijn voorwaardelijk: raakt geen van beide jouw app, sla dit dan over en ga verder.

Native libraries: 64-bits en een paginagrootte van 16 KB

Bevat je app native code, rechtstreeks, via een SDK of gegenereerd door een app-builder, controleer die dan op ondersteuning voor 64-bits en op compatibiliteit met een paginagrootte van 16 KB, en test hem in een 16 KB-omgeving. Apps die alleen in Java of Kotlin zijn geschreven, inclusief hun dependencies, ondersteunen de betreffende paginagrootte al. Controleer de bundel die je daadwerkelijk uploadt: een dependency kan zonder enige wijziging aan jouw kant opnieuw een 32-bits of op 4 KB uitgelijnde library binnenhalen. Paginagroottes van 16 KB64-bits

Versie van de Play Billing Library

Als, en alleen als, je app Play Billing integreert, hebben nieuwe inzendingen normaal gesproken versie 8 of hoger van de Billing Library nodig. De gewone deadline voor versie 7 was 31 augustus 2026, en een verlenging waarvoor je in aanmerking komt kan tot 1 november 2026 lopen. Niets hiervan raakt een app zonder die integratie, en het betekent niet dat al geïnstalleerde oudere apps stoppen met werken. Beëindigingsschema voor de Billing Library

Klaar als: Een ondertekende .aab uploadt zonder fout over het doel-API-niveau of het formaat, de versiecode ligt hoger dan alles wat je eerder hebt geüpload, en, als de app native code bevat, slagen zowel je compatibiliteitscontroles als een run in een 16 KB-omgeving. Dat Play Console een upload valideert, betekent niet dat je dependencies getest zijn; los blokkerende problemen op en lees de waarschuwingen.

3. Controleer de Android-ontwikkelaarsregistratie in Play Console

Dit komt na de vorige fase, omdat de app ervoor moet bestaan: registratie koppelt een app, met zijn pakketnaam en de vingerafdruk van de ondertekeningssleutel, aan een geverifieerde ontwikkelaarsidentiteit, en dat geldt voor het hele Android-ecosysteem en niet alleen voor Google Play. Het is iets anders dan de identiteitscontrole op accountniveau in fase 1, die aantoont wie je bent zodat je een account mag hebben.

Voor wie op Play publiceert, komt het neer op één praktische vraag: is je app geregistreerd? Controleer de status op de pagina Android-ontwikkelaarsverificatie in Play Console. Google probeert automatisch te registreren en hergebruikt de identiteitsverificatie die je al hebt gedaan, dus voor de meeste ontwikkelaars op Play is dit een statuscontrole en geen taak: je hebt geen apart account voor de Android Developer Console nodig en je doet de identiteitsverificatie niet nog een keer. Bevestig de registratie en werk elke openstaande actie af die Console daarbij toont. Play-pakketnamen registreren

Apps die niet geregistreerd blijven, lopen vanaf 30 september 2026 wereldwijd het risico uit Google Play te worden verwijderd. Dat is makkelijk te missen, omdat de meeste berichtgeving over die datum alleen de installatiefase in vier landen beschrijft, een ander onderdeel van hetzelfde programma. Twee dingen die je kunt negeren: het gratis Limited Distribution-account is bedoeld voor hobbyisten die naar een handvol apparaten distribueren en is geen gratis route naar Google Play; en de Android-ondergrens van de controle op het apparaat wordt inconsistent gedocumenteerd (de FAQ van Android Developers noemt 7 en hoger, Android Help noemt 8 en hoger), wat een onopgelost verschil tussen twee pagina’s van Google is en geen vereiste waar je iets mee moet. Android Help

Klaar als: De pagina Android-ontwikkelaarsverificatie in Play Console toont de app als geregistreerd, zonder openstaande actie ernaast.

4. Rond je Store-vermelding en het materiaal af

De vermelding is wat gebruikers en beoordelaars als eerste zien, en er gelden harde limieten die het opslaan tegenhouden. De nuttige scheidslijn loopt tussen wat Google vereist om te publiceren en wat Google aanbeveelt om uitgelicht te worden; die twee staan hieronder los van elkaar.

Vereist om te publiceren

Google Play Console · echte screenshot

Aanbevolen, maar geen voorwaarde om te publiceren

De richtlijnen van Google voor previewmateriaal beschrijven ook wat een vermelding geschikt maakt voor grote formaten en aanbevelingsplekken: meer screenshots, hogere resoluties en sets voor de apparaatklassen waarop je uitgelicht wilt worden. Ontbreekt daar iets van, dan blokkeert dat geen release. Vermeldingen voor Wear OS, TV en XR hebben daarbovenop hun eigen regels voor materiaal. Previewmateriaal

Het hoekmasker van het icoon

Je uploadt een volledig vierkant icoon en Google Play legt daar een dynamisch hoekmasker overheen met een straal van 30% van de icoongrootte, zodat alles vlak bij een hoek in het eindresultaat wordt weggesneden. Dit is de huidige specificatie en niet, zoals vaak wordt herhaald, een wijziging die in 2026 is ingevoerd. De wijzigingsdatum van een bronpagina zegt niets over wanneer een regel is ingegaan. Specificaties voor het ontwerp van iconen

AI-verklaringen voor gegenereerd storemateriaal

Genereer of bewerk je afbeeldingen, video of promotiemateriaal voor je vermelding met AI, dan bevat Play Console nu per onderdeel een eigen verklaring in de flows waarin je content maakt, met labels op materiaal dat binnen de geldende regelgeving valt. De helppagina van Google noemt geen startdatum en geen uitputtende lijst van de regels die eronder vallen, dus die verzinnen wij ook niet. Dit gaat over storemateriaal en staat los van het beleid over wat een generatieve app voor gebruikers produceert. Door AI gegenereerde content declareren

Metadataregels waarop vermeldingen worden afgewezen

De richtlijnen van Google voor vermeldingen zijn streng over promotionele taal in de velden die in zoekresultaten en op schappen verschijnen: de titel, het icoon, de ontwikkelaarsnaam en de korte beschrijving.

Klaar als: De Hoofd-Store-vermelding wordt opgeslagen zonder fout over ontbrekend materiaal, en de afbeeldingen die je hebt geüpload zijn na het hoekmasker nog steeds goed leesbaar.

5. Rond App-content en de toegang voor beoordelaars af

App-content is het onderdeel dat wie voor het eerst publiceert onderschat, omdat er geen techniek aan te pas komt en het toch alles blokkeert. Het is een stapel verklaringen, en een onvolledig of onnauwkeurig antwoord is een van de meest voorkomende redenen dat een launch stilvalt.

Privacybeleid: elke app, op twee plekken

Elke app heeft een privacybeleid nodig, niet alleen apps die op kinderen zijn gericht, zoals dit vaak wordt beschreven. Zet de link in Play Console en zet een link of de tekst van het beleid in de app zelf. Gebruik een actieve, openbare URL zonder geoblokkade, geen PDF. Een app die geen gegevens verzamelt, heeft er ook een nodig, en ‘wij verzamelen niets’ is geen beleid: het moet nog steeds de app en de ontwikkelaar benoemen, een contactpunt voor privacy geven en beschrijven hoe gegevens die de app wel raakt, worden verwerkt en bewaard. Beleid voor gebruikersgegevens

Gegevensbeveiliging

Elke app op de gesloten, open of productietrack vult het formulier Gegevensbeveiliging in. Apps die uitsluitend op de interne testtrack draaien, zijn vrijgesteld, en dat is een echte reden om de interne test vroeg in te zetten. Een app die niets verzamelt, vult het formulier ook in en geeft dat daar aan. Gegevensbeveiliging

Geef aan wat je app echt verzamelt en deelt, inclusief wat je SDK’s namens jou doen. Dat is het deel dat het vaakst fout gaat: een SDK voor analyse, advertenties of crashrapportage verzamelt gegevens, of jij die code nu hebt geschreven of niet, en de verklaring is van jou. Lees de documentatie van elke SDK afzonderlijk in plaats van aan te nemen dat een hele leverancier zich overal hetzelfde gedraagt.

Account- en gegevensverwijdering

Kunnen gebruikers een account maken in je app, dan moeten ze verwijdering kunnen aanvragen vanuit de app en van buitenaf, via een openbaar bereikbare web-URL, en moet het verwijderen van het account ook de bijbehorende gegevens verwijderen. Moet je op grond van de wet of een legitiem bedrijfsbelang iets bewaren, maak dat dan kenbaar.

Al het andere in App-content

Naast privacy, Gegevensbeveiliging, verwijdering en App-toegang hierboven blijven deze over. Twee ervan verrassen mensen, omdat de namen voorwaardelijk klinken: de verklaringen voor gezondheidsapps en financiële functies zijn verplicht voor een gewone openbare app op de gesloten, open of productietrack, ook als die geen van beide soorten functies heeft. Beide hebben een antwoord voor ‘geen functies’, en er een invullen betekent niet dat regels over medische of financiële vergunningen op jou van toepassing worden. Verklaring voor gezondheidsappsVerklaring voor financiële functies

Google Play Console · echte screenshot

Geef beoordelaars werkende toegang

Zit een deel van je app achter een inlog of een andere afscherming, vul dan App-toegang in. Play Console ondersteunt maximaal vijf sets instructies, dus sets instructies en niet per se vijf sets inloggegevens, en dat maakt uit als je één login en meerdere afgeschermde paden hebt. Je app voorbereiden op de beoordeling

Controleer vóór het indienen of de inloggegevens nog werken en of iemand anders dan jij elke afgeschermde functie kan bereiken. Verlopen accounts, eenmalige codes die op jouw telefoon binnenkomen en functies die alleen voor een intern account ontgrendelen, zijn de gebruikelijke struikelblokken.

Klaar als: App-content toont geen openstaande taak meer, en iemand anders dan jij kan inloggen met precies wat je in App-toegang hebt gezet.

Categoriespecifieke verklaringen

Naast de formulieren hierboven hangen sommige beleidsregels aan wat de app echt doet. Die zijn wel echt voorwaardelijk:

• Gezondheidsapps, voorbij de verklaring. Heeft de app echt gezondheidsfuncties, dan voegt het beleid Gezondheidscontent en -services daar labeling als medisch hulpmiddel en een disclaimerplicht voor niet-gereguleerde gezondheidsapps aan toe, en hebben gezondheidsapps van de genoemde soorten een organisatorisch account nodig. Gezondheidscontent en -services
• Apps met generatieve AI. Voorkom verboden uitvoer en geef gebruikers een manier om die in de app te melden of te markeren. Dit gaat over wat de app produceert en staat los van de verklaringen over storemateriaal hierboven; het is geen regel die elke app met AI-hulp een label geeft. Beleid voor door AI gegenereerde content
• Machtigingen voor foto’s en video’s. Vraag brede toegang alleen waar een kernfunctie die nodig heeft; gebruik anders de fotokiezer van het systeem.
• Locatie en contacten. Voor beide komen er eisen om de toegang zo klein mogelijk te houden, met concrete datums en een beperkte reikwijdte: zie deadlines en voorwaardelijke wijzigingen.
• Andere categorieën. Nieuws en tijdschriften, financiële diensten, overheidsapps en andere hebben elk een beleidspagina die vanuit App-content is gelinkt.

6. Rond de verplichte gesloten test af, als die voor jou geldt

Geldt voor: persoonlijke ontwikkelaarsaccounts die na 13 november 2023 zijn gemaakt. Organisatorische accounts en persoonlijke accounts van vóór die datum hebben deze eis helemaal niet; ben jij dat, ga dan door naar de release indienen.

De regel is kort: voer een gesloten test uit met minstens 12 testers die aangemeld zijn gedurende de 14 aaneengesloten dagen vóór je aanvraag voor productietoegang. De verlaging van 20 naar 12 testers ging in op 11 december 2024 en hield dezelfde 14 dagen aan. TestvereistenDe wijziging van 20 naar 12

Google Play Console · echte screenshot

Drie tracks, en maar één ervan telt

De interne test lijkt de voor de hand liggende kortere weg en is ook echt nuttig, alleen niet hiervoor.

Google beoordeelt twee dingen: je aantal testers en de betrokkenheid van je testers. De voorbeelden die Google zelf geeft van waarom het om meer testen vraagt, noemen onder meer testers die tijdens de test niet betrokken waren bij de app, dus 12 namen op een lijst zijn niet de vereiste. Wat Google niet publiceert, is een regel over minuten per dag of over sessies: heb je ergens een concreet dagcijfer gelezen, dan komt dat niet van Google en moet je je test er niet op plannen.

Hoe je er echt aan voldoet

Elke andere vereiste hier is papierwerk of techniek die je zelf in de hand hebt. Deze heeft 12 echte mensen nodig, op echte Android-apparaten, die zich aanmelden en 14 onafgebroken dagen aangemeld blijven.

Klaar als: Play Console toont 12 of meer aangemelde testers en een gesloten test die minstens 14 aaneengesloten dagen loopt, en de actie Productie aanvragen wordt beschikbaar op het Dashboard.

7. Vraag productietoegang aan, als dat voor jou nodig is

Geldt voor: dezelfde accounts als bij de gesloten test, dus persoonlijke accounts die na 13 november 2023 zijn gemaakt. Alle anderen gaan meteen door naar de release.

Voldoen aan de criteria van de gesloten test brengt je op zichzelf nog niet naar productie. Je dient de aanvraag in op het dashboard van Play Console en beantwoordt een vragenlijst. Die wordt vaak beschreven als een vast formulier met tien vragen; Google past de formulering in de loop van de tijd aan, dus onthoud hem liever als drie onderwerpen.

Schrijf het op vanuit de test die je echt hebt gedraaid. Geen enkele formulering garandeert goedkeuring; concrete details over echt testen en echte wijzigingen helpen wel. Algemene antwoorden zijn een bekende route naar het verzoek om meer te testen. Uitgewerkte voorbeelden laten zien hoe je je eigen test beschrijft, ze zijn geen script.

Google zegt dat deze beoordeling meestal zeven dagen of minder duurt, maar soms langer kan duren; plan op zeven dagen en behandel dat niet als een bovengrens. Timing van de beoordeling voor productietoegang Wordt toegang geweigerd, dan is de gebruikelijke uitkomst een verzoek om meer te testen en geen afwijzing, en je gesloten test hoeft niet te stoppen terwijl je een nieuwe aanvraag voorbereidt. Wat te doen na ‘meer testen vereist’.

Klaar als: Play Console toont dat productietoegang is verleend. Niets daarvóór, geen volledige checklist en geen volle 14 dagen, is die toekenning zelf; de beslissing ligt bij Google.

8. Dien de productierelease in en publiceer die

Productietoegang ontgrendelt, waar die geldt, de track; het publiceert nog niets. De release is een eigen reeks stappen, en het is de plek waar mensen aankomen met alles af en niets live. Een release voorbereiden en uitrollen

1. Landen en regio’s Begin smal en breid later uit als je dat wilt.
2. Prijzen Stel die in vóór de eerste release. Een gratis app kan later niet betaald worden onder dezelfde pakketnaam.
3. Voeg de bundel voor de release toe Kies een geschikte bundel die je al voor de test hebt geüpload, of upload een nieuwe build met een hogere versiecode. Een geteste build naar de productierelease verplaatsen vraagt op zichzelf niet om opnieuw bouwen.
4. Releasenaam en releaseopmerkingen De naam is intern; de opmerkingen zijn wat gebruikers bij deze versie zien.
5. Lees de fouten en waarschuwingen Console blokkeert bij fouten en laat waarschuwingen door. Lees ze allebei: juist de waarschuwing doet er later vaak toe.
6. Dien de wijzigingen in ter beoordeling Er is niets ingediend tot je dat doet. Een afgeronde releasepagina met niet-verzonden wijzigingen is een van de stilste manieren waarop een launch vastloopt.
7. Volg de beoordeling en de publicatie In beoordeling, klaar om te publiceren en live zijn drie verschillende statussen. Is beheerde publicatie beschikbaar en ingeschakeld, dan blijven goedgekeurde wijzigingen wachten tot jij Wijzigingen publiceren kiest; goedkeuring alleen is geen publicatie. Daarna kan het nog even duren voordat de vermelding verschijnt.

Klaar als: Het publicatieoverzicht toont geen niet-verzonden wijzigingen meer, en de productierelease staat op live, niet alleen op goedgekeurd. Waar beheerde publicatie geldt, is die laatste stap aan jou. Beheerde publicatie en publicatiestatussen

Hoelang publiceren duurt en wat kan overlappen

Vlak bij de finish liggen twee beoordelingen, en die staan los van elkaar: de beoordeling voor productietoegang na je vragenlijst, en de beoordeling van de release zelf. Google zegt dat de beoordeling voor toegang meestal zeven dagen of minder duurt maar langer kan duren, en dat de app-beoordeling in uitzonderlijke gevallen ook boven de zeven dagen kan uitkomen. Geen van beide is op een week gemaximeerd. Timing van beoordeling en publicatie Cijfers per fase: de gids over beoordelingstijden.

Welke stappen elkaar echt blokkeren

Het meeste hiervan kun je in willekeurige volgorde doen. Vier dingen niet, en weten welke vier is het verschil tussen een launch van drie weken en een van zes.

Een planningsschatting, duidelijk als zodanig aangeduid

Drie tot vijf weken of meer is een redelijke planning voor een nieuw persoonlijk account. Dat is onze planningsschatting en geen serviceniveau van Google, en hij gaat uit van een app die al grotendeels gebouwd is, testers die zich snel aanmelden en geen grote herzieningen. Het bouwen van de app zit niet in dat getal, en één ronde herwerk komt er nog bij.

Wat Console je vertelt, en waar je het oplost

Bijna elke stilstand verschijnt als een van zes meldingen. Lees welke je hebt in plaats van opnieuw in te dienen en te hopen.

Je checklist per fase

Geef aan welk account je hebt en waar je naartoe werkt. De checklist scheidt drie dingen die de gebruikelijke lijst door elkaar haalt: wat je nu nodig hebt, wat later vereist is en wat helemaal niet voor jou geldt. Het is een tracker voor jezelf: hij kan niet in je Play Console kijken, en hem afvinken is geen goedkeuring.

Actuele deadlines en voorwaardelijke beleidswijzigingen

Dit zijn de gedateerde punten die kunnen veranderen wat je bouwt of wanneer je uitbrengt. De meeste raken jouw app niet: lees de derde kolom voordat je op een ervan handelt.

Doorlopende vereisten zonder deadline

Deze gelden nu en staan in geen enkel overzicht van ‘wat er is veranderd’, en juist daarom verrassen ze mensen die dit proces een jaar of twee geleden hebben geleerd.

• Gesloten test: 12 testers, 14 aaneengesloten dagen, voor persoonlijke accounts die na 13 november 2023 zijn gemaakt. Het aantal daalde op 11 december 2024 van 20 naar 12 testers.
• Overdracht van accounteigendom loopt via de overdrachtsprocedure van Play Console. Directe overdracht van de eigenaar geldt voor organisaties en persoonlijke accounts die geen geld verdienen; een persoonlijk account dat wel geld verdient, gaat via een andere route met een nieuw account en een app-overdracht. Accounts kopen, leasen of verkopen via derden is verboden. Eigendom van een ontwikkelaarsaccount overdragen
• Organisatorische accounts zijn verplicht voor bepaalde apps voor financiële diensten, gezondheidsapps, goedgekeurde VpnService-apps en overheidsapps.
• Machtigingen voor foto’s en video’s worden nu gehandhaafd. Brede toegang alleen waar een kernfunctie die nodig heeft; gebruik anders de fotokiezer van het systeem.

PolicyBytes: beleidsupdates van april 2026

Het Developer Experience-team van Google over het beleid rond contacten en accountoverdracht en over de updates hierboven voor locatie en leeftijdsbeperkte content. Optioneel; de tabel bevat de versie waarmee je aan de slag kunt.

YouTube

Zo helpt PrimeTestLab bij de gesloten test

Zeven van de acht fasen zijn papierwerk en techniek die je zelf in de hand hebt. Eén fase heeft 12 echte mensen nodig, op echte Android-apparaten, aangemeld en echt actief gedurende 14 onafgebroken dagen. Dat is de stap waarop solo-ontwikkelaars vastlopen, en het enige deel dat wij doen.

Jij deelt de link voor aanmelden van je gesloten test. Wij regelen de uitnodiging, de bevestiging van de aanmelding, de dagelijkse monitoring van betrokkenheid en volledige retentie over 14 dagen, en vervangen iedereen die afhaakt. Elke app-taal, flexibele targeting op landen.

Huidige pakketten

Geld-terug-garantie · Testen start doorgaans binnen 4 tot 6 uur · Geen abonnement

Veelgestelde vragen

Wat je nu kunt doen

Waar elke vereiste vandaan komt

Elke claim hierboven die ertoe doet, linkt zijn bron op de plek zelf; dit is de overzichtsversie. De helppagina’s van Google zijn grotendeels ongedateerd, dus de wijzigingsdatum van een pagina zegt niets over wanneer een beleidsregel is ingegaan.

Wat er in deze herziening is veranderd

11 september 2026

Opnieuw opgebouwd aan de hand van de documentatie van Google, gecontroleerd op 8 september, en daarna nog eens herzien na een heraudit van die herbouw. Gecorrigeerd: de vereiste voor het doel-API-niveau (nu een matrix per formfactor); de volgorde van de voorwaarden rond de gesloten test; de omzetting van persoonlijk naar organisatorisch; de doorlooptijd van D-U-N-S; de reikwijdte van de registratiedeadline van 30 september 2026 en de route ernaartoe, die een statuscontrole in Play Console is nadat de app bestaat; contacten en locatie naar 27 januari 2027 bij API 37+, waarbij implementatie en verklaring stapelen; de specificaties voor icoon, screenshots en previewvideo; toegang voor beoordelaars als vijf sets instructies; de applicatie-ID als eigenschap van de build en niet van het record in Console; en de mechaniek van de release, want een geschikte geteste bundel kan opnieuw worden gebruikt, en goedkeuring is geen publicatie waar beheerde publicatie geldt. Toegevoegd: apparaatverificatie, de fasen voor het aanmaken van de app en voor de release, preflight voor native code en Play Billing, verklaringen over AI in storemateriaal, de verklaringen voor gezondheidsapps en financiële functies (ook verplicht zonder zulke functies), een tabel met blokkades, en een bron naast elke claim die ertoe doet. Verwijderd wegens gebrek aan onderbouwing: de migratiedatum van 28 januari 2026 voor gezondheidsaccounts, de mythe van de ‘vijf dagen’ voor identiteit, de uitleg over de Android-ID uit april 2025, de limiet van 1 MB voor de uitgelichte afbeelding en de ranking ‘#1 vermijdbare afwijzing’. De checklist voor gereedheid is twee keer opnieuw gebouwd: hij scheidt nu ‘later vereist’ van ‘niet van toepassing’, en leest ingediend werk niet langer als afgerond.

24 juni 2026

Voor het eerst gepubliceerd.