Kort antwoord
Een afwijzing wegens Broken Functionality betekent dat de beoordelaar van Google vond dat de release die je indiende crashte, geforceerd werd afgesloten, vastliep of op een andere manier abnormaal werkte; Googles eigen voorbeelden zijn apps die niet installeren, apps die installeren maar niet laden, en apps die laden maar niet reageren. Het is een beleidsbesluit over een release, geen weigering van productietoegang, en volgens Google heeft een afwijzing op zich geen invloed op de status van je ontwikkelaarsaccount. Reproduceer het probleem op de build die Play distribueert, controleer of beoordelaars kunnen inloggen via Inloggegevens (voorheen App-toegang), herstel elke getroffen track en verzend daarna de gecorrigeerde release ter beoordeling. Maak alleen bezwaar als je kunt aantonen dat de bevinding onjuist was.
Actueel op 16 oktober 2026. Elke regel op deze pagina is op die datum gecontroleerd aan de hand van de beleidspagina's van Google Play en de Play Console Help, en bij elke regel staat de bron waar hij wordt gebruikt. De ontwikkelaarsmeldingen hieronder laten zien wat ontwikkelaars in 2026 zagen, ze zijn geen diagnose van Google van hun apps, en er staat geen ranglijst van oorzaken in omdat geen enkele openbare dataset die onderbouwt.
Dit artikel gaat over afwijzingen van een release onder het beleid Broken Functionality. Heeft Google na je gesloten test geen productietoegang verleend, of kreeg je te horen dat er meer tests nodig zijn, dan is dat een ander besluit met een andere oplossing: lees dan wat je doet als Google Play zegt dat er meer tests vereist zijn en waarom aanvragen na een gesloten test worden afgewezen.
Wat dit artikel behandelt
Wat betekent Broken Functionality op Google Play?
Het is een van de twee onderdelen van Googles beleid Functionality, Content, and User Experience. Het andere onderdeel, Limited Functionality and Content, gaat over apps met te weinig doel. Broken Functionality gaat over een app die niet werkt zoals hij is ingediend.
We staan geen apps toe die crashen, geforceerd worden afgesloten, vastlopen of op een andere manier abnormaal werken.
Google noemt onder die zin drie voorbeelden van veelvoorkomende schendingen: apps die niet installeren, apps die installeren maar niet laden, en apps die laden maar niet reageren. Lees ze als drie plekken om te zoeken. Een beoordelaar die de build niet kan installeren, die een leeg of eindeloos ladend scherm ziet, of die op een knop tikt en er gebeurt niets, kan allemaal tot dezelfde melding leiden.
In oudere Help-links en forumdiscussies kom je misschien nog de naam Minimum Functionality tegen. Het huidige beleidsonderdeel heet Limited Functionality and Content en gaat over apps met alleen statische tekst of pdf's, apps met heel weinig content en apps die ontworpen zijn om niets te doen. Een melding kan naar elk van beide onderdelen verwijzen en de oplossingen verschillen, dus lees welk onderdeel je melding noemt voordat je iets verandert.
Vier besluiten die met elkaar worden verward
| Besluit | Waar het over gaat | Waar je begint |
|---|---|---|
| Broken Functionality | Waar het over gaatDe ingediende release crashte, liep vast, laadde niet of reageerde niet bij de beoordelaar. | Waar je begintReproduceer het op de build die Play distribueert, herstel het op elke getroffen track en dien opnieuw in. |
| Limited Functionality and Content | Waar het over gaatDe app draait, maar biedt te weinig eigen doel of content. | Waar je begintVoeg echte functionaliteit toe. Alleen een bugfix is hier geen antwoord op. |
| Inloggegevens ontbreken of werken niet | Waar het over gaatBeoordelaars kwamen niet voorbij een login, lidmaatschap, betaalmuur, eenmalige code of regiocontrole. | Waar je begintWerk Inloggegevens bij in App-content en verzend de wijziging daarna ter beoordeling. |
| Productietoegang niet verleend | Waar het over gaatNa de gesloten test besloot Google dat de app meer tests nodig heeft of nog niet klaar is voor productie. | Waar je begintEen apart proces zonder melding op codeniveau. Zie meer tests vereist. |
Waar laat Google zien wat er kapot was?
Begin bij de handhavingsmail en de pagina Beleidsstatus in Play Console. Samen noemen ze het beleid en de betreffende release, en volgens Google toont Beleidsstatus ook alle aanvullende informatie die beschikbaar is. Screenshots, apparaatgegevens en stacktraces worden niet beloofd, dus wacht er niet op.
Open Play Console, selecteer de app en open de pagina Beleidsstatus. Noteer vier dingen voordat je de code aanraakt: het genoemde beleidsonderdeel, de versiecode en track die zijn beoordeeld, de datum en eventueel bijgevoegd bewijs. Bekijk ook de e-mail en je meldingen in Play Console, want daar vermeldt Google welk beleid de release heeft geschonden.
Hoe meldingen er in 2026 echt uitzien
Er bestaat geen standaard e-mail over Broken Functionality die iedereen krijgt, en elke pagina die er een afdrukt als het exacte sjabloon, gokt. Ontwikkelaars die hun meldingen in 2026 openbaar plaatsten, beschrijven heel verschillende niveaus van detail:
- Een meldingslabel met de tekst "Broken Functionality: Unresponsive UI elements", geplaatst op 2 september 2026 door een ontwikkelaar van wie de app tijdens de eerste gegevenssynchronisatie een offline scherm met een knop om het opnieuw te proberen toonde (Play Console Help Community).
- Een voorbeeld van een beoordelaar met de tekst "For example, your app does not open or load.", in juni 2026 geciteerd door een game-ontwikkelaar van wie het titelscherm wel degelijk laadde. De auteur meldde later dat de game werd gepubliceerd nadat hij had aangepast hoe de Android-terugknop de game afsloot.
- Een melding die een ontwikkelaar in augustus 2026 omschreef als slechts twee woorden, "Broken functionality", zonder verdere uitleg.
Dit zijn fragmenten die ontwikkelaars zelf hebben overgenomen, geen geverifieerde e-mails van Google, en elk fragment is één enkel geval. Ze laten zien hoeveel detail je kunt krijgen, niet wat er in jouw melding staat of waarom jouw app faalde.
Als je melding vaag is
Behandel het genoemde beleid als een symptoom om te reproduceren, niet als een diagnose. De vijf controles in het volgende onderdeel staan zo op volgorde dat elke controle een andere plek uitsluit waar de fout zich kan verstoppen.
Wat controleer je eerst na een afwijzing wegens Broken Functionality?
Doe vijf controles op precies de release die Google beoordeelde. Ze staan op volgorde van het goedkoopst naar het moeilijkst uit te sluiten, niet op hoe vaak elke oorzaak voorkomt, want geen enkele openbare data laat zien hoe vaak elke oorzaak voorkomt.
Vijf controles, op volgorde
Installeer de build die Play distribueert, niet je debugbuild
Installeer vanuit je testtrack op een schoon apparaat dat is ingelogd met een Google-account dat de app nog nooit heeft gebruikt, en open de app zoals een beoordelaar dat zou doen. Google Play ondertekent de builds die het distribueert met je app-ondertekeningssleutel (Play App Signing gebruiken), dus elke dienst die een certificaatvingerafdruk controleert, zoals Google Sign-In, Maps of een API-sleutel die beperkt is op pakketnaam en SHA-1, kan in je debugbuild werken en in de Play-build falen. Eén ontwikkelaar herleidde in 2025 een fout die alleen in de release optrad tot een internetpermissie die ontbrak in het productiemanifest.
Controleer of de beoordelaar binnenkomt
Zit een deel van de app achter een login, lidmaatschap, locatie of andere afscherming, dan eist Google dat je de toegangsgegevens opgeeft. Controleer of Inloggegevens (voorheen App-toegang) gegevens bevat die vandaag werken, vanuit elk land, zonder eenmalige code. Het volgende onderdeel loopt het stap voor stap door.
Test de backend van buiten je eigen netwerk
Inlogschermen en gegevensschermen falen als de server niet bereikbaar is vanaf het netwerk van de beoordelaar. Ontwikkelaars herleidden in 2026 fouten tot een per ongeluk ingestelde firewallregel die een aanvraag voor een inlogcode blokkeerde, en meldden een certificaatvertrouwensfout op een inlogscherm. Test via mobiele data en een ander netwerk, en vanuit een ander land als je server verkeer op regio filtert.
Tik op elke zichtbare knop en open elk leeg scherm
Elke knop en link moet reageren met passende content. Googles eigen checklist voor Broken Functionality in de Play Console Help Community zegt: "Zorg dat je app geen lege of blanco pagina's heeft zonder passende disclaimers of foutmeldingen." Verwijder onafgemaakte functies in plaats van een knop te leveren die niets doet, en controleer of elke functie die je Store-vermelding belooft ook echt werkt in de build. Geef een terecht lege lijst, zoals nog geen opgeslagen items, een zin die het uitlegt en een volgende actie. Is je navigatie ongebruikelijk, zoals overal tikken om verder te gaan, voeg dan een zichtbare aanwijzing toe die een nieuwe gebruiker niet kan missen.
Controleer het opstarten, de terugknop en de rapporten die Play al heeft
Start de app koud op, draai het scherm, stuur de app naar de achtergrond en haal hem terug, en druk op elk scherm op Terug. Lees daarna het pre-launchrapport en Android vitals voor de beoordeelde versie. Een crash die daar is vastgelegd, is het sterkste bewijs dat je krijgt, en een schoon rapport heeft grenzen die het onderdeel na het volgende uitlegt.
Hoe geef je de beoordelaars van Google inloggegevens?
Ga in Play Console naar Beleid en programma's, dan App-content, dan Inloggegevens (Sign-in details). Dit onderdeel heette vroeger App-toegang (App access), dus oudere artikelen en sommige vertaalde Help-pagina's gebruiken die naam nog.
Als je hele app of delen van je app zijn beperkt op basis van inloggegevens, lidmaatschappen, locatie of andere vormen van verificatie, moet je alle vereiste gegevens opgeven om toegang tot je app mogelijk te maken.
De instructies toevoegen of bijwerken
- Open Play Console en ga naar de pagina App-content (Beleid en programma's > App-content).
- Kies onder Inloggegevens de optie Starten, of Beheren als je al eerder instructies hebt toegevoegd.
- Kies + Nieuwe instructies toevoegen en vul de toegangsgegevens in. Gebruik het veld Andere instructies voor alles wat ongebruikelijk is, zoals een eenmalig wachtwoord, meervoudige verificatie of een login met meer dan twee velden.
- Sla je wijzigingen op. Je kunt maximaal vijf sets instructies toevoegen.
- Ga naar Publicatieoverzicht, zoek de wijziging onder Wijzigingen klaar om te verzenden voor beoordeling en kies Verzenden voor beoordeling. Alleen opslaan dient niets in.
Wat telt als werkende toegang
De Play Console-vereisten van Google vragen je om "een actief demo-account, inloggegevens en alle andere middelen op te geven die Google Play nodig heeft om je app te beoordelen". De vereisten voor inloggegevens van Google leggen uit wat dat betekent:
- Een account dat actief en herbruikbaar is, geen uitnodiging voor eenmalig gebruik of een proefperiode die tijdens de beoordeling verloopt.
- Gegevens die langs eenmalige codes en verificatie in twee stappen komen, want de beoordelaar kan de code die je naar een telefoon of inbox stuurt niet ontvangen.
- Toegang die vanaf elke locatie werkt als de app op regio beperkt, en volledige toegang tot betaalde of afgeschermde functies die de beoordelaar moet zien, zonder dat er kosten in rekening worden gebracht.
- Gegevens die in het Engels zijn geschreven en actueel worden gehouden. Wijzig je het wachtwoord of verwijder je het testaccount, werk Inloggegevens dan nog dezelfde dag bij.
- Heeft het inloggen iets nodig dat geen tekst is, zoals een QR-code of barcode, maak er dan een statische URL voor en voeg die toe aan Inloggegevens. Vraagt de app gebruikers om zelf een pincode in te stellen of gebruikt hij een social login, leg dan in de instructies uit hoe een beoordelaar erdoor komt.
Ontbrekende toegang is niet hetzelfde als een kapotte login
Verwijst de melding naar Inloggegevens, dan helpt geen enkele codewijziging totdat de toegangsgegevens zijn gecorrigeerd en ter beoordeling zijn verzonden. Klopten de gegevens en faalde de login zelf, dan is dat een probleem van Broken Functionality, en is de backendcontrole hierboven de plek om te zoeken.
Wat als de app op je telefoon werkt en Google geen screenshot stuurde?
Dan is je telefoon niet de omgeving die faalde. Reproduceer op de Play-build, op een schoon apparaat en een ander netwerk, en lees de twee rapporten die Play Console al voor die release heeft voordat je iets besluit.
Het pre-launchrapport
Je vindt het onder Test and release > Testing > Pre-launch report. Google maakt het automatisch aan als je een app-bundle of APK uploadt, afhankelijk van de capaciteit, door de app op testapparaten te draaien. Controleer welke schermen de crawl echt heeft bereikt: stopte hij bij je inlogscherm, dan heeft hij de rest van de app nooit gezien. Google noemt een grens die goed is om te weten: "Inloggegevens kunnen alleen automatisch worden ingevoerd in Android-apps die standaard Android-widgets gebruiken." (Een pre-launchrapport gebruiken om problemen te vinden). Een schoon rapport is bewijs, geen goedkeuring. Google zegt hetzelfde over zijn controles vóór de beoordeling: "Als je alle controles vóór de beoordeling doorstaat, is dat geen garantie dat je het formele beoordelingsproces van de app doorstaat".
Android vitals
Je vindt het onder Monitor and improve > Android vitals > Crashes and ANRs. Google verzamelt deze gegevens alleen van gebruikers die ervoor hebben gekozen gebruiks- en diagnostische gegevens te delen (Technische kwaliteit bewaken met Android vitals), dus een nieuwe app in een kleine test laat misschien helemaal niets zien. Een lege vitals-pagina bewijst niet dat de app nooit is gecrasht.
Echte mensen op echte apparaten
Een gesloten test is er om dit soort problemen te vinden vóór een openbare release. Testers op verschillende telefoons, Android-versies en netwerken bereiken de schermen die een beoordelaar bereikt, en hun feedback vertelt je waar het misgaat. Dat helpt je defecten te vinden en te herstellen; het verandert niets aan hoe Google de app beoordeelt. Wil je de basis van de track zelf kennen, lees dan hoe de gesloten test van Google Play werkt.
Moet je herstellen en opnieuw indienen, of bezwaar maken?
Herstel en dien opnieuw in als je een fout kunt reproduceren of een aannemelijke oorzaak vindt. Maak bezwaar als je bewijs hebt dat de genoemde bevinding onjuist is. Dien nooit dezelfde build ongewijzigd opnieuw in: Google zegt tegen ontwikkelaars dat ze een afgewezen app pas opnieuw publiceren nadat de schending is verholpen.
Herstellen, verduidelijken of bezwaar maken?
Beantwoord drie vragen over je melding en je eigen tests. Niets wat je kiest verlaat deze pagina.
Beantwoord de vragen om een advies te zien. Kun je geen fout reproduceren, dan beslist de derde vraag.
Herstel het en dien daarna opnieuw in op elke track
Herstellen en opnieuw indienenJe hebt een reproduceerbare fout, en dat is de beste positie om in te zitten. Herstel hem, test de oplossing op de Play-build en volg daarna de stappen voor opnieuw indienen hieronder, zodat er op geen enkele track een niet-conforme bundle actief blijft.
Test de Play-build voordat je beslist
Eerst testenEen debugbuild is niet wat de beoordelaar heeft gedraaid. Installeer vanuit je testtrack op een schoon apparaat met een nieuw account, via een netwerk dat je niet zelf beheert, en doe de vijf controles. Beslis pas daarna.
Corrigeer Inloggegevens en verzend ter beoordeling
Toegang herstellenWerk de instructies bij met herbruikbare gegevens die eenmalige codes omzeilen, sla op en verzend de wijziging daarna ter beoordeling vanuit het Publicatieoverzicht. Volgens Google kan dat zonder contact op te nemen met het ondersteuningsteam voor beleid of daarop te wachten.
Voeg een doel toe, niet alleen fixes
HerwerkenLimited Functionality and Content gaat over hoeveel de app doet. Voeg echte, eigen functies of content toe voordat je opnieuw indient; een stabiliteitsfix is geen antwoord op deze bevinding.
Maak het ontwerp duidelijk en beslis dan
VerduidelijkenIs een offline scherm, een lege staat of een ongebruikelijk gebaar bewust zo gemaakt, dan kan een beoordelaar het toch als kapot zien. Voeg een zichtbare aanwijzing, een uitleg en een volgende actie toe. Je kunt bezwaar maken met bewijs, maar een duidelijker scherm neemt de twijfel ook weg voor de volgende beoordelaar.
Maak bezwaar met bewijs
BezwaarJe hebt de Play-build getest op een schoon apparaat en een ander netwerk en niets gevonden. Maak één keer bezwaar, met de versiecode, het apparaat en de Android-versie, de exacte stappen en een schermopname van de flow die de melding noemt.
Een herstelde release opnieuw indienen
De stappen voor opnieuw indienen van Google zijn meer dan het uploaden van een nieuwe versiecode:
- Lees het beleid dat in de e-mail en je meldingen wordt genoemd, en controleer de app ook aan de hand van het andere beleid; Google waarschuwt dat verdere schendingen tot verdere handhaving kunnen leiden.
- Werk elk releasetype bij dat de betreffende versie bevat, niet alleen productie: ook de open, gesloten en interne testtracks.
- Upload de gecorrigeerde app-bundle en deactiveer de niet-conforme bundles. Google waarschuwt dat het opnieuw indienen mislukt als je ze niet deactiveert, en dat live versies kunnen worden verwijderd.
- Kies in elke getroffen track Track beheren en Nieuwe release maken, voeg de gecorrigeerde bundle toe (of verwijder een concept dat de schendende bundle bevat), en zorg dat de niet-conforme versie onder Niet opgenomen staat.
- Sla op, kies Release beoordelen en rol hem uit.
Daarna wacht de wijziging op verwerking. Google zegt: "De verwerking kan een paar uur of maximaal zeven dagen duren (of in uitzonderlijke gevallen langer)" (Bepalen wanneer app-wijzigingen worden beoordeeld en gepubliceerd).
Hersteld, maar de waarschuwing staat er nog
Staat er een gecorrigeerde versie live en toont Beleidsstatus het probleem nog steeds, vergelijk dan de versiecodes en tracks die de waarschuwing noemt met wat nu actief is: een niet-conforme bundle die op een testtrack is blijven staan, is het eerste wat je uitsluit. Een nieuwere versie wist niet automatisch elke handhavingsregistratie. Klopt alles, neem dan contact op met de ondersteuning van Play Console en geef de versiecodes, de getroffen tracks en eventuele eerdere zaaknummers door.
Bezwaar maken tegen het besluit
Google zet apps terug als het een fout heeft gemaakt en vaststelt dat de app het beleid niet schendt. Om bezwaar te maken volg je de instructies in de handhavingsmail of gebruik je het bezwaarformulier van Google. Je kunt één bezwaar indienen per handhavingsmaatregel (Beleidsschendingen en bezwaren beheren), en Google beantwoordt bezwaren in het Chinees, Engels, Japans en Koreaans. Google publiceert geen reactietermijn voor bezwaren, en ontwikkelaarsmeldingen halen antwoorden op bezwaren en latere beoordelingen van releases door elkaar, dus plan zonder datum.
Schrijf het bezwaar als bewijs, niet als frustratie: de versiecode die is beoordeeld, het apparaat en de Android-versie waarop je hebt getest, de exacte stappen, een schermopname van de flow die de melding noemt, en wat je eventueel hebt veranderd.
Schaadt een afwijzing wegens Broken Functionality je account of je gesloten test?
Een afwijzing op zich heeft geen invloed op de status van je ontwikkelaarsaccount. Herhaalde afwijzingen kunnen tot opschorting leiden, en opschortingen tellen als strikes, dus herstel voordat je opnieuw indient. Wat een afwijzing doet met een lopende gesloten test, is niet gedocumenteerd.
De pagina Handhavingsproces van Google zet het verschil uiteen:
- "Afwijzingen hebben geen invloed op de status van je Google Play-ontwikkelaarsaccount."
- "Als een update voor een bestaande app wordt afgewezen, blijft de versie van de app die vóór de update is gepubliceerd beschikbaar op Google Play."
- "Opschorting kan het gevolg zijn van ernstige of meerdere beleidsschendingen, en van herhaalde afwijzingen of verwijderingen van apps."
Google publiceert geen aantal afwijzingen dat veilig is. Dezelfde fout opnieuw indienen is precies het patroon dat de derde regel beschrijft.
En de gesloten test van 14 dagen?
De testvereiste van Google vraagt van persoonlijke accounts die na 13 november 2023 zijn gemaakt minimaal 12 testers die minimaal 14 dagen doorlopend aangemeld zijn voordat ze productietoegang aanvragen. Er staat niet in of een beleidsafwijzing van een release op de gesloten track die periode opnieuw laat beginnen, pauzeert of laat staan, en uitspraken op forums in welke richting dan ook zijn gissingen. Wat je wel kunt controleren: of je testers nog een goedgekeurde release op de track hebben, en wat het dashboard laat zien over productietoegang. Houd testers aangemeld terwijl je herstelt, en vraag de ondersteuning van Play Console naar je situatie als het dashboard verandert. De regel zelf wordt uitgelegd in wat 14 achtereenvolgende dagen betekent.
Wijst Google een WebView- of TWA-app af als kapot?
Niet om de technologie. Google documenteert zowel Trusted Web Activities als WebView voor Android-apps, en geen enkel beleid verbiedt die architectuur. De vragen zijn of de app werkt, of hij genoeg doel heeft en of je het recht hebt om de website in te pakken.
We staan geen apps toe waarvan het hoofddoel is affiliateverkeer naar een website te leiden of een webview van een website te bieden zonder toestemming van de eigenaar of beheerder van die website.
Voor een webgebaseerde app zijn de controles voor Broken Functionality dezelfde als voor elke andere app: de site moet na een schone installatie in de app laden, offline- en foutstatussen moeten zichzelf uitleggen en elke link moet ergens naartoe leiden. Is de app grotendeels een dunne weergave van een website, dan is het onderdeel Limited Functionality and Content het grotere risico. Overstappen van een TWA naar een WebView, of andersom, lost een afwijzing op zich niet aantoonbaar op.
Hoe helpt PrimeTestLab voor de volgende beoordeling?
We kunnen je code niet herstellen en het besluit van Google niet veranderen. Wat wij leveren is de testkant: echte mensen op echte apparaten die je app via je gesloten test gebruiken, zodat problemen zoals die hierboven in hun feedback opduiken voordat een beoordelaar ze vindt.
PrimeTestLab levert 12 of meer echte testers op echte apparaten van Android 7 tot en met 17, de volle 14 dagen aangemeld, en het testen begint binnen 4-6 uur. We hebben begeleide tests uitgevoerd voor 12.100+ apps met testers in 120+ landen.
Zelf testen of begeleid testen
| Taak | Zelf doen | Met PrimeTestLab |
|---|---|---|
| Testers vinden | Zelf doenVrienden, groepen en forums, meestal op vergelijkbare telefoons | Met PrimeTestLabEchte testers op echte apparaten, toegewezen aan je app |
| Spreiding van apparaten en Android-versies | Zelf doenWat je vrijwilligers toevallig hebben | Met PrimeTestLabApparaten van Android 7 tot en met 17 |
| Dagelijks gebruik en feedback | Zelf doenAfhankelijk van goodwill | Met PrimeTestLabTesters gebruiken de app en melden wat er misgaat |
| 12 testers 14 dagen aangemeld houden | Zelf doenJe jaagt zelf achter afhakers aan | Met PrimeTestLabAfhakers worden vervangen, zodat het aantal blijft staan |
| De code en de melding oplossen | Zelf doenJij | Met PrimeTestLabNog steeds jij; wij rapporteren wat testers vonden |
| Het besluit van Google | Zelf doenGoogle | Met PrimeTestLabNog steeds Google; niemand kan goedkeuring beloven |
Heeft Google na je volledige test met PrimeTestLab geen productietoegang verleend, dan kies je een gratis hertest of een volledige terugbetaling; zie het beleid voor terugbetaling en gratis hertest. Dat geldt voor de testvereiste, niet voor een beleidsafwijzing van je code. Pakketten beginnen bij $19.99 plus 5% servicekosten bij het afrekenen (minimaal $1.50), en de eenmalige registratiekosten van $ 25 bij Google staan daar los van. Vergelijk de pakketten op de prijspagina.
Veelgestelde vragen
Wat is het beleid Broken Functionality op Google Play?
Het is een onderdeel van het beleid Functionality, Content, and User Experience van Google Play. Google staat geen apps toe die crashen, geforceerd worden afgesloten, vastlopen of op een andere manier abnormaal werken, en noemt apps die niet installeren, apps die installeren maar niet laden, en apps die laden maar niet reageren als veelvoorkomende schendingen.
Is Broken Functionality hetzelfde als Minimum Functionality?
Nee. Minimum Functionality is de oudere naam voor wat Google nu Limited Functionality and Content noemt, en dat gaat over apps met te weinig doel of content. Broken Functionality gaat over apps die niet werken zoals ze zijn ingediend. Beide staan in hetzelfde beleid, maar ze vragen om verschillende oplossingen.
Waar voeg ik demogegevens toe voor de beoordeling door Google Play?
Ga in Play Console naar Beleid en programma's, dan App-content, dan Inloggegevens (voorheen App-toegang). Kies Starten of Beheren, voeg de instructies toe en sla op, en verzend de wijziging daarna ter beoordeling vanaf de pagina Publicatieoverzicht. De gegevens moeten herbruikbaar zijn en mogen niet afhangen van een eenmalige code die naar je telefoon wordt gestuurd.
Telt een afwijzing als een strike op mijn ontwikkelaarsaccount?
Volgens Google hebben afwijzingen geen invloed op de status van je ontwikkelaarsaccount. Opschortingen tellen als strikes, en Google noemt herhaalde afwijzingen of verwijderingen van apps als redenen voor opschorting, dus herstel het genoemde probleem voordat je opnieuw indient.
Hoelang duurt de beoordeling nadat ik een herstelde app opnieuw heb ingediend?
Volgens Google kan het verwerken van app-wijzigingen een paar uur of maximaal zeven dagen duren, of in uitzonderlijke gevallen langer. Dat is de beoordeling van de gecorrigeerde release. Google publiceert geen reactietermijn voor bezwaren.
Kan ik bezwaar maken tegen een afwijzing wegens Broken Functionality?
Ja, als je denkt dat de bevinding onjuist is. Volg de instructies in de handhavingsmail of gebruik het bezwaarformulier van Google. Je kunt één bezwaar indienen per handhavingsmaatregel, dus vermeld de beoordeelde versiecode, het apparaat en de stappen die je hebt getest, en een opname van de flow die de melding noemt.
Begint mijn gesloten test van 14 dagen opnieuw na een afwijzing wegens Broken Functionality?
Google documenteert dat niet. De vereiste is minimaal 12 testers die minimaal 14 dagen doorlopend aangemeld zijn voordat je productietoegang aanvraagt. Houd testers aangemeld terwijl je de release herstelt, houd het dashboard in de gaten en vraag de ondersteuning van Play Console om hulp als je geschiktheid verandert.
Waarom is mijn app afgewezen als hij op mijn telefoon werkt?
Je telefoon dekt één build, één account, één set gegevens en één netwerk. Installeer de release die Play distribueert op een schoon apparaat met een nieuw account, en test daarna lege content en mislukte netwerkverzoeken. Een Play-build die met de app-ondertekeningssleutel is ondertekend, kan falen waar je debugbuild werkt, dus test de build die de beoordelaar heeft geïnstalleerd.
Mijn app gebruikt Google Sign-In of een eenmalige code. Wat geef ik beoordelaars?
Google eist inloggegevens die herbruikbaar zijn, vanaf elke locatie werken en eenmalige wachtwoorden of verificatie in twee stappen omzeilen. Geef beoordelaars een testaccount en instructies die elke beperkte functie bereiken, ook betaalde functies. Test daarna zelf precies de gegevens die je hebt opgegeven; uitleggen hoe een gewone gebruiker een code ontvangt, is geen werkende toegang.
Google stuurde geen screenshot of crashlog. Wat nu?
Bekijk Beleidsstatus en de handhavingsmail voor de betreffende versie en eventuele details die Google heeft toegevoegd. Reproduceer daarna de belangrijkste route door de app op de ingediende release en neem zelf video en logs op. Een schone pagina in Android vitals of een schoon pre-launchrapport bewijst niet dat elk scherm en elk backendverzoek voor de beoordelaar werkte.
Worden TWA- en WebView-apps automatisch afgewezen?
Nee. Google documenteert beide technologieën en geen enkel beleid verbiedt ze. Google beperkt wel apps die een website inpakken zonder toestemming van de eigenaar, en apps met te weinig functionaliteit of content. Stel de werkelijke fout vast, zoals fouten bij inloggen, navigatie of het netwerk; overstappen van de ene wrapper naar de andere is geen gedocumenteerde oplossing.
Kort samengevat
Samengevat
Een afwijzing wegens Broken Functionality zegt dat de release die Google beoordeelde niet werkte: hij crashte, liep vast, laadde niet of reageerde niet. Lees naar welk beleid de melding verwijst, reproduceer op de build die Play distribueert, controleer of beoordelaars kunnen inloggen via Inloggegevens, test de backend van buiten je netwerk en zorg dat elke knop en elk leeg scherm zichzelf uitlegt. Herstel elke getroffen track en verzend de gecorrigeerde release ter beoordeling. Maak alleen bezwaar met bewijs dat de bevinding onjuist was. Een afwijzing alleen is geen strike, maar herhaald opnieuw indienen zonder herstel kan er wel tot een leiden.
Wil je dat echte mensen op echte apparaten het kapotte scherm vinden voordat de volgende beoordelaar dat doet, dan verzorgt PrimeTestLab de kant van de gesloten test terwijl jij de app herstelt.
Officiële documentatie van Google
Wat er op deze pagina kan veranderen
- Labels in Play Console verschuiven. Inloggegevens heette tot voor kort App-toegang, en sommige vertaalde Help-pagina's gebruiken de oude naam nog.
- De tekst van meldingen wordt niet als sjabloon gepubliceerd en verschilt per geval; vertrouw op je eigen e-mail en pagina Beleidsstatus boven elk voorbeeld hier.
- Google documenteert niet wat een beleidsafwijzing doet met een lopende gesloten test. Publiceert Google een regel, dan volgt deze pagina die.
Bronnen gecontroleerd op 16 oktober 2026.