Je app moet 16 KB-geheugenpagina's ondersteunen: zo los je het op

De waarschuwing is kort, noemt hooguit een bestandsnaam, en komt binnen op het moment dat je de build al af waande. Daarom herhalen zich steeds dezelfde drie verkeerde afslagen: ontwikkelaars vertrouwen op een deadline die verschoven is, upgraden een framework en gaan ervan uit dat het klaar is, of controleren één lokale APK en kijken nooit naar de bundle waar Google daadwerkelijk vanaf bouwt. Dit artikel volgt de volgorde waarin het probleem echt oplost, namelijk herkennen, herleiden, repareren en bewijzen, en alles erin is actueel per 5 augustus 2026, gecontroleerd tegen de paginagroottegids van Google op dezelfde dag dat die pagina voor het laatst is bijgewerkt. Waar het bewijs alleen uit de issue tracker van een beheerder komt en niet uit officiële releasenotes, zegt de kaart dat erbij in plaats van het af te ronden tot een feit.

Los het op in drie stappen

De vereiste zelf is smal. De paginagroottegids van Google zegt dat apps met Android 15 (API-niveau 35) of hoger als doel geheugenpagina's van 16 KB moeten ondersteunen op 64-bits apparaten, en dat je vanaf 1 februari 2027 geen updates meer kunt uitbrengen die dat niet doen. Het geldt alleen voor native code. Zijn jouw app en elke library en SDK erin puur Java of Kotlin, dan stelt Google dat je app al 16 KB-apparaten ondersteunt. Het probleem is dat de meeste ontwikkelaars die deze waarschuwing zien denken dat ze in die categorie vallen, en dat niet doen.

De hele beslissing op één scherm

Loop dit door voordat je één versienummer van een dependency aanraakt. Het kost ongeveer twee minuten en het is het verschil tussen het juiste ding repareren en elf pakketten upgraden die nooit het probleem waren.

Wat de waarschuwing in Play Console echt betekent

De formulering doet ertoe, want de paniekversie van dit verhaal reist sneller dan de accurate. Lees de teksten die Google werkelijk toont, en het bereik wordt smal en behapbaar.

Twee lezingen van die kaart gaan vaak mis. Ten eerste is "Action by Feb 1, 2027" geen aftelling naar verwijdering; de eigen tekst van Google op dezelfde pagina omschrijft de uitkomst als het niet kunnen uitbrengen van die updates. Ten tweede staat Extension granted wel in de schermafbeelding van Google, maar dat bewijst niet dat er voor jou op dit moment een aanvraagprocedure voor uitstel openstaat. Beschouw uitstel pas als echt wanneer je de optie in je eigen Play Console ziet staan.

Welke deadline had jij eigenlijk gelezen?

Er gaan drie data rond en er geldt er maar één. Kies degene die jij zag en dit bepaalt de status ervan tegenover de huidige Google-pagina, die op 5 augustus 2026 voor het laatst is bijgewerkt.

Raakt de 16 KB-vereiste mijn app?

Apps in puur Java of Kotlin

Google is hier ondubbelzinnig: gebruiken jouw app en al zijn libraries en SDK's alleen Java of Kotlin, dan ondersteunt je app al 16 KB-apparaten. Google raadt nog steeds aan om in een 16 KB-omgeving te testen op onverwachte regressies, en dat kost je één emulatorsessie.

De adder zit in de zinsnede "en al zijn libraries en SDK's". Eén dependency voor een database, analytics, crashrapportage, media, kaarten, machinaal leren of beveiliging kan native binaries toevoegen aan een project waarvan de eigen broncode niets dan Kotlin bevat. "Ik heb geen C++ geschreven" is geen bewijs. De map lib wel.

Flutter, React Native, Unity, Kivy en app builders zonder code

Deze stacks leveren native runtimes, enginebinaries en plug-inlibraries mee als onderdeel van hun ontwerp, dus vallen ze bijna altijd binnen het bereik. Google noemt uitdrukkelijk app builders van derden die native libraries gebruiken als manier waarop een app geraakt kan worden, ook als de maker nooit C of C++ geschreven heeft. Wat verschilt is niet of je native code hebt maar welk pakket het falende onderdeel leverde, en daarom komt de bestandsnaam herleiden vóór welke upgrade dan ook.

Hoe je het precies controleert

Open de release-APK, klap lib open, en bekijk de ABI-mappen erin, normaal gesproken arm64-v8a en x86_64. Zijn er shared object-bestanden aanwezig, dan gebruikt je app native code. Geen .so-bestanden en geen map lib betekent dat deze APK helemaal geen native code gebruikt. De kolom Alignment in de analyzer toont waarschuwingen bij de bestanden met uitlijningsproblemen, en dat is de snelste weg van "er is iets mis" naar een bestandsnaam.

Waarom een 4 KB-binary faalt op een 16 KB-apparaat

Dat is de hele mechaniek, en het verklaart het ene getal dat je steeds zult tegenkomen. Uitlijning wordt uitgedrukt als een macht van twee: 2**12 is 4096 bytes, 2**14 is 16384 bytes. De regel van Google is dat elk LOAD-segment in een native library uitgelijnd moet zijn op 2**14 of hoger. Een library die op 2**14 is gebouwd werkt op apparaten met 4 KB én met 16 KB, want 16384 is een net veelvoud van 4096. Een library die op 2**12 is gebouwd werkt alleen op de kleinere paginagrootte. Die asymmetrie is de reden dat de oplossing altijd "verhoog de uitlijning" is en nooit "detecteer het apparaat".

Er is een tweede, volledig losstaande beperking die buiten de library leeft. Ongecomprimeerde native libraries die in een APK zijn opgeslagen moeten óók op een grens van 16 KB liggen binnen het ZIP-archief zelf. Dat is een eigenschap van de verpakking, wordt gecontroleerd met zipalign en ingesteld door je buildplug-in, en die kan fout zijn terwijl elke library erin perfect is uitgelijnd. Die twee begrippen uit elkaar houden is het nuttigste dat je uit deze sectie kunt meenemen.

De kortste oplossing per framework

Alle ondergrenzen in één tabel

De betrouwbaarheidslabels betekenen overal op deze pagina hetzelfde. GEVERIFIEERD betekent dat een actuele primaire bron het rechtstreeks stelt. GEDEELTELIJK betekent dat een betrouwbare bron de kern van de bewering ondersteunt maar niet elk implementatiedetail. GEMELD betekent dat het bewijs uit de issue tracker van een beheerder of uit meldingen van ontwikkelaars komt en niet uit officiële releasenotes.

Vind precies de library die de fout veroorzaakt

Begin in APK Analyzer

Open Build > Analyze APK..., laad de release-APK, en klap lib open. Daarin zie je één map per ABI, normaal gesproken arm64-v8a en x86_64. De kolom Alignment toont waarschuwingen bij bestanden met uitlijningsproblemen. Ook de eigen waarschuwingen van Android Studio en Lint lichten native libraries uit die niet voldoen, dus je kunt dezelfde bevinding op meer dan één plek tegenkomen.

Noteer elke gemarkeerde bestandsnaam voordat je één versienummer aanraakt. Controleer beide ABI-mappen apart: het is volstrekt normaal dat arm64-v8a slaagt terwijl x86_64 zakt, of andersom, want het zijn verschillende binaries die door mogelijk verschillende pijplijnen zijn gebouwd.

Lees de uitvoer van de opdrachtregel uit

Werk je liever in een terminal, dan levert Google check_elf_alignment.sh, dat ALIGNED of UNALIGNED meldt voor een APK, en kun je één library rechtstreeks inspecteren met llvm-objdump. Beide vragen Android SDK Build-Tools 35.0.0 of hoger. Plak hieronder wat ze afdrukken en dit leest het voor je terug.

Zoek uit welke dependency hem bezit

Play Console en APK Analyzer geven je allebei een bestandsnaam en geen eigenaar. Typ hem hieronder in en dit vertelt je wat er over die binary bekend is, met de kwaliteit van het bewijs erbij, en geeft je de zoekopdrachten met jouw bestandsnaam er al in.

Controleer de app bundle, niet alleen de lokale APK

Dit is de mechaniek achter de meest frustrerende versie van het probleem: de ontwikkelaar upgradet alles, inspecteert de lokale APK, ziet schone uitvoer, uploadt, en de waarschuwing staat er nog steeds. Niets van wat hij controleerde was fout. Hij heeft alleen nooit gecontroleerd wat Play beoordeelt.

Draai dit dus elke keer op de bundle die je op het punt staat te uploaden:

bundletool dump config --bundle=app-release.aab | grep alignment

PAGE_ALIGNMENT_16K is het resultaat dat je wilt. PAGE_ALIGNMENT_4K betekent dat de bundle bundletool opdraagt native libraries op grenzen van 4 KB te verpakken, dus elke APK die Play daaruit bouwt zal fout zijn. Google waarschuwt er specifiek voor dat Android Gradle Plugin 8.3 tot en met 8.5 precies dit verschil kan opleveren: de lokale build ziet er uitgelijnd uit, terwijl de app die Play uit de bundle bouwt niet correct installeert op een 16 KB-apparaat. De aanbevolen oplossing is overstappen op Android Gradle Plugin 8.5.1 of hoger.

Elke opdracht, met je eigen bestandsnamen erin

Typ je bestandsnamen één keer in. Elke opdracht hieronder herschrijft zichzelf, en elk tabblad toont de exacte uitvoer die als geslaagd telt, zodat je nooit hoeft te raden of een resultaat goed was.

AGP, NDK en de verpakkingsvalkuil

Het gevaarlijke middenveld is Android Gradle Plugin 8.3 tot en met 8.5. In dat bereik kan een lokale build er volstrekt correct uitzien terwijl bundletool de APK's die het uit jouw bundle voor Play produceert niet ZIP-uitlijnt, en de formulering van Google over de uitkomst is bot: de app die uit die bundle wordt gebouwd installeert niet correct. Zit je op 8.5.0 en doorstaat je lokale APK elke controle die je maar kunt bedenken, dan is dit het eerste dat je moet uitsluiten.

Overzicht van buildinstellingen

Het deel dat verpakking niet kan repareren

Gaat je eigen C- of C++-code uit van een paginagrootte, dan redt geen enkele buildvlag je. Haal vastgeschreven 4096-waarden weg en elk vertrouwen op een vaste PAGE_SIZE-constante, vraag de echte waarde op tijdens het draaien met getpagesize() of sysconf(_SC_PAGESIZE), en loop elke mmap()-aanroep na samen met elk argument dat je met de hand op een pagina uitlijnt. Dit is de foutklasse waarbij een app netjes installeert op een 16 KB-apparaat, de bundlecontroles doorstaat, en dan crasht zodra hij voor het eerst memory mapping aanraakt.

Test in een echte 16 KB-omgeving

Je hebt drie praktische routes en twee specialistische. Kies wat je vandaag echt kunt bereiken; voor het opsporen van paginagroottefouten zit er geen kwaliteitsverschil tussen.

adb shell getconf PAGE_SIZE

Wat je echt moet uitproberen

Zodra de omgeving bevestigd is, is de nuttige testronde niet "start hij op". Native fouten clusteren in de functies die native code raken, dus draai die bewust: koude start, navigeren door de app, camera, lezen en schrijven in de database, media afspelen en opnemen, inloggen, achtergrondwerk, elke functie met machinaal leren of augmented reality, elk oppervlak van een native plug-in, en alles in je eigen code dat memory mapping gebruikt. Draait een functie op een van de libraries die je zojuist hebt geüpgraded, dan is die functie de test.

Waarom de waarschuwing een upgrade overleeft

Twee daarvan verdienen een voorbehoud in plaats van een stellig antwoord. Geen enkele primaire bron legt vast hoe lang Google Play erover doet om een geüploade bundle opnieuw te beoordelen, dus blijft je waarschuwing meteen na een upload staan, dan is de eerlijke zet om te bevestigen dat de nieuwe versiecode bij je recentste releases en app bundles verschijnt en het later opnieuw te controleren, in plaats van te vertrouwen op een concreet getal over verwerkingstijden dat je ergens hebt gelezen. En een app die alleen draait omdat de compatibiliteitsmodus ingreep is niet gerepareerd, die wordt getolereerd.

Libraries van derden die steeds terugkomen

Gebruik dit als startpunt zodra een bestandsnaam je bekend voorkomt, en controleer het daarna tegen de actuele releases en open issues van dat project. Waar het bewijs uit de issue tracker van een beheerder komt en niet uit releasenotes, zegt de kaart dat erbij.

Hoe dit samenhangt met de API 36-deadline van 31 augustus 2026

Google Play verplicht nieuwe apps en app-updates om vanaf 31 augustus 2026 Android 16 (API-niveau 36) als doel te hebben, met uitstel dat aanvraagbaar is tot 1 november 2026. Dat is een wijziging in je manifest en in het gedrag van je app. De 16 KB-regel is een wijziging in binaire compatibiliteit. Wie op maandag targetSdk verhoogt en op dinsdag een 16 KB-waarschuwing ziet, heeft niets kapotgemaakt: de native libraries waren al gebouwd voor pagina's van 4 KB, en het hogere doelniveau bracht de app alleen maar binnen het bereik van een controle die er hoe dan ook zou komen.

In de praktijk behandel je ze als één migratie met twee bewijzen. Dat doelniveau ga je toch verhogen, dus plan de audit van je native libraries in dezelfde release in plaats van er middenin de haast rond API 36 achter te komen. Voor de volledige lijst met niveaus per apparaattype, de uitzonderingen en hoe het uitstel werkt, lees je ons artikel over de API 36-deadline van Google Play, en voor de hele route van account tot productie ons artikel over de publicatievereisten van 2026.

De releasecheck voor het uploaden

Je voortgang wordt alleen in deze browser bewaard. Er gaat niets ergens naartoe, en je browsergegevens wissen wist ook dit.

Waar dit botst met je gesloten test

De volgorde die pijn doet gaat zo. Een persoonlijk ontwikkelaarsaccount start een gesloten test, de periode van 14 dagen doorlopend aangemeld begint te lopen, en ergens halverwege legt een verhoging van het doelniveau een 16 KB-waarschuwing bloot. Nu bouwt de ontwikkelaar native dependencies opnieuw terwijl een testgroep daar omheen intact moet blijven. Een nieuwe build naar de testtrack uploaden is prima, en Google moedigt ontwikkelaars juist aan om tijdens een test te blijven updaten. Wat de run breekt is dat het aan de testerkant stil wordt.

Precies dat deel houdt PrimeTestLab stabiel. Wij leveren 12 echte testers op echte apparaten van Android 7 tot en met 17, aangemeld en vastgehouden voor de volle 14 dagen, zodat jouw herbouw plaatsvindt tegen een stabiele test en niet tegen een instortende. Testen start binnen 4-6 uur, en we hebben dit inmiddels voor ruim 7.400 apps in 120+ landen gedaan met een slagingspercentage van 99,9%.

Zelf testers werven tegenover een begeleide run

Voor de duidelijkheid over de grens: wij bouwen jouw native libraries niet opnieuw en dit artikel is daar ook geen verkooppraatje voor. Het 16 KB-werk is van jou, en alles boven deze sectie is geschreven om dat werk zo kort mogelijk te maken. Wat wij van je bord halen is de testervereiste die er tegelijk naast loopt, zodat de twee problemen niet langer om dezelfde twee weken vechten.

Veelgestelde vragen

Kort samengevat