Google impone limiti di memoria alle app Android: scatta dal 2027

Quando Google parla di qualità delle app, raramente intende estetica o nuove funzioni. Intende frizione: quei micro-blocchi, i riavvii silenziosi in background, le lentezze improvvise e i crash per "memoria esaurita" che su uno smartphone potente passano come fastidi sporadici, ma su un dispositivo medio o economico diventano la norma quotidiana. Dal febbraio 2027, le app Android distribuite tramite Play Store dovranno rispettare nuovi limiti sull'uso della RAM, trasformando quella che era una raccomandazione in un requisito operativo con conseguenze concrete per gli sviluppatori e, indirettamente, per le scelte d'acquisto degli utenti.

La memoria costa di più, le app pesano di più

Nella forma, la notizia sembra una classica stretta di piattaforma: nuove soglie, nuovi strumenti nella Play Console — il pannello di controllo che gli sviluppatori usano per pubblicare e monitorare le loro app — e penalità per chi non si adegua. Nella sostanza è qualcosa di più: Google sta cercando di governare il bloat, l'aumento progressivo del peso delle applicazioni, in un momento in cui l'economia della memoria è diventata più instabile. Nel 2026, secondo stime di TrendForce, i prezzi contrattuali della DRAM mobile hanno registrato rialzi molto forti nel secondo trimestre, con la variante LPDDR5X — la memoria ad alte prestazioni usata nei telefoni di fascia alta — cresciuta nell'ordine del +78–83% trimestre su trimestre. Allo stesso tempo, la capacità media di RAM sugli smartphone continua a salire, stimata intorno a 8,5 GB nel 2026.

È una tensione quasi paradossale: le esperienze che chiediamo alle app spingono verso più memoria, ma la memoria costa di più e diventa un vincolo di prodotto. In questo scenario, la leva software diventa una scorciatoia industriale: se non si può — o non si vuole — aumentare la RAM su tutta la gamma di dispositivi, si cerca di farla "bastare" meglio.

Metriche dal campo, non da laboratorio

Il dettaglio che rende questa mossa diversa da una generica campagna di ottimizzazione è il metodo. Le soglie non verranno verificate in laboratorio, ma con metriche raccolte su grandi volumi di utilizzo reale. La Play Console mostrerà valori basati su finestre mobili di 28 giorni e su un indicatore di coda chiamato P90, cioè il comportamento del 10% di utenti con i valori più alti di consumo, filtrabile per stato dell'app (in primo piano, in background, in cache) e per fascia di RAM del dispositivo. È un punto chiave perché sposta l'attenzione dal "quanto consuma in media" al "quanto va fuori controllo nei casi peggiori": quelli in cui una perdita di memoria o una cache che cresce senza limiti trasformano una sessione d'uso in un'esperienza sempre più lenta e instabile.

Le tre aree oggetto delle nuove soglie sono: uso di memoria complessivo misurato come Anonymous RSS + Swap, consumo di memoria legato alle bitmap e ottimizzazione del codice DEX. Capire cosa significano concretamente aiuta a capire dove Google vuole intervenire.

La prima metrica è meno familiare ai non addetti, ma il concetto è intuitivo: non conta solo quanta memoria l'app tiene attiva in RAM, conta anche quanta ne viene compressa o spostata nello spazio di swap — su Android tipicamente gestito da zRAM — quando il sistema è sotto pressione. Per l'utente, la differenza si percepisce come reattività che cala e animazioni che scattano: il telefono non è "più lento" in assoluto, è più spesso costretto a fare i conti con memoria che va e viene.

Google vuole misurare non quanto consuma un'app in media, ma quanto va fuori controllo nei casi peggiori

Immagini, dipendenze e codice gonfiato

La scelta di includere le bitmap — le immagini caricate in memoria — come area distinta è altrettanto significativa. Nel 2026 molte app sono feed di immagini, anteprime video, cataloghi e interfacce ricche. La memoria occupata dalle immagini è uno dei punti in cui si paga più facilmente il prezzo della comodità: pre-caricare tutto per scorrere in modo fluido, oppure caricare su richiesta rischiando attese e schermate vuote. Quando Google dice "bitmap memory usage", sta di fatto dicendo agli sviluppatori che l'ottimizzazione deve toccare asset, pipeline di caricamento e gestione della cache — non solo il codice.

L'ultimo tassello, l'ottimizzazione DEX, chiarisce forse meglio di tutti l'ambizione di Google. Il DEX è il formato dei file eseguibili delle app Android. Un'app moderna tende a portarsi dietro decine di librerie esterne — chiamate SDK — per pubblicità, analisi dei dati, test A/B, antifrode, pagamenti, assistenza clienti. Non sono dettagli: sono blocchi di codice che aumentano dimensioni e complessità, e che spesso arrivano come "scatole nere" da aggiornare per ragioni commerciali o di sicurezza. Collegare la qualità di pubblicazione all'ottimizzazione del codice significa spingere verso strumenti come R8 — lo strumento di Android che riduce e ottimizza il codice — e verso un lavoro più disciplinato su cosa entra nel pacchetto finale e quanto di quel codice è davvero necessario.

Non un ban, ma una penalità che fa male

Google ha chiarito anche il tipo di sanzione: non è un'espulsione dallo Store. Le app che superano i limiti subiranno una riduzione di visibilità e di capacità di pubblicazione. È una penalità che colpisce dove fa più male senza arrivare al blocco totale: sul ciclo di rilascio e sulla possibilità di essere trovate dagli utenti. In un ecosistema dove la competizione si gioca spesso su chi aggiorna prima e chi appare meglio nei risultati di ricerca, trasformare la memoria in una metrica di qualità equivale a creare un incentivo economico e operativo, non solo tecnico.

Vale la pena leggere questa mossa in continuità con un precedente: Android Vitals, il sistema di metriche di qualità raccolte sul campo che Google usa da anni come leva per spingere stabilità e buone pratiche. Il pattern è abbastanza coerente: rendere misurabile un problema — crash, blocchi, consumo batteria, ora la memoria — dargli visibilità in Play Console e, a un certo punto, legarlo a meccanismi di ranking o di pubblicazione. La stretta sulla RAM è meno un fulmine a ciel sereno e più un nuovo capitolo nella trasformazione di Play da semplice canale di distribuzione a regolatore tecnico dell'ecosistema.

C'è anche un secondo livello, più strutturale. Nel 2026 il team Android ha comunicato una diffusione più ampia dei limiti di memoria per-app legati alla configurazione del dispositivo, con conseguenze nette come la terminazione forzata del processo quando l'app supera certe soglie. Non è solo una questione di "Play ti penalizza": è una questione di sistema operativo che chiude l'app quando esagera. In questa cornice, Play si posiziona come filtro preventivo: se il sistema diventa più severo, la piattaforma di distribuzione prova a ridurre il numero di app che arrivano sul campo in condizioni critiche.

Chi ci guadagna e chi paga il costo

Gli utenti con dispositivi meno potenti potrebbero essere i primi a beneficiarne, ma non in modo lineare. Migliorare l'uso della RAM può ridurre i casi in cui un'app viene chiusa in background e deve ricaricarsi da zero; può rendere più costante la fluidità nelle sessioni lunghe; può diminuire certi tipi di crash per memoria esaurita. Ma la memoria non è un rubinetto che si chiude senza effetti collaterali: è spesso il buffer che rende gradevole l'esperienza. Se un'app è costretta a stringere, può reagire con più ricaricamenti, immagini meno definite o funzioni che si "spengono" sui dispositivi con meno RAM. Il trade-off implicito è questo: una qualità più prevedibile su un parco dispositivi ampio può significare esperienze meno ricche o più variabili a seconda dell'hardware.

Un'app più leggera non è sempre un'app migliore: dipende da cosa si è disposti a sacrificare

Per gli sviluppatori, il punto critico è la distribuzione del costo. Le grandi aziende con centinaia di milioni di utenti hanno spesso team dedicati alle prestazioni e strumenti interni per rilevare regressioni. Per un editore medio o un indipendente la situazione è diversa: ottimizzare davvero l'uso della memoria significa analizzare le dipendenze, riscrivere parti di codice, fare profiling costante e spesso negoziare internamente su cosa si può sacrificare. E c'è un elemento che rende il tema delicato: molta "pesantezza" arriva da SDK terzi che entrano per ragioni di monetizzazione o conformità normativa. Se Play trasforma la memoria in una metrica che impatta visibilità e rilascio, è plausibile che si apra una selezione indiretta: chi controlla meglio la propria catena di fornitura software avrà più margine competitivo nello Store.

L'eccezione temporanea per i giochi — con indicazioni specifiche attese nel 2027 — è un ulteriore indizio della complessità. I giochi hanno un profilo di memoria strutturalmente diverso: asset più grandi, grafica, motori di gioco, uso intensivo della GPU e picchi di consumo molto più pronunciati. Trattarli come un'app di produttività sarebbe poco realistico. Ma proprio questa eccezione rivela la direzione: l'obiettivo non è punire chi usa tanta memoria per sua natura, ma costruire una soglia di comportamento considerato problematico rispetto al contesto del dispositivo e dello scenario d'uso.

In Italia, dove la fascia media del mercato resta sensibile al prezzo e molti utenti tengono lo smartphone più a lungo, questa stretta ha un impatto potenzialmente più visibile di quanto sembri. Se l'ecosistema Play riesce davvero a rendere più leggere le app più comuni, il beneficio non si misura solo in secondi risparmiati: si misura in meno frustrazione quotidiana su dispositivi con 4–6 GB di RAM e in una vita utile percepita un po' più lunga. La contropartita potrebbe arrivare in modo silenzioso: app più sobrie nelle funzioni o più selettive su ciò che offrono su hardware economico, con una frammentazione che l'utente percepisce solo quando una funzione c'è su un modello e sparisce su un altro.

Il riferimento alla riduzione della RAM sul Pixel 11 Pro, più che un dettaglio di prodotto, suona come un messaggio industriale: la piattaforma non vuole più inseguire automaticamente l'aumento di memoria come soluzione universale. Se la DRAM resta volatile e costosa, e se il mercato chiede dispositivi più accessibili, l'ottimizzazione smette di essere un esercizio di stile e diventa una condizione per far funzionare l'economia del mobile. La domanda aperta è quanto questo nuovo standard produrrà app realmente più efficienti e quanto, invece, spingerà verso esperienze "adattive" che cambiano a seconda del dispositivo — portando nel software quella segmentazione che finora era soprattutto una questione di prezzo e scheda tecnica.