Kunnen je testers je APK nog installeren na de verificatie van Android-ontwikkelaars?

Het verhaal dat zich in 2025 verspreidde was simpel: Android stopt met rechtstreeks installeren. Het standpunt dat Google in augustus 2026 daadwerkelijk documenteert is smaller, preciezer en veel minder bruikbaar als kop. Google heeft de reikwijdte van de eerste handhavingsfase in juni en juli 2026 verduidelijkt en aangescherpt en schreef die beperking op 15 juli 2026 in één zin op: de deadline van 30 september "geldt alleen voor de specifieke deelnemende stores". Een groot deel van de berichtgeving uit 2025 en begin 2026 die nog circuleert, is gepubliceerd voordat die zin bestond en beschrijft een bredere eerste uitrol dan Google daadwerkelijk doorvoert.

Daarom is dit artikel opgebouwd rond de beslissing die je echt moet nemen, en niet rond de ophef. Je hebt twaalf vrienden, collega's of testers en een build die op hun telefoon moet. Mag je de APK nog mailen? Heb je ADB nodig? Werkt Firebase App Distribution? En de vraag die vrijwel elke week bij PrimeTestLab binnenkomt: telt iets daarvan mee voor de gesloten test met 12 testers die Google vóór productietoegang eist? Elke datum, elk cijfer en elk mechanisme hieronder is op 13 augustus 2026 gecontroleerd op de pagina's van Google, en waar Google niets heeft gepubliceerd benoemt dit artikel het gat in plaats van het te vullen.

Kunnen testers je APK na 30 september 2026 nog installeren?

Ja. Onder de huidige regels van Google kan een tester na 30 september 2026 nog steeds een APK installeren die je hem rechtstreeks stuurt. De datum is echt, de vier landen zijn echt en de handhaving is echt, maar de huidige FAQ van Google zegt dat de deadline "alleen geldt voor de specifieke deelnemende stores". Voor rechtstreeks installeren zegt diezelfde FAQ dat die "nog niet voor je app geldt".

Wat 30 september wel en niet raakt

Drie regels beslechten de vraag voor bijna elke lezer. De middelste regel is degene die afwijkt van veel eerdere berichtgeving over deze datum.

Het bereik komt uit de FAQ over verificatie van Android-ontwikkelaars (update van 10 augustus 2026) en de aankondiging van 18 juni 2026 met de datum, de vier landen en de zeven stores. De testvereiste van Play komt uit antwoord 14151465 van de Play Console-helpsectie. Alles geraadpleegd op 13 augustus 2026.

Wat er op 30 september 2026 echt verandert

Google prikte de datum op 18 juni 2026 en versmalde die vervolgens schriftelijk op 15 juli. Vanaf 30 september wordt een installatie via een van zeven genoemde stores in vier genoemde landen gecontroleerd: de app moet op een geverifieerde ontwikkelaar geregistreerd zijn. De huidige FAQ van Google zegt dat die eerste fase geldt voor de genoemde deelnemende stores, en dat rechtstreeks installeren en niet-deelnemende stores nog niet gedekt zijn.

Dit zijn twee losse verplichtingen op 30 september, en ze door elkaar halen is de meest voorkomende misvatting over deze datum. Packageregistratie in Play is wereldwijd en bepaalt of je vermelding online blijft; handhaving bij installatie is regionaal en bepaalt wat er op de telefoon van een gebruiker gebeurt. Geverifieerd

De zeven deelnemende stores

Noem ze precies bij naam. Dit een beperking voor alle appstores noemen is te breed volgens de huidige formulering van Google over de eerste fase: op basis van de lijst die Google heeft gepubliceerd valt een store die hier niet genoemd wordt buiten de uitrol van 30 september.

De storelijst en de landen komen uit de aankondiging van Google van 18 juni 2026; het uitsluiten van rechtstreeks installeren en niet-deelnemende stores komt uit de verificatie-FAQ van Google zoals bijgewerkt op 10 augustus 2026. Geraadpleegd op 13 augustus 2026. Geverifieerd

De vier landen en de apparaattypen daarbinnen

Twee details versmallen dit nog verder en zijn het onthouden waard. Voor distributie buiten Google Play stelt de verificatie-FAQ van Google dat de handhaving in de geselecteerde regio's in eerste instantie geldt voor telefoons en tablets. Diezelfde FAQ zegt dat de bescherming wordt geleverd via Google Play services op gecertificeerde Android-apparaten met Android 7 of hoger, wat het uiteindelijke apparaatbereik is en geen beperking die alleen in september geldt.

Wat er in september niet verandert

De lijst hieronder is kort, maar dekt hoe de meeste kleine teams een build daadwerkelijk verplaatsen. Niets ervan wordt geraakt door de fase van 30 september.

Wat er gebeurt als de verificatie in 2027 wereldwijd wordt

Google zegt dat de vereiste in 2027 en verder wereldwijd wordt uitgebreid, naar apps op gecertificeerde Android-apparaten met Android 7 of hoger, geleverd via Google Play services. Google heeft geen exacte wereldwijde datum en geen planning per land aangekondigd. Behandel elke specifieke datum in 2027 als onofficieel zolang Google die niet publiceert.

De tijdlijn, met wat elke datum met een gedeelde APK doet

1. 30 maart 2026

   De verificatie wordt uitgerold naar alle ontwikkelaars

   Google begon de verificatie van Android-ontwikkelaars uit te rollen naar elke ontwikkelaar in Play Console en de Android Developer Console.

   Kale APK Alleen door deze datum verandert er niets zichtbaars aan het installeren. Niet-geverifieerde app Blijft installeerbaar volgens het bestaande gedrag van Android.
2. Augustus 2026

   Geavanceerde flow en limited-distribution-accounts gaan wereldwijd

   Google plande de wereldwijde lancering van de geavanceerde installatieflow en van limited-distribution-accounts voor deze maand. Op 13 augustus 2026 noemen de geraadpleegde bronnen de maand maar geen exacte dag, en tonen ze niet aan dat de flow al elke gebruiker heeft bereikt. Gedeeltelijk

   Kale APK Blijft beschikbaar. Niet-geverifieerde app De geavanceerde flow is het mechanisme dat het installeren ervan moet behouden.
3. 30 september 2026

   Registratiehandhaving begint in zeven stores, vier landen

   Installaties via Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore en Xiaomi GetApps in Brazilië, Indonesië, Singapore en Thailand vereisen dat de app op een geverifieerde ontwikkelaar geregistreerd is. Geverifieerd

   Kale APK Nog niet gedekt door deze eerste fase. Niet-geverifieerde app Een installatie via een deelnemende store kan beperkt worden; de rechtstreekse route blijft in deze fase onaangeroerd.
4. 2027 en verder

   Wereldwijde uitbreiding naar gecertificeerde Android-apparaten

   De verificatie wordt wereldwijd uitgebreid voor apps op gecertificeerde Android-apparaten met Android 7 of hoger. In deze fase verandert het antwoord over rechtstreeks installeren. Geverifieerd

   Kale APK Geregistreerde app: de gewone installatieroute. Niet-geregistreerde app: geavanceerde flow of ADB volgens het aangekondigde model. Niet-geverifieerde app De geavanceerde flow of ADB blijft de aangekondigde route.
5. Exacte datum in 2027

   Niet aangekondigd op 13 augustus 2026

   De gepubliceerde planning van Google zegt 2027 en verder, en niets preciezers. Er is ook geen volgorde van landen bekendgemaakt. Niet gedocumenteerd

   Kale APK Plan niet op een specifieke dag. Niet-geverifieerde app Plan niet op een specifieke dag.

De chronologie komt uit het uitrolbericht van Google van 30 maart 2026, de aankondiging van 18 juni 2026 en de FAQ over verificatie van Android-ontwikkelaars zoals bijgewerkt op 10 augustus 2026. Geraadpleegd op 13 augustus 2026.

Geverifieerde versus niet-geverifieerde APK: wat Android echt controleert

"Ben ik geverifieerd?" is op zichzelf de verkeerde vraag. De verificatie van Android-ontwikkelaars maakt wat Google een formele, controleerbare koppeling noemt tussen een ontwikkelaarsidentiteit, de packagenaam van een app en de ondertekeningssleutel of sleutels van dat package. Identiteitsverificatie is één schakel in die ketting, niet de hele ketting.

De ketting, schakel voor schakel

De ketting komt uit de gidsen van Google over verificatie van Android-ontwikkelaars, inclusief de beschrijving van het eigendomsbewijs, en de ondersteuning van meerdere ondertekeningssleutels die in de verificatie-FAQ staat. Geraadpleegd op 13 augustus 2026. Geverifieerd

Google is er duidelijk over dat rechtstreeks installeren fundamenteel is voor Android en dat geverifieerde ontwikkelaars rechtstreeks kunnen blijven verspreiden. De nuance die die zin verbergt, is dat een soepele installatie ervan afhangt dat de app geregistreerd is, en niet alleen dat jij een identiteitscontrole hebt doorstaan. Daarom staat er in dit artikel telkens "geregistreerd op een geverifieerde ontwikkelaar" en niet het kortere, lossere "geverifieerde app".

Wat als je een debugsleutel of een aparte QA-ondertekeningssleutel gebruikt?

Hier lopen echte QA-teams tegen de lamp, want het is volstrekt normaal om een met de debugsleutel ondertekende build naar interne testers te sturen en een met de releasesleutel ondertekende build naar de store. Dat zijn verschillende certificaten op dezelfde packagenaam.

Vijf randgevallen waar Google wél antwoord op heeft gegeven

Deze vijf komen steeds terug en hebben alle vijf een gepubliceerd antwoord, dus gissen is niet nodig.

ADB blijft toegestaan, maar het is een ontwikkelaarswerkwijze

De duidelijkste toezegging van Google in dit hele programma, uit de verificatie-FAQ: er verandert niets aan hoe ADB werkt. Ontwikkelaars en gevorderde gebruikers kunnen apps op die manier blijven installeren, en de wachttijd van 24 uur uit de geavanceerde flow geldt niet voor installaties via ADB. Het is de meest duurzame technische route in dit artikel, en tegelijk de minst geschikte voor gewone testers.

Wat een tester eerst moet doen

De documentatie van Google over de tooling is helder over de voorwaarde: om ADB via USB te gebruiken moet je USB-foutopsporing aanzetten in de ontwikkelaarsopties van het apparaat. Op een moderne telefoon betekent dat: het buildnummer opzoeken, er zeven keer op tikken om de ontwikkelaarsopties te ontgrendelen en dan USB-foutopsporing aanzetten in een instellingenscherm met een waarschuwing. Die werkwijze is werkbaar voor een technische tester en belastend voor iemand die zich gewoon aanbood om je app te proberen.

De setup wordt niet bij elke build herhaald, en dat is het detail dat de meeste artikelen missen. Zodra de tester jouw werkstation heeft geautoriseerd, blijft die autorisatie staan tot hij die intrekt of het apparaat vergeet. Een nieuwe build kost dus nog een adb install -r en toegang tot de telefoon, niet nog een gang door de ontwikkelaarsopties. Android 11 en hoger ondersteunen ook draadloos debuggen: de tester koppelt de telefoon één keer aan het werkstation met een QR-code of koppelcode, daarna installeer je via het netwerk zolang beide apparaten erop zitten, zonder kabel. Dat haalt de kabel weg, niet de technische voorwaarde.

adb devices

adb install app-release.apk

adb install -r app-release.apk

Wat is de geavanceerde flow van Android voor niet-geverifieerde apps?

Google heeft een bewuste route gebouwd voor gebruikers die een app van een niet-geverifieerde ontwikkelaar toch willen installeren. Het is een eenmalige instelling met halverwege een drempel: ontwikkelaarsmodus aanzetten, bevestigen dat niemand je erdoorheen praat, opnieuw opstarten, één dag wachten, je identiteit bevestigen en daarna niet-geverifieerde installaties 7 dagen of voor onbepaalde tijd toestaan. De wachttijd van 24 uur hoort bij die instelling en is geen vertraging vóór elke APK.

De volgorde, formulering en duuropties komen uit de FAQ van Google over verificatie van Android-ontwikkelaars, geraadpleegd op 13 augustus 2026. Google publiceert bij elke stap in deze flow een reden, dus de notities hierboven geven die redenering weer in plaats van haar af te leiden. Geverifieerd

Drie dingen die mensen hierover verkeerd begrijpen

Is het nu al beschikbaar?

De praktische lezing voor een ontwikkelaar: de geavanceerde flow is een echt, gedocumenteerd antwoord op "kan een gebruiker mijn niet-geverifieerde app nog installeren?" en een slecht antwoord op "hoe krijg ik deze week een build bij twaalf testers?". Een beveiligingsvertraging van één dag midden in het aanmeldproces levert echte wrijving op voor incidentele of externe testers. Zijn je testers gewone gebruikers, dan worden de routes die hun tijd respecteren vergeleken in sectie 09.

Wat gebeurt er met APK's die al geïnstalleerd zijn?

De documentatie van Google gaat over installeren en bijwerken. Zodra de handhaving geldt, kan een niet-geregistreerde app niet normaal geïnstalleerd of bijgewerkt worden, en Google zegt dat een gewone update "mislukt" zonder de geavanceerde flow of ADB. Wat de bekeken documentatie niet zegt, is dat kopieën die al op de telefoons van mensen staan worden verwijderd of niet meer mogen starten.

Het gedrag komt uit de FAQ van Google over verificatie van Android-ontwikkelaars, geraadpleegd op 13 augustus 2026. De eerste rij vermeldt het ontbreken van een aangekondigd mechanisme, en dat is niet hetzelfde als de belofte dat het gedrag nooit kan veranderen.

Het onderscheid verandert wat je daadwerkelijk moet doen. Een geblokkeerde update is een echt en gedocumenteerd operationeel probleem: een getroffen tester kan op een oudere build blijven hangen omdat de update niet via de gewone route installeert, en hij meldt het misschien nooit, want van zijn kant is er niets gebeurd. Een massale verwijdering zou een compleet ander soort noodgeval zijn en compleet andere communicatie vragen. Slechts één van de twee is gedocumenteerd.

Waar Firebase App Distribution na de verificatie past

Firebase App Distribution is een manier om builds van voor de release op de apparaten van testers te krijgen. Het is geen verificatiesysteem, geen testtrack van Google Play en het geeft geen vrijstelling van de verificatie van Android-ontwikkelaars. Wat het goed doet, is het handwerk weghalen uit het bezorgen van een ondertekende build bij een lijst mensen.

Hoe de APK-flow echt verloopt

De flow, de ondertekeningseis, het bewaren van builds gedurende 150 dagen en het verlopen van uitnodigingen na 30 dagen komen uit de Android-documentatie van Firebase App Distribution, geraadpleegd op 13 augustus 2026. Geverifieerd

Werkt Firebase tijdens de septemberfase nog?

Vrijwel zeker wel, en hoe je tot die conclusie komt doet ertoe. De APK-flow van Firebase is rechtstreekse verspreiding van een ondertekende APK naar uitgenodigde testers. De FAQ van Google zegt dat rechtstreeks installeren niet onder de fase van 30 september valt. Leg die twee feiten naast elkaar en de APK-distributie via Firebase zou tijdens die eerste fase bruikbaar moeten blijven.

APK- en AAB-distributie via Firebase zijn niet hetzelfde

Dit is de nuance die vrijwel elk artikel platslaat. Firebase ondersteunt allebei, en ze leggen een verschillende weg af naar de telefoon van de tester.

"Werkt Firebase nog?" heeft dus twee antwoorden, afhankelijk van welk bestand je uploadt. Wanneer je erover schrijft, of het aan een collega vraagt, benoem dan APK-distributie via Firebase of AAB-distributie via Firebase. De korte vorm verbergt een detail dat de analyse wezenlijk verandert.

Telt Firebase App Distribution mee voor de regel van 12 testers?

Nee. De vereiste van Google voor productietoegang bij accounts die eronder vallen vraagt om minimaal 12 testers die aangemeld zijn voor een gesloten test op Google Play, doorlopend, gedurende de afgelopen 14 dagen. Testers uit Firebase zijn niet aangemeld voor een gesloten test op Play, dus testen via Firebase voldoet er niet aan, hoeveel mensen er ook meedoen en hoe grondig ze ook testen.

De vereiste van Play komt uit antwoord 14151465 van de Play Console-helpsectie; het gedrag van Firebase uit de documentatie van Firebase App Distribution. Beide geraadpleegd op 13 augustus 2026. De twee producten definiëren verschillende processen die het woord "registreren" delen. Geverifieerd

Het patroon dat hierdoor ontstaat verdient een naam, want het kost mensen twee weken. Een ontwikkelaar draait een werkelijk grondige Firebase-test met vijftien betrokken testers, concludeert dat het vinkje voor testen gezet is, opent Play Console om productietoegang aan te vragen, en ontdekt dat de klok van 14 dagen nog niet eens is gaan lopen. Sectie 10 zet de twee vereisten naast elkaar zodat jou dat niet overkomt.

De beste manier om in 2026 een build bij 12 testers te krijgen

Er is geen enkele winnaar, want de routes lossen verschillende problemen op. Een kale APK is het eenvoudigste dat vandaag werkt. ADB is het duurzaamst en het minst bruikbaar. Firebase is het beste pure QA-kanaal. En slechts één route op deze pagina voldoet aan de vereiste van Google Play voor productietoegang, en dat is nu net wat je lanceerdatum bepaalt.

Alle zeven routes naast elkaar

De tool beantwoordt één situatie. Deze tabel beantwoordt ze allemaal, inclusief de twee kolommen die mensen overslaan tot het te laat is: het aangekondigde gedrag in 2027, en of de route iets doet voor je aanvraag van productietoegang bij Play.

Bronnen: de FAQ en de gidsen over verificatie van Google, de documentatie van de ADB-tooling, de documentatie van Firebase App Distribution, de pagina over limited distribution en de Play Console-helpsectie over de interne test en over de testvereisten voor productietoegang. Alles geraadpleegd op 13 augustus 2026.

Het eerlijke advies

Laat twee sporen naast elkaar lopen, want ze beantwoorden verschillende vragen. Gebruik voor echte QA wat een build het snelst op apparaten krijgt: een kale APK voor één collega, Firebase voor een groep, ADB wanneer je alles wilt overslaan. En start daarnaast, zo vroeg mogelijk, de gesloten test op Play als je account onder de vereiste voor productietoegang valt, want die wordt in kalenderdagen gemeten en wordt niet korter door harder te werken.

De fout die je wilt vermijden is ze na elkaar plannen. Een grondige Firebase-test afronden brengt de teller van 14 dagen geen dag verder.

Verificatie van ontwikkelaars vervangt de gesloten test van Google Play niet

Dit zijn twee losstaande vereisten die mensen tot één mentaal vinkje samenvoegen. Verificatie beantwoordt "wie heeft dit package gemaakt en ondertekend?" De gesloten test beantwoordt "heeft dit account de test van Google vóór productie afgerond?" De ene afronden doet helemaal niets voor de andere.

Waarom "een interne test telt ook, het is toch een Play-test" niet klopt

Google staat tot 100 testers toe bij een interne test, waardoor die de serieuzere optie lijkt. Maar de vereiste voor productietoegang is geschreven rond één specifieke track: de meetellende testers moeten de afgelopen 14 dagen doorlopend aangemeld zijn geweest voor een gesloten test. De interne test is een andere track en voldoet dus niet aan die zin.

De cijfers, en waar ze vandaan komen

Twee stukjes geschiedenis maken vragen duidelijk die steeds terugkomen. Google kondigde de vereiste aan op 9 november 2023, en het huidige beleid past hem toe op persoonlijke accounts die na 13 november 2023 zijn gemaakt: twee verschillende data die twee verschillende dingen betekenen. En het minimum was oorspronkelijk 20 mensen gedurende minimaal twee weken; de communitygids van Google zelf zegt dat de verlaging naar 12 in december 2024 plaatsvond. Meldingen van ontwikkelaars uit die tijd leggen de wijziging in Play Console op 11 december 2024, maar er is geen gedateerde aankondiging van Google voor precies die dag te vinden, dus behandel de dag als gemeld en niet als officieel. Gedeeltelijk

Organisatorische accounts vallen buiten deze specifieke horde: de vereiste richt zich op persoonlijke accounts die aan de voorwaarden voldoen. En de kosten zijn in beide gevallen hetzelfde: eenmalige registratiekosten van $ 25 bij Google Play. Wil je de volledige vergelijking van accounttypen in plaats van één alinea, dan staat die in het artikel over persoonlijke versus organisatorische accounts.

Tien beweringen hierover die achterhaald zijn

Een groot deel van de berichtgeving over de verificatie van Android-ontwikkelaars is geschreven voordat Google de eerste fase in juni en juli 2026 versmalde. De beweringen hieronder zijn geen leugens; verschillende klopten toen ze werden gepubliceerd. Ze beschrijven eenvoudigweg een versie van het beleid die niet meer overeenkomt met de huidige pagina's van Google.

Waar twee Google-pagina's elkaar lijken tegen te spreken

Dit is het benoemen waard, want een aandachtige lezer stuit erop. De algemene formulering in de helpsectie van Google zegt dat apps waarvan de ontwikkelaars niet aan de vereiste hebben voldaan niet meer beschikbaar zijn voor nieuwe installaties in de betrokken landen, en dat klinkt breder dan de uitzondering die alleen over stores gaat. De specifiekere FAQ, bijgewerkt op 10 augustus 2026, zegt dat de deadline van 30 september alleen voor de deelnemende stores geldt en nog niet reikt tot rechtstreeks installeren.

Van symptoom naar oplossing: wat er echt misgaat

Zoek de zin die jij of je tester echt heeft gezegd. Een veelvoorkomende oorzaak van een mislukte installatie of update bij een tester is een conflict tussen ondertekeningscertificaten, en dat is gewoon Android-gedrag, heeft niets met verificatie van ontwikkelaars te maken en bestaat al tien jaar langer.

Wat je echt moet doen vóór 30 september

Verspreid je APK's alleen rechtstreeks, dan handhaaft de eerste fase van 30 september de ontwikkelaarsverificatie niet op die route. Dat is tijdelijk, niet blijvend: Google raadt aan de verificatie af te ronden voordat de wereldwijde uitrol in 2027 begint. Publiceer je op Google Play, dan vraagt die datum één ding: elk package geregistreerd. En los van die twee: valt je account onder de horde voor productietoegang, dan is de klok van 14 dagen het item dat je lanceerdatum bepaalt, en die zou dus al moeten lopen.

Wanneer dit artikel veroudert

Dit artikel bederft ongewoon snel en het zou oneerlijk zijn het als tijdloos te presenteren. Hieronder staan de dingen die waarschijnlijk het eerst veranderen, en wat elk ervan onjuist zou maken.

Het herzieningsritme voor dit artikel: wekelijks tot 30 september 2026, daarna op de handhavingsdatum en ongeveer een week later voor verduidelijkingen over de uitvoering, en vervolgens maandelijks tot Google een concrete planning voor 2027 publiceert. Dat ritme is een redactionele keuze op basis van hoe vaak Google dit programma in 2026 heeft herzien, geen officiële planning van Google.

Waar PrimeTestLab wel en niet in beeld komt

Eerst de grens, want dat is het eerlijke deel. PrimeTestLab verifieert je identiteit niet, registreert je packagenamen niet en maakt van een Firebase-test geen gesloten test op Play. Dat deel is aan jou, en dit artikel is onze hele bijdrage daaraan. Wat wij wel doen is de enige vereiste op deze pagina die uit kalendertijd bestaat en niet uit papierwerk: 12 echte testers die 14 dagen doorlopend aangemeld blijven voor een gesloten testtrack op Play. Google publiceert wel API’s en OAuth-delegatie waarmee een geautoriseerd platform een ontwikkelaar kan helpen bij de registratie, maar die toegang moet je zelf verlenen en jij blijft verantwoordelijk voor het account en de identiteit van de app.

Dat onderscheid heeft precies de vorm van het probleem waarvoor dit artikel bestaat. Een ontwikkelaar verspreidt zijn builds prima: nette groepen in Firebase, verzorgde releasenotes, betrokken testers, echte bugmeldingen. Dan opent hij Play Console om productietoegang aan te vragen en ontdekt dat niets daarvan meetelde. Verspreiden is een opgelost probleem. De periode van 14 dagen aangemeld blijven is het deel dat niet korter wordt door je beter te organiseren.

De gesloten test zelf draaien of uitbesteden

Drie pakketten, één betaling

Alle pakketten gebruiken echte testers op echte apparaten gedurende de volle 14 dagen, de test start meestal binnen 4-6 uur, en als een test niets oplevert krijg je een gratis hertest of volledige terugbetaling. We beloven geen goedkeuring van Google, want niemand kan dat.

Veelgestelde vragen

De kern

Laatste beleidscontrole: 13 augustus 2026. De FAQ-pagina van Google over ontwikkelaarsverificatie is voor het laatst bijgewerkt op 10 augustus 2026, het antwoord over direct sideloaden daarop dateert van 15 juli 2026, en de Android-documentatie van Firebase App Distribution is voor het laatst bijgewerkt op 11 augustus 2026. De verificatie van Android-ontwikkelaars wordt nu actief uitgerold, dus controleer het bereik van 30 september, de lijst met deelnemende stores, de beschikbaarheid van de geavanceerde flow en de planning voor 2027 opnieuw op de pagina's van Google voordat je erop handelt. Dit artikel staat gepland voor herverificatie elke week tot 30 september 2026, opnieuw op de handhavingsdatum en ongeveer een week daarna, en daarna maandelijks tot Google een concreet gebied of een concrete datum voor 2027 publiceert.