Deadline doel-API 36 van Google Play: wat er verandert op 31 augustus 2026

Google verhoogt de ondergrens voor het doel-API-niveau van de Play Store één keer per jaar, en 2026 is de cyclus van API 36. Het getal is niet het verwarrende deel. Het verwarrende deel is dat "de eis voor het doel-API-niveau" eigenlijk twee regels onder één naam zijn: de ene bepaalt wat je mag uploaden, en een andere, lagere bepaalt wie iets wat al gepubliceerd is nog kan installeren. Bijna elke pagina die op deze vraag scoort haalt de twee door elkaar, en zo komt het dat ontwikkelaars een app herbouwen die dat niet nodig had, of een waarschuwing in Play Console wegwuiven die er wél toe deed.

Dit artikel haalt ze uit elkaar, geeft je de getallen per apparaatsoort, en beantwoordt dan de vraag die onze supportinbox in augustus werkelijk krijgt: wat doet dit met een app die halverwege een gesloten test (closed testing) met 12 testers en 14 aaneengesloten dagen zit? PrimeTestLab draait die testkant voor ontwikkelaars, dus we zien die botsing in de planning voortdurend, en het advies in die sectie geldt of je nu een dienst gebruikt of zelf testers werft. Elke datum en elk niveau hieronder is op 9 augustus 2026 gecontroleerd tegen de pagina's van Google zelf, en alles wat Google niet echt gedocumenteerd heeft is als zodanig gemarkeerd in plaats van ingevuld met een zelfverzekerde gok.

De regel in één zin

Vanaf 31 augustus 2026 moet een gewone app voor telefoon, tablet, vouwbaar toestel of Android Auto zich richten op Android 16, API-niveau 36 of hoger om bij Google Play ingediend te kunnen worden, of het nu een gloednieuwe app is of een update van een gepubliceerde. Die ene zin dekt de meeste lezers. De uitzonderingen, en de aparte lagere ondergrens voor apps waar je niets aan doet, zijn waar de rest van dit artikel over gaat.

Eén naam, twee verschillende regels

Google gebruikt de term "eis voor het doel-API-niveau" voor twee dingen die zich totaal niet hetzelfde gedragen. Ze uit elkaar houden is het waardevolste wat je met deze pagina kunt doen.

Een app die rustig op API 35 blijft zonder geplande updates voldoet dus op 31 augustus aan regel 2, en voldoet niet meer op het moment dat je iets probeert uit te brengen onder regel 1. Dat is geen tegenspraak maar het ontwerp: Google legt de lat voor wat de store binnenkomt sneller hoger dan de lat voor wat erin blijft.

De drie begrippen die Google precies definieert

Het beleid steunt op drie termen, en elk daarvan heeft een specifieke betekenis die bepaalt onder welke regel je valt:

• Nieuwe app: een app die "nog niet gepubliceerd is op Google Play". De eerste upload van een packagenaam.
• Bestaande app: een app die al op Google Play gepubliceerd is.
• App-update: een nieuwe versie van een bestaande app die ter beoordeling wordt ingediend om de huidige te vervangen. Een update wordt beoordeeld volgens de inzendregel, niet volgens de beschikbaarheidsregel.

Eisen per apparaatsoort

"Android-app" is niet één rij. Telefoons, tablets, vouwbare toestellen en Android Auto gaan naar API 36. Wear OS en Android Automotive OS stoppen bij API 35. Android TV en Android XR stoppen bij API 34. De ondergrenzen voor een app die je niet bijwerkt liggen nog lager, en de schakelaar hieronder wisselt tussen beide sets.

Android Auto is niet Android Automotive OS

Deze twee namen kosten ontwikkelaars elk jaar echt tijd. Android Auto projecteert een app vanaf een telefoon op het scherm van de auto, dus de app is een telefoon-app en volgt de telefoonregel: API 36. Android Automotive OS is het besturingssysteem dat op het voertuig zelf draait, en dat is een van de genoemde uitzonderingen met een lager doelniveau: API 35. Bouw je een media- of navigatie-app die naar beide gaat, dan heb je de hoogste van de twee nodig.

Geldt het voor jou? Beantwoord drie vragen

Of 31 augustus jouw probleem is hangt van drie dingen af: wat je op het punt staat te doen, welke apparaatsoort je uitbrengt, en waar je huidige build werkelijk op richt. De tool hieronder legt de gepubliceerde ondergrenzen van Google op die combinatie en vertelt je onder welke van de twee regels je valt.

Zegt het oordeel dat je in orde bent, dan wil je de checklist voor de deadline aan het eind alsnog, want "mijn broncode zet target 36" en "het artefact dat Google beoordeeld heeft geeft 36 op" zijn niet dezelfde bewering. De meest voorkomende valse veiligheid in deze hele cyclus is een ontwikkelaar die zijn Gradle-bestand leest in plaats van zijn geüploade bundle.

Wat er werkelijk gebeurt als je 31 augustus mist

Twee verschillende dingen, afhankelijk van de regel waar je onder valt. Probeer je een build onder de ondergrens te uploaden, dan voldoet de inzending niet aan de eis. Laat je een gepubliceerde app onder de beschikbaarheidsondergrens simpelweg met rust, dan is hij niet langer vindbaar en installeerbaar voor nieuwe gebruikers op toestellen met een nieuwere Android-versie dan hij target. Geen van beide uitkomsten is verwijdering.

Als je probeert te uploaden

Let op waar dit gevolg aan vastzit: aan de handeling van het uploaden. De kalender alleen doet niets met een build die al live staat. Daarom kan een app op 1 september perfect voldoen en op 2 september geblokkeerd zijn, puur omdat je besloot een bugfix uit te brengen.

Als je een gepubliceerde app onder de ondergrens laat staan

Dit is het scenario dat concurrenten omschrijven als "je app verdwijnt", en dat is fout op een manier die ertoe doet. De formulering van Google is dat de app "stop being discoverable" voor een specifieke groep gebruikers. Concreet:

• Nieuwe gebruikers op nieuwere toestellen verliezen toegang. Draait het toestel van een gebruiker een hogere Android-versie dan het doelniveau van je app, dan toont of installeert Google Play de app niet meer voor hem.
• Nieuwe gebruikers op oudere toestellen merken niets. Een toestel met hetzelfde of een lager API-niveau dan de app target kan hem gewoon nog krijgen.
• Wie hem eerder installeerde merkt niets. Iedereen die de app al geïnstalleerd heeft kan hem nog vinden, opnieuw installeren en gebruiken op ondersteunde Android-versies.
• Deeplinks vertellen de waarheid. Een gebruiker op een niet in aanmerking komend nieuwer toestel die je Play Store-link opent, krijgt te zien dat de app "made for an older version of Android" is.

Wat er niet gebeurt

Elk jaar in augustus levert dit beleid dezelfde vier angsten op in de supportforums van Google. Geen daarvan is wat de pagina over het doel-API-niveau beschrijft.

Sluit richten op API 36 oudere toestellen uit?

Nee, niet uit zichzelf. targetSdk geeft aan voor welk gedragsniveau van Android je app gebouwd en getest is. minSdk bepaalt op welke oudste Android-versie hij geïnstalleerd kan worden. Het zijn losse getallen, en het doelniveau naar 36 tillen verhoogt het minimum niet vanzelf: je app kan oudere Android-versies tot aan dat minimum blijven ondersteunen, zolang je code en eventueel bijgewerkte dependencies compatibel blijven.

Dit is het misverstand dat elke cyclus de meeste onrust veroorzaakt. Een ontwikkelaar leest "moet op Android 16 richten", denkt dat het "draait alleen op Android 16" betekent, en concludeert dat Google zojuist het grootste deel van zijn bereikbare toestellen heeft geschrapt. Sleep het minimum hieronder en kijk wat er werkelijk verandert.

De drie getallen, en welke Google Play controleert

Wat dit betekent als je app nu in een gesloten test zit

Ben je een nieuw persoonlijk ontwikkelaarsaccount dat de verplichte gesloten test met 12 testers en 14 aaneengesloten dagen draait, dan valt de deadline midden in je venster. De veilige zet is om de API 36-build vóór 31 augustus in dezelfde gesloten track te krijgen, elke tester aangemeld te houden, en je nooit door een deadline te laten dwingen tot wisselen van track of het opnieuw beginnen met testers.

De pagina van Google over het doel-API-niveau en de pagina over gesloten tests zijn door verschillende teams voor verschillende doelen geschreven, en geen van beide gaat over de ander. Dat laat een echt gat, en het eerlijke is om je precies te laten zien waar de gedocumenteerde grond ophoudt.

Wat geverifieerd is

• Een nieuw persoonlijk account dat eronder valt "moet een gesloten test uitvoeren" met minimaal 12 testers die de afgelopen 14 dagen doorlopend aangemeld zijn geweest voordat het productietoegang kan aanvragen. Dit geldt voor persoonlijke accounts die na 13 november 2023 zijn aangemaakt. Geverifieerd
• De ontwikkelaarsdocumentatie van Google zegt dat een geüploade APK aan de doel-API-eisen van Play moet voldoen, en publiceert geen uitzondering voor testtracks. Die formulering is trackneutraal, niet testspecifiek, dus plan een nieuwe upload naar een gesloten track na de deadline alsof API 36 nodig is: een sterke gevolgtrekking, geen gedocumenteerde regel voor testtracks. Gedeeltelijk
• Google moedigt ontwikkelaars zelf aan om de app tijdens de gesloten test te blijven bijwerken terwijl ze problemen oplossen, en definieert de kwalificerende periode rond de continuïteit van aangemelde testers, niet rond één bevroren artefact. Geverifieerd
• De interne test is begrensd op 100 testers en vervangt de kwalificerende gesloten test niet. Geverifieerd

Wat Google niet gedocumenteerd heeft

Omdat het antwoord onbekend is, is de juiste strategie niet om het te voorspellen. Ze is om de vraag irrelevant te maken door vóór de datum een build die voldoet in de track te hebben. Dat is veilig onder beide uitkomsten en kost je niets als het oude artefact tóch was blijven draaien.

De volgorde die hoe dan ook veilig is

1. Houd dezelfde gesloten track en dezelfde testersgroep aan

   Maak geen nieuwe track voor de API 36-build en verwijder geen aangemelde testers. De 14 dagen continuïteit die Google telt gaan over testers die aangemeld blijven, dus de aanmelding is het bezit dat je beschermt.

2. Bouw en test API 36 vóór de deadline, niet erop

   Behandel de migratie als een eigen taak met een eigen testronde. Op 30 augustus ontdekken dat je edge-to-edge-layout breekt is een heel andere dag dan het op 10 augustus ontdekken.

3. Upload hem naar de bestaande gesloten track met een hogere versiecode

   Elke vervangende bundle heeft een opgehoogde versiecode nodig. Google definieert de kwalificerende periode rond de continuïteit van aangemelde testers en moedigt ontwikkelaars uitdrukkelijk aan om tijdens het testen problemen te blijven oplossen, maar publiceert geen absolute garantie die elk scenario van buildvervanging dekt. Houd dezelfde track en dezelfde aangemelde testers aan, en controleer daarna de teller in Play Console. De volledige mechanica van bijwerken tijdens een test is het lezen waard als dit je eerste cyclus is.

4. Bevestig dat de release de testers werkelijk bereikt heeft

   Een gepubliceerde release is niet hetzelfde als een geleverde. Controleer of de gesloten release live staat, of de versiecode hoger is, en of testers op de aanmeldlijst de update zien.

5. Controleer de beleidsstatus opnieuw na de verwerking

   Geef de bundle tijd om verwerkt te worden en open daarna de beleidsstatuspagina van de app opnieuw. Blijft de waarschuwing over het doel-API-niveau staan, werk dan de triagelijst af in plaats van willekeurig releases te verwijderen.

6. Vraag de verlenging alleen aan als de migratie er echt niet op tijd komt

   Ze koopt je tijd tot 1 november 2026 en wordt per getroffen app aangevraagd. Het is geen reden om het technische werk stil te leggen.

Zo vraag je de verlenging tot 1 november 2026 aan

Getroffen ontwikkelaars kunnen een verlenging aanvragen die de distributie tot 1 november 2026 laat doorlopen. Je vraagt hem per app aan, vanuit de beleidswaarschuwing van die app in Play Console. Google beschrijft hem niet als automatisch, gegarandeerd of als een permanente vrijstelling, dus blijf migreren zolang de aanvraag loopt.

Google Play Console · echte schermafbeelding Klik om te vergroten

1. Open de betreffende app in Play Console

   Toegang tot de verlenging is appspecifiek, niet accountbreed. Publiceer je meerdere apps, reken er dan op dat je dit voor elke getroffen app herhaalt.

   Geverifieerd
2. Ga naar Beleidsstatus

   Alleen apps die Google als niet-voldoend beschouwt horen de melding over het doel-API-niveau te dragen. Voldoet de app al, dan valt er hier niets te verlengen en vind je geen formulier.

   Geverifieerd
3. Open de waarschuwing of de meldingsdetails over het doel-API-niveau

   De titel van de melding in de schermafbeelding hierboven is App must target Android 16 (API level 36) or higher. De formulering kan per app en per uitrolstatus verschillen, dus behandel dat als wat één echt account zag en niet als een gegarandeerde universele tekst.

   Geverifieerd
4. Volg de verlengingslink in de melding, of in Meldingen

   Google leidt sommige getroffen ontwikkelaars via de appmelding in plaats van via het meldingspaneel. Controleer beide voordat je concludeert dat de optie voor jou niet bestaat.

   Geverifieerd
5. Stuur de gevraagde informatie in

   Google publiceert de exacte vragen niet op zijn openbare helppagina, dus behandel elke lijst met "de vragen die ze stellen" als ongeverifieerd. Antwoord vanuit je echte migratieplan.

   Gedeeltelijk
6. Behandel 1 november 2026 als de harde grens

   De verlenging verschuift de datum, ze schaft de eis niet af. Wat je op 31 augustus niet af kreeg, moet op 1 november af zijn.

   Geverifieerd
7. Blijf migreren zolang de aanvraag loopt

   Niets in de formulering van Google belooft goedkeuring. Plannen rond een toegekende verlenging die je nog niet hebt is de duurste aanname die deze cyclus te bieden heeft.

   Gedeeltelijk

Nog één onderscheid om vast te houden: Google hangt de voetnoot over de verlenging aan de eis van API 36, en zijn proza beschrijft de verlenging meestal als iets wat de distributie van een bestaande app in stand houdt. Het loopt niet met dezelfde precisie elke combinatie van nieuwe app, update en bestaande app af. Voordat je aanneemt dat een verlenging een bepaalde geplande upload dekt, lees wat de waarschuwing van je eigen app zegt te dekken.

Zo breng je een app naar API 36

Vier stappen: installeer de SDK van API 36, zet compileSdk en targetSdk op 36, werk de dependencies bij die daardoor breken, en test de gedragswijzigingen van Android 16. Het getal veranderen is een aanpassing van één regel. Aantonen dat de app nog werkt is de eigenlijke migratie.

Stap 1: installeer de Android 16-SDK

Open Android Studio, ga naar de SDK Manager en installeer het Android SDK-platform voor API-niveau 36 samen met de huidige 36.x.x build tools. Zonder dat platform levert het verhogen van compileSdk alleen een buildfout op die nergens naar lijkt te verwijzen.

Stap 2: verhoog de niveaus in je build

Kies je stack. Het bestandspad en de exacte regels verschillen, de bestemming niet: het manifest in je geüploade bundle moet target 36 opgeven.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Stap 3: werk dependencies en frameworktooling bij

Het compileniveau verhogen is waar oude dependencies stukgaan. Reken erop dat je de Android Gradle Plugin, Gradle zelf, Kotlin, AndroidX-libraries, Google Play services en elke advertentie- of analytics-SDK met native code aanraakt. Dit artikel publiceert bewust niet "de juiste versies", want compatibele versies verschuiven wekelijks en een vaste lijst hier zou binnen veertien dagen misleidend zijn. Haal ze op de dag van je migratie uit de actuele release notes van je eigen framework.

Stap 4: bouwen, uploaden en het artefact controleren

• Genereer een ondertekende Android App Bundle en hoog de versiecode op.
• Test het release-artefact, niet alleen een debugbuild. Minificatie en het opschonen van resources breken dingen die een debugbuild verbergt.
• Upload naar de bedoelde track en controleer in Play Console dat het artefact doel-API-niveau 36 rapporteert.
• Loop na de verwerking elke actieve track na en open de beleidsstatus opnieuw.

Gedrag van Android 16 om te testen voordat je API 36 uitbrengt

Richten op API 36 zet het gedrag van Android 16 aan voor je app op Android 16-toestellen. Het gedrag met hoge prioriteit om te testen is edge-to-edge-layout, voorspellend terugnavigeren, vrije oriëntatie op grote schermen, gezondheidsrechten, uitvoering op vast interval en tekstopmaak. Vink hieronder aan wat van toepassing is en je krijgt de testlijst voor jouw app in plaats van een algemene.

Edge-to-edge en voorspellend terugnavigeren: de grootste impact

Edge-to-edge heeft een grote impact omdat het geen enkele exotische API van je app vraagt. Op Android 16 kan een app die op API 36 richt het vorige opt-outattribuut niet meer gebruiken, dus content die ervan uitging dat de systeembalken ruimte zouden laten loopt nu onder die balken door. Het symptoom is cosmetisch, tot precies het moment dat een primaire knop onder de gesturebalk komt en niet meer aantikbaar is.

Voorspellend terugnavigeren heeft een even grote impact. Registreert je app verouderde afhandeling van terugnavigatie, dan kan dat pad simpelweg niet meer afgaan zoals voorheen zodra voorspellend terugnavigeren standaard aanstaat bij target 36. Test terugnavigatie vanaf elke navigatiediepte die je hebt: modals, WebViews, formulieren met niet-opgeslagen invoer, en het laatste scherm vóór afsluiten.

Wat geen universele breuk bij target 36 is

En de eis rond de paginagrootte van 16 KB?

Andere eis, andere datum, dezelfde apps. De doel-API-deadline gaat over het niveau dat je manifest opgeeft. De eis rond de paginagrootte van 16 KB gaat erover of je native libraries werken op toestellen met geheugenpagina's van 16 KB. De huidige richtlijn van Google noemt 1 februari 2027 als de datum waarop betrokken app-updates zonder ondersteuning voor 16 KB niet meer uitgebracht kunnen worden.

• Voor wie het geldt: de eis van Google geldt voor apps die op API 35 of hoger richten op 64-bits Google Play-toestellen. Binnen die groep zijn apps die native .so-libraries meeleveren, rechtstreeks of via een SDK, degene die het vaakst expliciet opnieuw gebouwd en uitgelijnd moeten worden. Is je app alleen Kotlin of Java, dan is hij doorgaans al compatibel, maar testen blijft beter dan aannemen.
• Wat het niet is: het maakt geen deel uit van de doel-API-deadline van 31 augustus 2026, en de een halen betekent niet dat je de ander haalt.
• Waarom het samenvalt: iedereen die deze maand zijn doelniveau verhoogt is toch al aan het herbouwen, en juist dan komt de controle op de paginagrootte boven. Die timing is waarom de twee door elkaar gehaald worden.

Levert je app native libraries mee, behandel de controle op de paginagrootte dan als een eigen taak met een eigen testronde in plaats van iets wat je op het laatste moment in de API 36-build vouwt. De twee wijzigingen raken verschillende delen van de build, en ze tegelijk debuggen is hoe een migratie van een week er drie wordt.

Je hebt API 36 geüpload en de waarschuwing staat er nog

Meestal is het een van drie dingen: de bundle is nog niet klaar met verwerken en de Beleidsstatus is niet ververst, een ouder artefact staat nog op een andere actieve track, of het artefact dat je uploadde geeft in werkelijkheid geen 36 op terwijl je project dat wel doet. Werk de lijst van boven naar beneden af, en begin niet met het verwijderen van releases.

De meldingstitel die ontwikkelaars nu rapporteren is Your app must target Android 16 (API level 36) or higher. Google publiceert geen canonieke volledige foutmelding voor elke uploadstroom, dus behandel exacte formuleringen die je online vindt, ook deze, als waargenomen en niet als officieel.

Eén gewoonte lost het meeste hiervan blijvend op: lees na elke upload het doel-API-niveau terug van het artefact in Play Console en schrijf het naast de versiecode op. Het kost tien seconden en het haalt de hele categorie "ik weet zeker dat ik dit gefixt heb" uit je week.

De checklist voor de deadline

Veertien punten, in de volgorde waarin ze echt gebeuren. De laatste vier zijn degene die mensen overslaan, en juist die bepalen of de waarschuwing verdwijnt.

Waar PrimeTestLab in deze deadline past

Even duidelijk over de grens: wij migreren je code niet. targetSdk verhogen, dependencies bijwerken en gedragswijzigingen van Android 16 repareren is jouw build, en dit artikel is onze volledige bijdrage daaraan. Wat we wél afdekken is de andere helft van de botsing: de 12 echte testers, 14 aaneengesloten dagen aangemeld die een nieuw persoonlijk account nodig heeft voordat het überhaupt productie kan bereiken.

De timing is het probleem. Iemand die in augustus 2026 voor het eerst publiceert wordt gevraagd twee losstaande moeilijke dingen in hetzelfde venster te doen: een API 36-build uitbrengen, en twee weken achtereen een kwalificerende gesloten test bij elkaar houden. De build is een oplosbare technische klus. Twaalf echte mensen werven die veertien dagen aangemeld blijven, op echte apparaten, is het deel dat stilletjes een maand opslokt.

De gesloten test zelf doen versus hem uitbesteden

De volgorde voor deze maand

Heb je beide problemen tegelijk, voer ze dan parallel uit in plaats van na elkaar. Begin nu met de gesloten test, want de 14 dagen daarvan zijn echte kalendertijd die je niet kunt indikken, en doe de migratie naar API 36 ernaast. Duw de build die voldoet in dezelfde gesloten track zodra hij klaar is, met een hogere versiecode en dezelfde testers nog aangemeld. Zo houden de deadline en het testvenster op om dezelfde twee weken te vechten.

Veelgestelde vragen

Kort samengevat

Momentopname van het beleid, geverifieerd op 9 augustus 2026. Google werkt deze pagina's zonder aankondiging bij, dus controleer de primaire bronnen hierboven voordat je op een datum handelt. Dit artikel staat gepland voor herverificatie direct na 31 augustus en opnieuw na 1 november 2026.