Android-ontwikkelaarsverificatie 2026: data en stappen

Bijna alles wat er in 2025 over Android-ontwikkelaarsverificatie is geschreven, klopt inmiddels op minstens één belangrijk punt niet meer, en dat geldt voor verrassend veel van wat er begin 2026 is geschreven ook. De opzet van het programma veranderde na de eerste aankondiging, de exacte handhavingsdatum kwam pas in juni 2026, en de reikwijdte werd op 22 juli 2026 zwart op wit versmald. Ondertussen typen ontwikkelaars helemaal niet "wat is ontwikkelaarsverificatie?" in de zoekbalk. Ze typen: Google zegt dat het mislukt is, wat is er precies mis, wat nu, en had ik dit niet allang gedaan?

Daarom is dit artikel geschreven als incidentafhandeling, niet als beleidsbeschouwing. Het beantwoordt eerst de vraag "ben ik al klaar?", geeft je de precieze route door Play Console in plaats van vaag advies, scheidt de twee handhavingslagen die elke andere pagina tot één enge zin samenperst, en is expliciet over de plekken waar Google niets heeft gepubliceerd. Het trekt ook een harde grens tussen verificatie en de losse eis van een gesloten test met 12 testers, want die verwarring landt bijna elke week in de inbox van PrimeTestLab. Elke datum en elk getal hieronder is op 9 augustus 2026 tegen de eigen pagina's van Google gecontroleerd.

Android-ontwikkelaarsverificatie zijn twee taken, niet één

Als je op Google Play publiceert, vraagt Android-ontwikkelaarsverificatie twee losse dingen van je: je identiteit verifiëren, en de packagenamen van je apps registreren. De meeste bestaande Play-ontwikkelaars hebben het eerste al gedaan en in de overgrote meerderheid van de gevallen ging het tweede automatisch. Voor veel accounts is het resterende werk het bekijken van twee schermen, al publiceert Google geen doorlooptijd die voor iedereen geldt en kan een probleem met documenten of het account fors langer duren.

Wat elke poort werkelijk vaststelt

De twee taken beantwoorden twee verschillende vragen, en de ene halen zegt Google niets over de andere. Ze uit elkaar houden is het waardevolste wat je van deze pagina kunt meenemen, want de manieren waarop het misgaat, de oplossingen en zelfs de schermen in Play Console verschillen.

Een account kan dus volledig geverifieerd zijn op identiteit en tegelijk een niet-geregistreerde package stilletjes in de lijst hebben staan. Precies die combinatie ontploft op de deadline, want de ontwikkelaar keek naar het scherm waar "geverifieerd" staat en opende nooit het scherm met de lijst apps.

Het antwoord van één minuut voor bestaande Play Console-gebruikers

Publiceer je al op Google Play, dan is dit het hele nalevingspad in de volgorde waarin je het hoort te controleren. De meeste lezers stoppen bij stap twee.

1. 01

   Bevestig je identiteitsstatus

   Open Ontwikkelaarsaccount in Play Console. De verificatiegids van Google beschrijft de route als Instellingen › Ontwikkelaarsaccount, terwijl de nieuwere documentatie over accountbeheer Ontwikkelaarsaccount › Over jou gebruikt. Hoe dan ook stelt Google dat je die stap niet opnieuw hoeft te doorlopen als je de identiteitsverificatie al met succes hebt afgerond. Gecontroleerd

2. 02

   Bevestig dat elke package geregistreerd is

   Open de pagina Android-ontwikkelaarsverificatie in Play Console en bekijk de registratiestatus van elke app. Ook de startpagina van Play Console kan informatie over appregistratie tonen. Zijn al je packagenamen automatisch geregistreerd, dan zegt Google dat er voor die apps geen verdere registratieactie nodig is. Gecontroleerd

3. 03

   Claim wat overblijft voor 30 september

   Voor een package die niet automatisch is geregistreerd volg je de handmatige registratie van Google. Welke vorm die krijgt hangt af van de packagenaam: een naam die Android nog nooit heeft gezien vraagt alleen de packagegegevens en je openbare ondertekeningscertificaat, terwijl een naam die al installaties heeft een ondertekende challenge-APK vraagt die aantoont dat je de privésleutel hebt. Beide werkwijzen staan in sectie 05.

Publiceer je op Google Play, gebruik dan Play Console

Dit is de valkuil die ontwikkelaars een uur laat omrijden. Er zijn twee consoles in dit programma. Play Console is waar Google Play-ontwikkelaars beide taken afronden. De Android Developer Console is een losse omgeving voor ontwikkelaars die buiten Google Play distribueren, en de hulppagina's daarvan beschrijven een andere route, inclusief verificatie van de website van de organisatie via Google Search Console. Beide sets instructies ranken op dezelfde zoekopdrachten.

Vier distributieroutes, vier antwoorden. Zoek je eigen rij voordat je nog een woord van Googles documentatie leest, want de verkeerde rij kost je een middag:

Routekaart uit Googles verificatiegids voor Play Console en zijn gids voor beperkte distributie, geraadpleegd op 13 augustus 2026. Gecontroleerd

De verificatietijdlijn van 2026, en de ene datum die artikelen nog steeds fout hebben

Verificatie kwam niet met één aankondiging. Ze kwam met vijf, en elke aankondiging versmalde of corrigeerde de vorige. De chronologie hieronder neemt het materiaal van Google uit juni en juli 2026 als leidende bron, en dat is belangrijk omdat de veelgeciteerde voorspelling uit maart achterhaald is.

Hoe het programma werkelijk arriveerde, mijlpaal voor mijlpaal

Elk item zet naast wat Google publiceerde wat een Play-ontwikkelaar eruit hoort te halen, want een aantal van deze data wordt elders los geciteerd en leest heel anders zodra je de volgorde ziet.

1. November 2025

   Vroege toegang gaat open

   Ontwikkelaars die voor vroege toegang waren uitgenodigd, konden beginnen met het verifiëren van apps die buiten Google Play worden gedistribueerd.

   Wat je eruit haalt: alleen een historische mijlpaal. Hier ontstaat vandaag geen verplichting voor een Play-ontwikkelaar.

2. 30 maart 2026

   De uitrol naar alle ontwikkelaars begint

   Google kondigde aan te beginnen met de uitrol van Android-ontwikkelaarsverificatie naar alle ontwikkelaars, zowel in Play Console als in de Android Developer Console, en zei tegen Play-ontwikkelaars dat ze de komende weken op toegang moesten letten. Gecontroleerd

   Wat je eruit haalt: lees dit niet als "elk Play-account kreeg verificatie op 30 maart". Google schrijft zelf dat de uitrol die dag begon.

3. Juni 2026

   De systeemservice Android Developer Verifier wordt uitgerold

   De bijgewerkte tijdlijn van Google plaatst de uitrol van de verifier-systeemservice in juni 2026. Gecontroleerd

   Wat je eruit haalt: gebruik juni. Het bericht van 30 maart voorspelde april, en verschillende artikelen van derden herhalen die voorspelling nog steeds alsof het geschiedenis is.

4. 18 juni 2026

   De exacte handhavingsdatum landt

   Google kondigde 30 september 2026 aan als eerste handhavingsdatum, noemde de zeven deelnemende stores en zei dat ruim 99% van de apps van Play-ontwikkelaars al geregistreerd was. Gecontroleerd

   Wat je eruit haalt: dit is de sterkste losse bron, zowel voor de datum als voor het cijfer over automatische registratie. Alles wat daarvoor verscheen, gokt over de datum.

5. Juli 2026

   Gereedschap: de ID Status API en de Console API

   De Android Developer ID Status API werd wereldwijd uitgerold, met de Console API en beperkte distributie in vroege toegang.

   Wat je eruit haalt: relevant voor teams die automatiseren en gereedschap bouwen, niet voor iemand die voor het eerst publiceert en Play Console met de hand doorloopt.

6. 15 juli 2026

   De huidige gidsen verschijnen

   De algemene verificatiegids van Google en de gids voor Play Console werden bijgewerkt, inclusief de eerste reikwijdte van de stores en de instructies voor registratie van Play-packages. Gecontroleerd

   Wat je eruit haalt: behandel deze twee pagina's als de leidende actuele documentatie voor alles wat operationeel is.

7. 22 juli 2026

   De FAQ versmalt de reikwijdte zwart op wit

   De FAQ van Google verduidelijkte dat stores buiten de deelnemerslijst en directe installatie niet onder de fase van 30 september vallen. Gecontroleerd

   Wat je eruit haalt: dit is de zin die het kader uit 2025 ("Google stopt op die datum met directe installatie") met pensioen stuurt. Het is een beperking van de eerste fase, geen permanente uitzondering.

8. Augustus 2026

   Gepland voor wereldwijde beschikbaarheid: beperkte distributie en de geavanceerde procedure

   Googles verificatiepagina noemt accounts voor beperkte distributie, de Android Developer Console API en de geavanceerde installatieprocedure als lanceringen van augustus 2026. Op 13 augustus 2026 zegt de eigen gids voor beperkte distributie nog steeds dat aanmelden voor early access gesloten is en dat er in augustus 2026 meer informatie volgt, dus deze regel is getekend als gepland en niet als geleverd. Deels, lancering niet bevestigd

   Wat je hieruit haalt: dit is het snelst bewegende punt op deze pagina, en dat de kalender in augustus staat is geen bewijs dat het uit is. Kijk op Googles verificatiepagina voor de actuele status in plaats van op een artikel dat midden in de maand is gepubliceerd, dit artikel inbegrepen.

9. 30 september 2026

   Er gebeuren twee dingen op dezelfde dag

   Appregistratie wordt verplicht voor installaties via de zeven deelnemende stores in Brazilië, Indonesië, Singapore en Thailand. Los daarvan moeten volgens de eisen van Play Console alle Play-packages geregistreerd zijn, en Google zegt dat apps die niet geregistreerd zijn van Google Play worden verwijderd. Gecontroleerd

   Wat je eruit haalt: één datum, twee losstaande gevolgen. Sectie 03 scheidt ze zoals het hoort.

10. 2027 en verder

    Wereldwijde uitbreiding, datum niet aangekondigd

    Google zegt dat de bescherming in 2027 wereldwijd wordt uitgebreid. Op 9 augustus 2026 is er geen exacte wereldwijde datum en geen verder landenschema aangekondigd. Gecontroleerd

    Wat je eruit haalt: behandel elke deadline van "1 januari 2027" of "begin 2027" die je elders leest als een voorspelling. Google heeft er geen gepubliceerd.

Is 30 september 2026 een wereldwijde deadline?

Nee voor de handhaving op Android-apparaatniveau, en ja voor de registratiedeadline van Google Play-packages. Dat zijn twee verschillende regels die toevallig een datum delen, en bijna elk artikel over dit programma gooit ze op één hoop. De regel op apparaatniveau begint in vier landen via zeven stores. De Play-regel geldt voor je vermelding in Play, en Google omschrijft het gevolg van het missen ervan als wereldwijde verwijdering uit Google Play.

De vier landen en de zeven stores

Google noemt beide lijsten precies, dus er valt niets te interpreteren. De eerste handhavingsfase dekt appinstallaties in deze vier landen:

En hij geldt voor installaties via deze zeven deelnemende appstores:

Beide lijsten komen uit de aankondiging van Google van 18 juni 2026 en de verificatiegids van 15 juli 2026, geraadpleegd op 9 augustus 2026. Google kan stores of regio's toevoegen, dus controleer de bron opnieuw voordat je vlak voor de datum op deze lijst afgaat.

Geldt 30 september voor jou? Los je eigen route op

Beantwoord twee vragen en de tool hieronder legt beide lagen op jouw distributieroute. Hij is bewust direct over de gevallen waarin het antwoord van Google "nog niet" is, want "nog niet" is niet hetzelfde als "nooit".

Zo controleer je of je al geverifieerd bent

Twee schermen beantwoorden de hele vraag. Ontwikkelaarsaccount bevat je identiteit en accountgegevens. De pagina Android-ontwikkelaarsverificatie bevat de registratiestatus van elke app. Open je alleen ooit het eerste, dan kun je denken dat je een controle hebt gehaald die je in werkelijkheid niet hebt gedaan.

De vier plekken waar een status kan opduiken

Van status naar actie, zonder labels te verzinnen

Google publiceert waar je moet kijken en wat je moet doen. Google publiceert geen volledige woordenlijst met identiteitsstatussen van Play, dus dit artikel verzint er geen. De tabel hieronder is geordend op wat je controleert en hoe klaar eruitziet, en dat is precies het deel dat Google wel documenteert.

Routes en de definities van "klaar" uit de hulp van Play Console antwoord 16984799, de verificatiegids van Google voor Play Console en de hulppagina over accountgegevens van ontwikkelaars; de rij over de gesloten test uit de hulp van Play Console antwoord 14151465. Allemaal geraadpleegd op 9 augustus 2026. De navigatie-items staan hier in het Nederlands omdat Play Console daadwerkelijk gelokaliseerd is: jouw console kan iets andere woorden tonen, en de pagina's van Google gebruiken op dit moment twee verschillende formuleringen voor de identiteitsroute. De navigatie van Play Console verandert vaak, dus behandel elke route hier als geldig op het moment van controleren, niet als permanent.

Wat "automatisch geregistreerd" werkelijk betekent

Automatische registratie gaat over één smalle relatie: de koppeling tussen de packagenaam van een app en de ondertekeningsgegevens die bewijzen wie hem beheert. Google zegt dat geschikte apps met Play App Signing onderdeel zijn van het automatische registratieproces, omdat Google de benodigde eigendoms- en ondertekeningsgegevens al heeft.

Zijn al je packagenamen met succes automatisch geregistreerd, dan zegt Google dat er voor die Play-apps geen verdere registratieactie nodig is. Die zin doet precies zoveel als hij zegt en niet meer.

Bij dat laatste punt is het de moeite waard even stil te staan. Registratie geldt per package, dus een account met zes apps kan vier zesde klaar zijn en nergens iets alarmerends tonen, behalve op die ene pagina waar ze allemaal staan. Google presenteert verificatie bovendien als het vaststellen wie de ontwikkelaar is, en omschrijft dat als losstaand van de veiligheidscontrole op de inhoud van apps. Niets hiervan zegt dus iets over de vraag of je app aan het beleid van Play voldoet.

Wat je doet als een app niet automatisch is geregistreerd

Handmatige registratie heeft twee vormen, en welke jij krijgt hangt af van de packagenaam, niet van jou. Voor een packagenaam die Android nog nooit heeft gezien lever je de packagegegevens en het openbare certificaat van je ondertekeningssleutel. Voor een packagenaam die al installaties heeft bewijs je daarnaast dat je de bijbehorende privésleutel beheert, door een APK te uploaden met een stukje tekst dat Google je geeft. Alleen het tweede geval heeft een ondertekende challenge-APK nodig, en geen van beide gevallen heeft je echte productie-APK nodig.

Bepaal eerst in welk geval je zit

Vijf rijen, en vandaag hoor je bij precies één ervan. Dit verkeerd inschatten is de duurste fout van deze sectie, want de challenge-APK-route is bouwwerk en drie van deze rijen hebben die helemaal niet nodig.

Onderscheid tussen de gevallen uit de Play Console-Help, "Registering Android package names" (antwoord 16761053), geraadpleegd op 13 augustus 2026. Gecontroleerd

A. Een nieuwe packagenaam registreren

De korte route. Alles gebeurt in Play Console, niets komt in de buurt van je buildomgeving en er is geen APK te maken.

1. 01

   Open de pagina Android-ontwikkelaarsverificatie

   Open in Play Console de pagina Android-ontwikkelaarsverificatie en loop de registratiestatus van elke packagenaam op het account na. Ook de startpagina van Play Console kan registratie-informatie over apps tonen.

2. 02

   Kies Packagenaam registreren

   Dit start een nieuwe registratie in plaats van een claim op een naam die al bestaat.

3. 03

   Vul de packagenaam en een herkenbare naam in

   De herkenbare naam is een intern label voor je eigen lijst. Het is niet wat gebruikers op je Store-vermelding zien.

4. 04

   Kies Sleutel toevoegen

   Hier begint de koppeling tussen een ondertekeningssleutel die jij beheert en de packagenaam die je registreert.

5. 05

   Lever het openbare ondertekeningscertificaat aan

   Geef het openbare certificaat uit het ondertekeningssleutelpaar van je app. Omdat Android deze packagenaam nog nooit heeft gezien, is dat certificaat alles wat Google nodig heeft. Je privésleutel verlaat je machine nooit.

6. 06

   Verstuur en wacht op de bevestiging

   Google stuurt een e-mail zodra de packagenaam met succes is geregistreerd, en de bijgewerkte status wordt zichtbaar in Play Console.

B. Een bestaande packagenaam registreren

Dit is de langere route, en degene die elk artikel beschrijft alsof het de enige is. Hij geldt wanneer de packagenaam al installaties op Android heeft, want dan neemt Google je niet op je woord: je moet het beheer over de privésleutel aantonen. Twee van deze stappen gebeuren buiten Play Console, dus zet je buildomgeving open voordat je begint.

1. 01

   Vul de packagegegevens in

   Start op de pagina Android-ontwikkelaarsverificatie de registratie van de packagenaam die je claimt.

2. 02

   Open Sleutel selecteren

   Google biedt de certificaten aan die het voor deze packagenaam geschikt acht, op basis van installatiebewijs.

3. 03

   Kies een geschikte vingerafdruk van een openbaar certificaat

   Neem de vingerafdruk van de sleutel die je echt hebt. Wordt er niets geschikts aangeboden, stop dan hier en lees eerst de geschiktheidsregels verderop voordat je iets anders probeert.

4. 04

   Start de eigendomsprocedure en kopieer het stukje tekst van Google

   Google genereert een uniek stukje tekst voor deze claim. Kopieer het exact. Dat is de waarde die bewijst dat de APK die je zo gaat bouwen voor precies deze challenge is gemaakt.

5. 05

   Maak assets/adi-registration.properties

   Maak in de assets-map van een APK-project een bestand met exact de naam adi-registration.properties. Het pad en de bestandsnaam zijn allebei letterlijk. Een typefout hier is de meest voorkomende manier waarop deze stap misgaat.

6. 06

   Plak het stukje tekst in dat bestand

   Er hoeft niets anders in. Het bestand bestaat puur om die tekst te dragen.

7. 07

   Bouw een release-APK

   Google zegt dat je hem kunt bouwen vanuit de echte applicatie of vanuit een leeg project met dezelfde packagenaam. Het lege project is meestal sneller en veiliger, omdat er niets van je productiecode bij betrokken is.

8. 08

   Onderteken hem met de bijbehorende privésleutel

   Daar draait de hele oefening om. De handtekening is het bewijs, niet de inhoud.

9. 09

   Upload hem via Play Console

   Upload de ondertekende challenge-APK in de eigendomsprocedure. Dit is geen release, het bereikt geen enkele gebruiker en je echte productie-artefact blijft erbuiten.

10. 10

    Houd de status en de bevestigingsmail in de gaten

    Google stuurt een e-mail zodra de packagenaam met succes is geregistreerd, en de bijgewerkte status wordt zichtbaar in Play Console.

C. Als een andere appstore je ondertekeningssleutel beheert

Sommige stores ondertekenen namens de ontwikkelaar, waardoor je zelf geen correct ondertekende challenge-APK kunt maken. Google documenteert daar een aparte route voor, en die is kort:

1. 01

   Bouw de release en upload hem naar die store

   Laat de build met het stukje tekst door het normale releaseproces van dat andere platform lopen.

2. 02

   Download bij die store de definitieve ondertekende APK

   Je hebt het artefact nodig zoals de store het heeft ondertekend, niet zoals jij het hebt geüpload.

3. 03

   Upload die door de store ondertekende APK naar Play Console

   De handtekening van de store is wat de eigendomscontrole vervult.

Stappen uit de Play Console-Help, "Registering Android package names" (antwoord 16761053), geraadpleegd op 13 augustus 2026. Gecontroleerd

Later meer sleutels toevoegen

Eén packagenaam kan meer dan één ondertekeningssleutel hebben. Google zegt dat de console het toelaat om meerdere ondertekeningssleutels voor één package toe te voegen en te verifiëren, en de procedure spiegelt route B: maak assets/adi-registration.properties met het stukje tekst voor die sleutel, bouw en onderteken een release-APK met de bijbehorende privésleutel, en upload hem. Registreer eerst de packagenaam, voeg daarna de extra sleutels toe.

Als er geen geschikte sleutel wordt aangeboden: de voorrangsregels

De meeste ontwikkelaars zien dit nooit. Het telt wanneer een packagenaam in de loop van zijn leven door meer dan één sleutel is ondertekend, of wanneer meer dan één partij een plausibele claim heeft. Google lost dat op met een rangorde op basis van installaties.

Rangorde van geschiktheid uit de Play Console-Help antwoord 16761053, geraadpleegd op 13 augustus 2026. Gecontroleerd

De praktische lezing, zorgvuldig geformuleerd: voldoet je ondertekeningssleutel duidelijk aan de rangorde hierboven, dan hoort hij als direct geschikt voor de claim te verschijnen. Dat bepaalt of Google je direct laat registreren in plaats van via een beoordeeld verzoek. Het rondt de registratie niet voor je af. Een package dat buiten de automatische registratie is gevallen, moet nog steeds met de hand door route B. De trede wie het eerst komt, het eerst maalt is degene waar je snel op moet doorpakken, want die wordt beslist door wie handelt, niet door wie gelijk heeft.

Wat persoonlijke ontwikkelaarsaccounts moeten insturen

Twee lagen: informatie die overal geldt, en documenten die per land verschillen. Het deel dat overal geldt is dat je wettelijke identiteits- en adresgegevens exact moeten overeenkomen met het Google Payments-profiel dat aan het account hangt. Het documentdeel hangt volledig af van het land of de regio in dat profiel, en daarom kan geen eerlijk artikel je één checklist voor de hele wereld geven.

Het deel dat overal hetzelfde is

Persoonlijke accounts leveren wettelijke identiteits- en accountgegevens aan, en de huidige hulp van Play noemt daarbij de wettelijke naam en het wettelijke adres. Het verificatieproces gebruikt het gekoppelde Google Payments-profiel, en de pagina met documenteisen van Google stelt dat de persoonlijke identiteitsgegevens, waar van toepassing de naam van de organisatie, en de adresgegevens exact moeten overeenkomen met de gegevens in je betaalprofiel.

Dat woord "exact" draagt deze hele sectie, en het is de reden dat de volgende tool bestaat.

Het deel dat niet overal hetzelfde is

De eigen pagina van Google zegt dat de geaccepteerde documenten afhangen van je geografische locatie. De landenkiezer op die pagina is de autoriteit voor jouw situatie, niet een lijst die elders is overgeschreven. Om de vorm van de eis concreet te maken zonder te doen alsof hij universeel is: dit vraagt de pagina van Google voor de Verenigde Staten op dit moment aan particulieren.

De beeldvereisten die Google ronduit noemt

Deze gelden voor het identiteitsbewijs met foto zelf en zijn ondubbelzinnig, waardoor ze de goedkoopste oorzaken zijn om weg te nemen voordat je iets uploadt:

• Het door de overheid uitgegeven identiteitsbewijs met foto moet geldig en niet verlopen zijn.
• De afbeelding moet in kleur zijn.
• De afbeelding moet scherp en goed belicht zijn.
• De afbeelding mag geen fotokopie zijn.

Google stelt daarnaast dat de huidige pagina met documenteisen niet-ondersteunde documenten aanwijst als de belangrijkste reden dat ontwikkelaarsverificatie mislukt, en dat valse of bewerkte documenten kunnen leiden tot zware maatregelen, waaronder verwijdering van account en apps. Niets op deze pagina is dat risico waard.

De controle die je doet voordat je iets uploadt

Google publiceert niet hoeveel verificatiepogingen je krijgt, en ontwikkelaars melden regelmatig dat ze in een toestand belanden waarin de knop om het opnieuw te proberen simpelweg niet meer zichtbaar is. Die combinatie maakt een slordige inzending echt duur. Doe eerst deze controle.

De fout die je controleert voordat je iets uploadt

Neem je één instructie mee uit dit artikel, neem dan deze: open je Google Payments-profiel en vergelijk de wettelijke naam en het adres veld voor veld met je documenten voordat je de uploadknop aanraakt. Google eist dat de gegevens overeenkomen; Google publiceert geen regel op teken- of leestekenniveau, dus behandel "veld voor veld" als de praktische manier om aan de eis te voldoen, niet als een eigen regel.

De eerste helft daarvan is de door Google zelf gestelde eis. De tweede helft is waar de hulpforums in 2026 vol mee staan. Discussies uit april, juni, juli en augustus 2026 hebben allemaal dezelfde vorm: een ontwikkelaar weet zeker dat de documenten kloppen, de verificatie mislukt zonder specifieke reden, en de community wijst terug naar een verschil tussen de ingestuurde identiteit en het betaalprofiel. In verschillende van die discussies ontdekte de ontwikkelaar het naamprobleem in het profiel pas na een afgewezen bezwaar.

Wat organisatorische accounts nodig hebben

Organisaties verifiëren met wettelijke organisatiegegevens in plaats van met een persoonlijke identiteit, en ze hebben doorgaans een D-U-N-S-nummer nodig: een unieke identificatie van negen cijfers die Dun and Bradstreet uitgeeft. De Play-documentatie van Google noemt uitzonderingen voor bepaalde overheidsinstanties. Google zegt dat ontwikkelaars die er geen hebben het gratis kunnen aanvragen, maar waarschuwt dat het weken kan duren, en daarmee is dit het enige onderdeel op deze pagina met een echte doorlooptijd. De eigen pagina's van Google zijn het oneens over hoeveel weken: de FAQ over Android-verificatie zegt tot 28 dagen en de huidige accounthulp van Play Console zegt tot 30. Dit artikel plant op 30.

Wat een organisatie verder klaarlegt

• Wettelijke organisatiegegevens die overeenkomen met je inschrijving, plus de bevoegde vertegenwoordiger en de accountgegevens.
• Het D-U-N-S-nummer van negen cijfers, gratis aan te vragen bij Dun and Bradstreet en met de door Google genoemde uitzonderingen voor bepaalde overheidsinstanties. Die uitzonderingen zijn smal: ze betekenen niet dat overheidsinstanties verificatie overslaan.
• Relevante organisatiedocumentatie en identiteitsdocumenten van de vertegenwoordiger, met dezelfde eisen van exacte overeenkomst en dezelfde landspecifieke regels als bij persoonlijke accounts.
• Een geverifieerde website, als je een organisatie bent die volledig buiten Google Play distribueert. De verificatiegids van Google zegt dat organisaties een website opgeven die via Google Search Console geverifieerd moet worden. Die stap hoort bij de route van de Android Developer Console, niet bij Play Console.

Eén ding verandert een organisatorisch account niet: publiceer je ook op Google Play, dan blijft dit werk in Play Console. En weeg je persoonlijk tegen organisatorisch af voor een nieuw account, dan reiken de voors en tegens veel verder dan verificatie. Dat is een keuze die het vergelijk tussen persoonlijke en organisatorische accounts netjes uitwerkt.

Wat er echt gebeurt als je op 30 september niet geverifieerd bent

Vier verschillende dingen, afhankelijk van hoe je app bij je gebruikers komt. Google documenteert beperkingen op nieuwe installaties, op updates waar de regels gelden, en verwijdering uit Google Play voor niet-geregistreerde Play-packages. Google documenteert niet dat apps die al op iemands telefoon staan gedwongen worden verwijderd.

Gevolgen uit de hulp van Play Console antwoord 16984799, de verificatiegids van Google voor Play Console, het uitrolbericht van 30 maart, de tijdlijn in de hulp van de Android Developer Console en de FAQ van 22 juli. Allemaal geraadpleegd op 9 augustus 2026.

De bewering waar je het voorzichtigst mee moet zijn

Dat onderscheid is geen muggenziften. Het verandert wat je deze maand moet doen. Verwijdering uit Play is een distributienoodgeval dat je oplost door een package te registreren. Een hypothetische massale verwijdering zou een noodgeval in je klantrelatie zijn en om totaal andere communicatie vragen. Slechts één van de twee is gedocumenteerd.

Hoe de geavanceerde procedure echt werkt

Google documenteert de geavanceerde procedure als een bewust traag pad en niet als een schakelaar, en die wrijving is precies de bedoeling: elke stap bestaat om te voorkomen dat iemand je er telefonisch doorheen praat terwijl het gesprek nog loopt.

1. 01

   Zet ontwikkelaarsmodus aan in de systeeminstellingen

   Een bewuste eerste zet, zodat hier niets per ongeluk of via een omzeiling met één tik zoals bij oplichting in gang wordt gezet.

2. 02

   Bevestig dat niemand je aan het sturen is

   Een snelle check dat niemand je onder druk zet om een beveiliging uit te schakelen.

3. 03

   Start de telefoon opnieuw op en verifieer je opnieuw

   Dit verbreekt toegang op afstand of een lopend gesprek dat iemand zou kunnen gebruiken om mee te kijken.

4. 04

   Kom terug na de beschermende wachttijd

   Google beschrijft het als een eenmalige wachttijd van één dag. Daarna bevestig je met biometrische verificatie of de pincode van het toestel.

5. 05

   Installeer van niet-geverifieerde ontwikkelaars

   Je kunt het zeven dagen of onbeperkt toestaan. Er blijft bij elke installatie een waarschuwing komen en die bevestig je zelf.

Stappen van de geavanceerde procedure uit Googles FAQ over Android-ontwikkelaarsverificatie, geraadpleegd op 13 augustus 2026. Gecontroleerd

De vraag over directe installatie, in één alinea

De fase van 30 september geldt nog niet voor directe installatie en ook niet voor appstores buiten de deelnemerslijst van Google, en Google blijft installatie via ADB ondersteunen plus een geavanceerde flow voor gebruikers die bewust van een niet-geverifieerde ontwikkelaar willen installeren. Dat is het actuele, gedocumenteerde standpunt op 9 augustus 2026, en het verschilt wezenlijk van het kader "Google stopt met directe installatie" dat na de eerste aankondiging in 2025 rondging. Het is ook uitdrukkelijk een eerste fase, dus het als vaststaande uitkomst behandelen zou de spiegelbeeldige fout zijn. Ben je hier terechtgekomen vanwege de gevolgen voor directe installatie en een open ecosysteem in plaats van vanwege een Play-deadline, dan verdient dat een eigen behandeling en geen alinea binnen een nalevingsartikel.

Verificatie vervangt de gesloten test met 12 testers niet

Dit zijn twee losstaande eisen waar je allebei aan moet voldoen als ze allebei op jou van toepassing zijn. Android-ontwikkelaarsverificatie beantwoordt "van wie zijn dit account en deze package?". De regel voor productietoegang beantwoordt "is deze app door echte mensen getest?". Je kunt de ene perfect halen en volledig geblokkeerd blijven door de andere.

De eis van Google voor nieuwe persoonlijke ontwikkelaarsaccounts die eronder vallen, verandert door niets in het verificatieprogramma: minimaal 12 testers die de afgelopen 14 dagen doorlopend aangemeld waren voor een gesloten test op het moment dat je productietoegang aanvraagt.

De verificatiekolommen komen uit de verificatiegids van Google en de hulp van Play Console antwoord 16984799; de kolommen over de gesloten test uit de hulp van Play Console antwoord 14151465 en de hulppagina over interne tests. Allemaal geraadpleegd op 9 augustus 2026. Gecontroleerd

Waarom mensen hierin trappen

Omdat allebei "eisen" heten, allebei in Play Console leven en allebei tussen een ontwikkelaar en een gepubliceerde app in staan. Een account dat net de identiteitsverificatie heeft gehaald, voelt daarom af. Vervolgens wordt productietoegang geweigerd, en niets in de verificatieschermen legt uit waarom, want dat antwoord woont niet in die schermen.

De volgorde die een nieuw persoonlijk account daadwerkelijk live krijgt is: identiteit geverifieerd, elke package geregistreerd, en apart daarvan een gesloten test met minimaal 12 testers die 14 dagen doorlopend aangemeld waren voordat je productietoegang aanvraagt. De regel van 14 aaneengesloten dagen kent meer randgevallen dan de meeste ontwikkelaars verwachten, en dat is het deel van deze volgorde dat je niet kunt inkorten door harder te werken.

Telt een interne test in plaats daarvan mee?

Nee, en het is de moeite waard precies te zijn over waarom, want "een interne test is nutteloos" klopt ook niet. Google staat interne tests toe met tot 100 testers, en dat is een echt goede manier om snel problemen te vinden. Maar de eis voor productietoegang noemt specifiek een gesloten test die voldoet aan de voorwaarde van 12 testers en 14 dagen. De interne test is een aparte track, dus deelname daaraan is niet de kwalificerende test voor deze specifieke eis.

Ook organisatorische accounts verdienen hier één verhelderende zin: de testeis voor productietoegang is uitdrukkelijk geschreven voor nieuwe persoonlijke ontwikkelaarsaccounts, dus organisatorische accounts zijn niet de accountsoort die onder deze specifieke regel van 12 testers valt. Dat staat los van verificatie, die beide accounttypen wel raakt.

Is de verificatie mislukt, controleer dit dan voordat je het opnieuw probeert

Ontwikkelaars melden vaak afwijzingsberichten zonder concrete reden, en Google documenteert de oorzaak van elke afzonderlijke afwijzing niet. De nuttige zet is dus niet gokken naar de betekenis van het bericht, maar de eisen aflopen die Google wel publiceert. Kies hieronder het symptoom dat je ziet. Elk symptoom levert het eerste wat je moet controleren op, hoe sterk het bewijs achter dat advies is, en de veilige volgende stap.

Begin bij het symptoom dat je echt ziet

De tien items hieronder zijn geformuleerd zoals ontwikkelaars ze op de hulpforums van Google formuleren, inclusief de versies die om twee uur 's nachts zijn getypt. Een item kiezen geeft je de meest waardevolle controle voor dat symptoom, in plaats van een lijst met alles wat theoretisch mis kan zijn.

Wat het bewijs draagt, en wat niet

De faalpatronen hieronder komen uit discussies in de Google Play Developer Help Community door heel 2026, met cases uit Brazilië, India, Oezbekistan en verschillende Portugeestalige discussies, plus oudere meldingen op Reddit en Stack Overflow. Ze zijn gegroepeerd naar de sterkte van het bewijs, want dat bepaalt wat je ermee moet doen.

De checklist voor de deadline

Vijf toestanden bepalen of 30 september een datum in je agenda wordt of een probleem in je inbox. Vier gelden voor elke Play-ontwikkelaar. De vijfde geldt alleen als je account onder de regel van de gesloten test valt, en dat is ook degene die echte kalendertijd kost.

De vier punten die je afhandelt

Vink ze eerlijk aan en niet optimistisch. Elke regel linkt terug naar de sectie die hem oplost, dus een leeg vakje is een omweg van twee minuten en geen doodlopende weg. Twee ervan zijn voorwaardelijk en daarom zo geformuleerd dat je ze kunt afvinken als ze nooit op jou sloegen: wie al zijn apps automatisch geregistreerd zag, heeft geen handmatige claim af te ronden, en wie al geverifieerd was zonder enige vraag over documenten heeft niets te corrigeren.

Waar PrimeTestLab wel en niet in past

Eerst de grens helder: niemand kan jouw identiteit voor je verifiëren. Je documenten uploaden, je betaalprofiel gelijktrekken en je packagenamen claimen kan alleen de accounthouder zelf, en dit artikel is onze volledige bijdrage aan dat deel. Wat wij wel doen is de eis die voor een nieuw persoonlijk account meteen na verificatie komt: 12 echte testers die 14 aaneengesloten dagen aangemeld zijn.

Dat is de splitsing die steeds in dezelfde vorm in onze inbox landt. Een ontwikkelaar haalt de identiteitsverificatie, ziet groen in Play Console, gaat ervan uit dat de weg vrij is, en ontdekt daarna dat productietoegang een compleet andere poort is met een ondergrens van twee weken eraan vast. Verificatie is papierwerk, en hoe lang het duurt hangt af van je documenten en je account. De gesloten test is kalendertijd die je niet kunt inkorten.

De gesloten test zelf draaien of uitbesteden

De volgorde die de minste tijd kost

Heb je zowel verificatie als de gesloten test nog voor je, doe ze dan naast elkaar en niet achter elkaar. De 14 dagen doorlopende aanmelding zijn echte kalendertijd die pas begint als je daadwerkelijk 12 mensen hebt ingeschreven, dus dat punt bepaalt je werkelijke lanceerdatum. Start die teller terwijl je de documenten regelt, niet erna.

Veelgestelde vragen

Kort samengevat

Beleid laatst gecontroleerd: 13 augustus 2026. De uitrol van Google rond 30 september en de uitbreiding in 2027 zijn nog in beweging, dus controleer data en landendekking opnieuw op de pagina van Google over Android-ontwikkelaarsverificatie voordat je erop handelt. Dit artikel staat gepland voor hercontrole op 30 september 2026 en direct nadat de handhaving begint, en opnieuw telkens wanneer Google een regio of datum voor 2027 publiceert.