Il Play Store dichiara guerra alle app ‘vampiro’: come si salva la batteria

La batteria resta uno dei punti più delicati nell’uso quotidiano di uno smartphone Android, e Google ha deciso di intervenire in modo più deciso proprio su questo fronte. Dal 1° marzo 2026 il Play Store ha iniziato ad applicare nuove misure tecniche legate ai wake lock, quei meccanismi che tengono attivo il processore anche a schermo spento.

L’obiettivo è ridurre il consumo eccessivo di energia causato da app che restano sveglie troppo a lungo in background. Le app che superano la nuova soglia di comportamento scorretto rischiano avvisi visibili nella scheda sul Play Store e una minore visibilità nelle sezioni di scoperta, come suggerimenti e raccomandazioni.

Vuoi ascoltare il riassunto dell’articolo?

Ascolta su Spreaker.

Google ha promosso l’efficienza energetica a metrica fondamentale di qualità tecnica, allo stesso livello di crash e ANR (blocchi dell’app). Il parametro chiave riguarda i partial wake lock, cioè i wake lock che tengono attivo il CPU mentre lo schermo resta spento.

La soglia di comportamento scorretto scatta quando un’app mantiene un partial wake lock non esentato per almeno 2 ore in media a schermo spento in oltre il 5% delle sessioni degli ultimi 28 giorni. Superato questo limite, l’app può ricevere avvisi nella pagina sullo store ed essere esclusa da alcune superfici di scoperta.

Esistono però dei wake lock esentati, gestiti dal sistema e legati a funzioni con un chiaro beneficio per l’utente che non si possono ottimizzare ulteriormente: ad esempio riproduzione audio, accesso alla posizione o trasferimenti di dati avviati dall’utente. Questi non vengono conteggiati nella metrica di excessive partial wake lock usata da Android vitals.

Molte app confondono foreground service e partial wake lock, usando entrambi in modo ridondante. Il foreground service comunica al sistema che l’app sta svolgendo un’attività visibile o percepibile dall’utente e che non dovrebbe essere chiusa per recuperare memoria, ma non garantisce da solo che il processore resti attivo a schermo spento.

Il partial wake lock, invece, serve proprio a tenere il CPU sveglio con display spento. In pratica, il foreground service gestisce il ciclo di vita dell’attività, mentre il wake lock controlla lo stato energetico del dispositivo.

Google raccomanda di usare un wake lock manuale solo quando davvero necessario, e solo per il tempo strettamente legato all’attività di calcolo in background, spesso in combinazione con un foreground service. Inoltre, quando si sfruttano API che già mantengono il dispositivo attivo (come alcune API di sistema), non serve aggiungere un altro wake lock. Per scegliere lo strumento corretto, Google rimanda al diagramma “Choose the right API to keep the device awake” nelle proprie risorse tecniche.

Non sempre è il codice principale dell’app a generare wake lock eccessivi: spesso la responsabilità ricade su librerie di terze parti o API di sistema usate dall’app. In questi casi, la prima tappa consigliata è Android vitals, dove la dashboard degli excessive partial wake locks mostra il nome esatto del wake lock problematico.

Incrociando questo nome con la guida “Identify wake locks created by other APIs” è possibile capire se il wake lock arriva da una API di sistema o da una libreria Jetpack. Se così fosse, conviene rivedere come si usa quell’API e seguire le indicazioni ufficiali per ridurre l’impatto sulla batteria.

Quando il wake lock non è immediatamente riconoscibile, Google suggerisce di riprodurre il problema in locale e registrare un System Trace, da analizzare con l’interfaccia Perfetto. Questo permette di vedere con precisione quando il wake lock viene acquisito e rilasciato.

Se il problema deriva da un SDK esterno poco efficiente e non configurabile in modo più rispettoso della batteria, le opzioni diventano: segnalare il problema ai responsabili dell’SDK, sostituire la libreria con un’alternativa più attenta ai consumi oppure implementare internamente la funzionalità.

Un caso tipico di uso intenso della batteria riguarda i trasferimenti di dati avviati dall’utente, come il download di un video per la visione offline o il backup di foto e contenuti multimediali.

In passato molte app gestivano questi scenari con wake lock manuali di lunga durata.

Google ora indica una strada più pulita: usare l’API per i User-Initiated Data Transfer (UIDT). Questa API è pensata proprio per i trasferimenti prolungati richiesti dall’utente e rientra tra i casi esentati dal conteggio dei wake lock eccessivi.

In pratica, affidandosi a UIDT, l’app può mantenere il trasferimento affidabile anche a schermo spento, senza accumulare tempo di partial wake lock che peggiora le metriche di Android vitals e la reputazione sul Play Store.

Per le sincronizzazioni periodiche o le attività una tantum in background (come aggiornare dati per l’uso offline o recuperare il conteggio dei passi), Google sconsiglia l’uso di wake lock manuali e punta tutto su WorkManager.

Configurato per lavori una tantum o periodici, WorkManager rispetta le politiche di salute del sistema, raggruppa i task per ridurre i risvegli del processore e impone un intervallo minimo di 15 minuti per i lavori ricorrenti, sufficiente per la maggior parte degli aggiornamenti.

Se Android vitals segnala wake lock associati a WorkManager o JobScheduler con uso elevato, spesso il problema non è l’API in sé ma una configurazione errata del worker che non termina in alcuni scenari. Google suggerisce di analizzare i motivi di stop del worker, con attenzione a STOP_REASON_TIMEOUT, e di registrare questi eventi in log per capire dove intervenire.

Oltre al logging, torna utile raccogliere system trace per osservare in dettaglio l’acquisizione e il rilascio dei wake lock. Google cita anche un caso pratico, quello di WHOOP, che ha individuato un errore nella configurazione dei worker e ha ridotto in modo significativo l’impatto dei wake lock dopo aver corretto il flusso.

Le app che dialogano con dispositivi esterni via Bluetooth (orologi, sensori, accessori vari) rientrano tra le principali responsabili di wake lock prolungati, soprattutto durante abbinamenti, notifiche da hardware esterno, trasferimenti di file o aggiornamenti firmware.

Per la fase di pairing, Google raccomanda di usare il companion device pairing, che gestisce in modo più efficiente l’abbinamento senza richiedere un wake lock manuale.

Per la comunicazione in background, la guida “Communicate in the background” spiega come strutturare lo scambio dati limitando l’impatto sulla batteria.

Quando la comunicazione può tollerare un certo ritardo, spesso basta affidarsi a WorkManager per programmare i task, evitando di tenere il processore attivo in modo continuo. Se invece si valuta che un wake lock manuale sia davvero necessario, Google invita a limitarlo al solo periodo in cui avviene l’attività Bluetooth o l’elaborazione dei dati ricevuti, evitando di mantenerlo oltre il necessario.

Applicazioni come quelle di fitness o di consegna cibo spesso richiedono aggiornamenti frequenti della posizione per tracciare percorsi o mostrare l’avanzamento in tempo reale. Qui il rischio di wake lock continui è alto, ma Google chiarisce che non serve un lock dedicato per ogni scenario.

Le linee guida per ottimizzare l’uso della posizione suggeriscono di introdurre timeout, usare il batching delle richieste o sfruttare gli aggiornamenti passivi per ridurre il numero di risvegli del processore.

Quando si usano FusedLocationProvider o LocationManager, il sistema attiva automaticamente un breve wake lock di sistema durante il callback di posizione.

Questo wake lock di breve durata, gestito dal sistema, è esentato dal conteggio degli excessive partial wake lock. Per questo motivo Google invita a evitare un wake lock continuo per il semplice caching dei dati di posizione: meglio salvare gli eventi in memoria o in archiviazione locale e delegare a WorkManager l’elaborazione periodica, così da mantenere l’app reattiva senza penalizzare la batteria.

App che monitorano sensori a frequenza elevata, come contapassi, rilevamento di cadute o incidenti, possono generare un numero elevato di risvegli del CPU e quindi un forte impatto sulla batteria. Google invita a usare SensorManager con moderazione, attivando i sensori solo quando l’utente ha dato un consenso esplicito tramite interfaccia.

Per il tracciamento di passi o distanza, invece di leggere continuamente i sensori, conviene sfruttare la Recording API o Health Connect, che offrono dati storici e aggregati in modo più efficiente dal punto di vista energetico.

Quando si registra un sensore con SensorManager, è importante impostare un maxReportLatencyUs di almeno 30 secondi per abilitare il batching dei dati del sensore. In questo modo il sistema può accumulare letture e inviarle tutte insieme quando il dispositivo viene comunque riattivato da un altro evento (interazione utente, richiesta di posizione, job pianificato), riducendo il numero di interruzioni del CPU.

Se l’app ha bisogno sia di posizione sia di dati dai sensori, Google suggerisce di sincronizzare la raccolta: agganciare la lettura dei sensori al breve wake lock che il sistema già usa per gli aggiornamenti di posizione. Per la successiva elaborazione o l’upload dei dati combinati, si può usare un worker o, se proprio necessario, un wake lock di durata molto limitata.

Le app che gestiscono monitoraggio remoto (audio o video) o mantengono connessioni di rete persistenti con un client desktop rientrano tra i casi più delicati per i wake lock.

Quando gli eventi possono essere gestiti lato server, Google consiglia di usare Firebase Cloud Messaging (FCM) per recapitare le informazioni al dispositivo, eventualmente abbinato a un worker accelerato per l’elaborazione aggiuntiva.

Se invece gli eventi devono per forza essere elaborati sul client tramite una connessione socket, non serve tenere un wake lock solo per “ascoltare”. Quando arrivano pacchetti sulla rete Wi‑Fi o cellulare, l’hardware radio genera un interrupt a livello di kernel che risveglia il dispositivo tramite un kernel wake lock.

In uno scenario come quello gestito con ktor-network, il processore può restare a riposo mentre il codice attende nuovi pacchetti. Solo quando i dati arrivano davvero, l’app può decidere se usare un wake lock manuale per un’elaborazione urgente o programmare un worker se il lavoro può essere rimandato. In questo modo il tempo totale in wake lock resta contenuto e più facile da mantenere sotto le soglie imposte da Android vitals.

Le nuove regole di enforcement sui wake lock non sono solo un tema tecnico per sviluppatori, ma incidono direttamente sulla qualità percepita delle app e sulla loro visibilità nel Play Store. Chi progetta o mantiene un’app Android deve iniziare a considerare il consumo energetico come un vincolo di progetto al pari della stabilità.

Adottare strumenti come WorkManager, UIDT, le API di posizione e sensori pensate per il risparmio energetico non significa solo evitare avvisi e penalizzazioni, ma anche offrire un’esperienza più affidabile a chi usa l’app ogni giorno, senza dover correre a cercare il caricabatterie a metà pomeriggio.