Google Play stelt vanaf februari 2027 strengere eisen aan geheugengebruik van Android-apps

Google gaat de technische eisen voor Android-apps en -games die via Google Play worden verspreid vanaf februari 2027 aanzienlijk aanscherpen. Ontwikkelaars krijgen dan niet alleen te maken met strengere eisen rond het geheugengebruik van hun software, maar ook met nieuwe minimumvereisten voor de optimalisatie van DEX-code.

Met de nieuwe regels wil Google voorkomen dat apps en games structureel te veel systeemgeheugen gebruiken. Dat is volgens het bedrijf belangrijk omdat Android-apparaten niet onbeperkt steeds meer RAM kunnen krijgen, terwijl apps tegelijkertijd steeds complexer en geheugenintensiever worden. Vooral de combinatie van stijgende geheugenkosten, zwaardere apps en de groei van lokale AI-verwerking zorgt volgens Google voor toenemende druk op het beschikbare geheugen.

De nieuwe eisen worden onderdeel van de technische kwaliteitsbeoordeling van Google Play. Apps en games die structureel slecht presteren op de nieuwe Android Vitals-metrieken kunnen uiteindelijk minder zichtbaar worden op Google Play en te maken krijgen met beperkingen bij het publiceren van nieuwe versies.

Google gaat daadwerkelijk meten hoeveel geheugen apps gebruiken

Een belangrijk onderdeel van de nieuwe regels is dat Google niet alleen naar de theoretische geheugenbehoefte van een app kijkt. Google Play gaat het daadwerkelijke geheugengebruik op gebruikersapparaten meten.

Daarvoor worden vanaf 2027 twee nieuwe geheugenstatistieken onderdeel van Android Vitals:

• Memory usage: het anonieme RSS-geheugen van de app, gecombineerd met geheugen dat naar swap of zRAM is verplaatst;
• Bitmap memory usage: de hoeveelheid geheugen die door bitmapafbeeldingen wordt gebruikt.

Met Anonymous RSS wordt onder meer geheugen bedoeld dat rechtstreeks door de app wordt gebruikt, bijvoorbeeld voor de Java- of Kotlin-heap, native geheugenallocaties en andere anonieme geheugentoewijzingen. Swap wordt eveneens meegerekend. Op Android wordt daarbij onder meer zRAM gebruikt om geheugenpagina's te comprimeren wanneer dat nodig is.

Dat is belangrijk omdat een app die ogenschijnlijk binnen een bepaalde geheugengrens blijft, alsnog grote druk op het systeem kan veroorzaken wanneer Android delen van het geheugen moet comprimeren of naar swap moet verplaatsen.

Google kijkt bovendien niet naar één afzonderlijke meting. De beoordeling is gebaseerd op gebruiksgegevens over een langere periode. Net als bij andere Android Vitals gebruikt Google een periode van 28 dagen en wordt het 90e percentiel gebruikt om te bepalen of een app structureel boven een bepaalde grens uitkomt.

Een 90e percentiel betekent in de praktijk dat ongeveer 90 procent van de gemeten waarden onder de betreffende grens ligt en dat de hoogste 10 procent daarboven zit. Hierdoor wordt voorkomen dat één incidentele uitschieter automatisch bepaalt of een app wel of niet aan de eisen voldoet.

De geheugengrens hangt af van het toestel

Er komt geen universele geheugenlimiet die voor iedere Android-smartphone hetzelfde is. Google maakt onderscheid tussen verschillende RAM-categorieën en tussen de verschillende toestanden waarin een app zich kan bevinden.

Dat is logisch: een app op een toestel met relatief weinig RAM heeft veel minder ruimte dan dezelfde app op een smartphone met aanzienlijk meer geheugen.

Voor reguliere apps gelden vanaf februari 2027 onder meer de volgende grenzen voor het 90e percentiel van het dynamische geheugengebruik:

Voor toestellen met zeer weinig RAM en voor de hoogste RAM-categorieën gelden niet in alle gevallen dezelfde handhavingsdrempels. Ook moet worden bedacht dat de categorieën zijn gebaseerd op de totale beschikbare systeemgeheugenclassificatie van het apparaat en niet simpelweg op het getal dat een fabrikant op de doos vermeldt.

De belangrijkste conclusie is daarom dat een ontwikkelaar niet kan volstaan met de redenering dat een smartphone bijvoorbeeld 8 of 12 GB RAM heeft. Google beoordeelt het daadwerkelijke gedrag van de app binnen de relevante hardwarecategorie en de toestand waarin de app draait.

Een app krijgt meer ruimte wanneer hij actief wordt gebruikt

Ook de toestand van de app speelt een belangrijke rol.

Een app die daadwerkelijk op het scherm wordt gebruikt, krijgt meer ruimte dan een proces dat alleen op de achtergrond actief is. Een applicatie die in de cache staat, wordt weer anders behandeld.

Dat onderscheid moet voorkomen dat ontwikkelaars grote hoeveelheden geheugen vasthouden terwijl hun app voor de gebruiker niet zichtbaar of actief is.

Vooral achtergrondprocessen kunnen daardoor belangrijk worden. Een app die op de achtergrond grote hoeveelheden data, afbeeldingen of andere objecten in het geheugen blijft bewaren, kan daarmee sneller tegen de nieuwe grenzen aanlopen.

Google wil ontwikkelaars hiermee stimuleren om geheugen daadwerkelijk vrij te geven wanneer dat niet meer nodig is.

Bitmapgeheugen krijgt een aparte beoordeling

Naast het totale dynamische geheugengebruik gaat Google specifiek kijken naar het geheugen dat door bitmaps wordt gebruikt.

Dat is relevant voor apps die veel afbeeldingen verwerken, bijvoorbeeld sociale media, foto-apps, games, videodiensten en andere toepassingen met veel visuele content.

Bitmaps kunnen relatief veel werkgeheugen innemen. Een afbeelding die op het scherm wordt weergegeven, moet immers op een bepaald moment in een voor Android bruikbare geheugenrepresentatie beschikbaar zijn. Wanneer een app vervolgens grote aantallen afbeeldingen blijft vasthouden terwijl ze niet meer zichtbaar zijn, kan het geheugengebruik snel oplopen.

Google maakt daarom onderscheid tussen zichtbaar gebruik en het onnodig lang vasthouden van bitmapgegevens. Vooral in achtergrond- en cached-toestanden moeten apps voorkomen dat grote hoeveelheden bitmapgeheugen onnodig worden vastgehouden.

Android zelf krijgt eveneens strengere geheugenbeperkingen

De nieuwe Play Store-regels staan niet los van ontwikkelingen binnen Android zelf.

Google werkt tegelijkertijd aan bredere geheugenlimieten binnen het besturingssysteem. Het doel daarvan is om te voorkomen dat één proces zoveel geheugen opeist dat de prestaties van het hele apparaat verslechteren.

Wanneer een app zijn beschikbare geheugenbudget bereikt, kan Android eerst proberen geheugen efficiënter te beheren door pagina's naar zRAM te verplaatsen. Dat voorkomt niet noodzakelijk direct dat de app blijft draaien, maar comprimeren en decomprimeren kost wel processorkracht. Een te zware geheugendruk kan daardoor leiden tot vertragingen en een minder vloeiende gebruikerservaring.

Als het geheugengebruik verder oploopt en de systeemdruk te groot wordt, kan Android uiteindelijk besluiten een proces te beëindigen.

Voor gebruikers kan dat zich bijvoorbeeld uiten in apps die opnieuw moeten worden geladen nadat ze naar de achtergrond zijn verplaatst. Voor ontwikkelaars betekent het dat efficiënt geheugenbeheer steeds belangrijker wordt.

De nieuwe Google Play-eisen vormen daarmee een tweede laag bovenop de beperkingen die Android zelf aan processen oplegt.

De regels zijn vooral gericht op structurele problemen

Het doel van Google is niet dat iedere app op ieder moment zo weinig mogelijk RAM gebruikt. Een moderne app heeft nu eenmaal geheugen nodig om gegevens te verwerken, snel te reageren en een goede gebruikerservaring te bieden.

Het probleem ontstaat vooral wanneer een app structureel meer geheugen gebruikt dan redelijk is voor zijn hardwarecategorie of wanneer de app geheugen blijft vasthouden dat niet langer noodzakelijk is.

Daarom gebruikt Google het 90e percentiel over een periode van 28 dagen. Een incidentele piek hoeft daardoor niet meteen te betekenen dat een app de nieuwe eisen overtreedt.

Voor ontwikkelaars wordt het echter wel belangrijker om geheugenproblemen in echte gebruikerssessies te onderzoeken in plaats van alleen te testen op een eigen toestel.

Nieuwe statistieken zijn al eerder zichtbaar in Play Console

Ontwikkelaars hoeven niet tot februari 2027 te wachten om te zien hoe hun apps ervoor staan.

Google is bezig met het beschikbaar maken van nieuwe geheugenstatistieken binnen de Play Console. Daar kunnen ontwikkelaars onder meer zien hoe hun app presteert binnen verschillende RAM-categorieën en bij verschillende percentielen.

Ook komen er hulpmiddelen om te onderzoeken waarom een app veel geheugen gebruikt.

Daarnaast kunnen ontwikkelaars waarschuwingen krijgen wanneer hun software in de buurt komt van of boven de nieuwe kwaliteitsdrempels uitkomt. Daarmee wil Google voorkomen dat ontwikkelaars pas na het ingaan van de regels ontdekken dat hun app problemen veroorzaakt.

DEX-code moet vanaf 2027 eveneens worden geoptimaliseerd

Naast geheugen introduceert Google een tweede belangrijke technische eis: de optimalisatie van DEX-code.

DEX staat voor Dalvik Executable en vormt een belangrijk onderdeel van de uitvoerbare Android-code. Wanneer een applicatie veel DEX-code bevat, kan een slechte optimalisatie leiden tot een grotere softwarevoetafdruk, langere laadtijden en een hoger geheugengebruik.

Daarom gaat Google Play vanaf februari 2027 minimumvereisten stellen aan de mate waarin DEX-code wordt geoptimaliseerd.

Voor apps en games met een aanzienlijke hoeveelheid DEX-code moet een minimale optimalisatiegraad van 25 procent worden bereikt voor drie onderdelen:

• shrinking;
• optimalisatie;
• obfuscatie.

Voor reguliere apps geldt de nieuwe DEX-drempel wanneer de app meer dan 10 MB DEX-code bevat. Voor games ligt de grens hoger: daar wordt de eis toegepast bij meer dan 50 MB DEX-code.

Het gaat dus niet om de totale downloadgrootte van een app. Een grote app hoeft niet automatisch een probleem te hebben als de omvang vooral wordt veroorzaakt door bijvoorbeeld afbeeldingen, video's, modellen of andere assets. De nieuwe regel kijkt specifiek naar de omvang en optimalisatie van de DEX-code.

R8 kan ontwikkelaars daarbij helpen

Google schrijft niet voor dat iedere ontwikkelaar één specifieke optimizer moet gebruiken.

Het bedrijf noemt R8 wel als belangrijk hulpmiddel. R8 kan onder meer ongebruikte code verwijderen, code optimaliseren en bepaalde onderdelen verkleinen of verhullen.

Het achterliggende idee is eenvoudig: wanneer een applicatie code bevat die niet daadwerkelijk nodig is voor de uiteindelijke distributieversie, hoeft die code ook niet noodzakelijk in dezelfde vorm meegeleverd te worden.

Door code te verkleinen en te optimaliseren kan een app niet alleen kleiner worden. Een efficiëntere codebasis kan ook bijdragen aan sneller opstarten, lager geheugengebruik en betere runtimeprestaties.

Google staat echter ook andere tools toe waarmee aan de vereisten kan worden voldaan.

Het gaat om drie afzonderlijke optimalisatiepercentages

De formulering van Google is belangrijk. De eis is niet simpelweg dat een DEX-bestand in totaal 25 procent kleiner moet worden.

Google kijkt naar drie afzonderlijke aspecten:

Shrinking richt zich op het verwijderen van overbodige of ongebruikte code.

Optimalisatie heeft betrekking op het verbeteren van de gegenereerde code, zodat deze efficiënter kan worden uitgevoerd.

Obfuscatie maakt code moeilijker leesbaar en kan tegelijkertijd helpen om de uiteindelijke code efficiënter te verpakken.

Voor de betreffende apps en games moet elk van deze onderdelen minimaal aan de vereiste van 25 procent voldoen.

De ontwikkelaar kan de resultaten van de optimalisatie per geüploade app bundle bekijken in de Play Console.

Waarom Google deze eisen nu invoert

De maatregelen komen op een moment waarop smartphones en apps voor een aantal nieuwe uitdagingen staan.

Traditioneel konden fabrikanten een groeiend geheugengebruik deels opvangen door smartphones simpelweg met meer RAM uit te rusten. Die strategie is echter niet onbeperkt houdbaar.

Geheugencomponenten zijn duurder geworden en de beschikbaarheid van geheugenhardware staat onder druk. Tegelijkertijd worden apps steeds uitgebreider.

Daar komt de groei van kunstmatige intelligentie op het apparaat bij. AI-functies die lokaal op een smartphone worden uitgevoerd, kunnen aanzienlijk meer geheugen vragen dan eenvoudige traditionele mobiele functies.

Dat betekent dat hetzelfde systeemgeheugen door steeds meer processen moet worden gedeeld.

Google probeert daarom twee ontwikkelingen tegelijk aan te pakken: het besturingssysteem moet apps beter beschermen tegen buitensporig geheugengebruik, terwijl ontwikkelaars worden aangespoord hun eigen software efficiënter te maken.

Vooral grote apps en games krijgen meer werk

Voor kleine, goed geoptimaliseerde apps zullen de nieuwe regels waarschijnlijk minder ingrijpend zijn.

De grootste gevolgen zijn te verwachten bij omvangrijke apps, games en toepassingen die grote hoeveelheden gegevens tegelijkertijd in het geheugen houden.

Denk daarbij aan software met grote hoeveelheden afbeeldingen, complexe gebruikersinterfaces, uitgebreide lokale databases, zware libraries of grote hoeveelheden uitvoerbare code.

Voor ontwikkelaars van dergelijke apps wordt het belangrijker om niet alleen naar functionaliteit te kijken, maar ook voortdurend te meten hoeveel geheugen iedere functie daadwerkelijk kost.

Een applicatie kan immers technisch goed functioneren op een ontwikkeltelefoon, terwijl duizenden gebruikers op goedkopere of oudere apparaten tegen geheugenproblemen aanlopen.

Google gaat technische kwaliteit directer koppelen aan distributie

De belangrijkste verandering is misschien wel dat geheugenoptimalisatie niet langer uitsluitend een interne technische keuze van een ontwikkelaar is.

Vanaf februari 2027 worden de nieuwe geheugen- en code-optimalisatiemetrieken onderdeel van de technische kwaliteitseisen van Google Play.

Apps en games die de nieuwe zogenaamde bad-behavior-thresholds overschrijden, kunnen daardoor gevolgen ondervinden binnen Google Play. Google heeft aangegeven dat dit onder meer kan leiden tot een lagere zichtbaarheid van een app en beperkingen rond publicatiemogelijkheden.

Daarmee verandert de positie van geheugenoptimalisatie fundamenteel.

Tot nu toe was het vooral een kwestie van prestaties, stabiliteit en gebruikerservaring. Vanaf 2027 kan het daarnaast ook rechtstreeks gevolgen hebben voor de manier waarop een app via Google Play wordt gedistribueerd.

Ontwikkelaars krijgen nog enkele maanden voorbereidingstijd

De nieuwe regels gaan in februari 2027 in. Google maakt de relevante meetgegevens echter al eerder beschikbaar, zodat ontwikkelaars hun apps kunnen controleren en aanpassen.

Dat geeft ontwikkelaars de mogelijkheid om vóór de daadwerkelijke handhaving te onderzoeken waar geheugenproblemen ontstaan.

Vooral het analyseren van gebruikersgegevens wordt daarbij belangrijk. Een ontwikkelaar kan bijvoorbeeld ontdekken dat het geheugengebruik op toestellen met 4 GB RAM aanzienlijk hoger ligt dan op moderne smartphones met 12 of 16 GB RAM.

Ook kan blijken dat een app in de voorgrond probleemloos presteert, maar na langere tijd op de achtergrond onnodig veel geheugen blijft vasthouden.

Door die verschillen zichtbaar te maken, kan een ontwikkelaar gericht optimaliseren.

Wat verandert er concreet voor Android-gebruikers?

Voor gebruikers is de verandering vooral indirect merkbaar.

Google wil voorkomen dat apps het beschikbare geheugen zo zwaar belasten dat andere apps voortdurend opnieuw moeten worden geladen of dat het toestel merkbaar trager reageert.

Op langere termijn kunnen de maatregelen daardoor bijdragen aan een stabielere Android-ervaring, vooral op apparaten met minder RAM.

Gebruikers hoeven zelf geen instellingen aan te passen om aan de nieuwe regels te voldoen. De verantwoordelijkheid ligt bij Google en vooral bij de ontwikkelaars van de apps.

Een app die veel geheugen nodig heeft, wordt dus niet automatisch van een toestel verwijderd. Het gaat in eerste instantie om kwaliteitsmetingen en de voorwaarden waaronder ontwikkelaars hun apps via Google Play kunnen blijven verspreiden.

De combinatie van maatregelen is belangrijk

De afzonderlijke maatregelen lijken op het eerste gezicht technisch en relatief beperkt, maar samen vormen ze een duidelijke koerswijziging.

Google gaat vanaf 2027 niet alleen kijken naar wat een Android-app doet, maar ook naar hoe efficiënt die app dat doet.

Aan de ene kant wordt het daadwerkelijke dynamische geheugengebruik gemeten. Aan de andere kant wordt specifiek gekeken naar bitmapgeheugen. Daarnaast moet omvangrijke DEX-code voldoende worden verkleind, geoptimaliseerd en geobfusceerd.

Daarmee ontstaat een bredere kwaliteitscontrole die verschillende oorzaken van een zware Android-app tegelijk probeert aan te pakken.

Android beweegt naar een efficiënter software-ecosysteem

De nieuwe regels laten vooral zien dat Google niet langer ervan uitgaat dat smartphones het groeiende geheugengebruik van apps altijd kunnen oplossen door simpelweg meer RAM toe te voegen.

De hoeveelheid beschikbare hardware is eindig, terwijl de eisen van moderne software blijven toenemen. Lokale AI, complexere games, rijkere interfaces en steeds grotere softwarebibliotheken versterken die ontwikkeling.

Google kiest daarom voor een andere aanpak: het besturingssysteem krijgt strengere mogelijkheden om buitensporig geheugengebruik te beperken en Google Play gaat ontwikkelaars rechtstreeks aanspreken op de efficiëntie van hun apps.

Vanaf februari 2027 worden geheugengebruik, bitmapgebruik en DEX-optimalisatie daardoor niet langer uitsluitend technische aandachtspunten voor ontwikkelaars. Ze worden onderdeel van de voorwaarden voor een kwalitatief goede app op Google Play.

Voor gebruikers zou dat uiteindelijk moeten betekenen dat Android-apps efficiënter omgaan met het beschikbare geheugen, minder snel andere processen verdringen en beter blijven functioneren op apparaten waarop de hoeveelheid RAM niet onbeperkt kan blijven groeien.

Door: Drifter