Doze Mode: essenza, fasi e meccanismo di risparmio energetico

Cos’è Doze Mode

Doze Mode è un meccanismo integrato di risparmio energetico di Android che si attiva quando il dispositivo non è collegato a un caricabatterie, lo schermo è spento e l’utente non ha interagito con il dispositivo per un certo periodo. L’obiettivo di Doze è minimizzare l’attività in background delle app per massimizzare la durata della batteria in modalità standby. Il sistema posticipa JobScheduler, la sincronizzazione degli account, AlarmManager e le richieste di rete.

La modalità è stata introdotta in Android 6.0 Marshmallow (API 23) ed è stata significativamente migliorata nelle versioni successive. Android 7.0 Nougat ha introdotto una seconda fase (Light Doze) che si attiva quando il dispositivo è in movimento. Android 8.0 ha aggiunto ulteriori restrizioni ai servizi in background che lavorano insieme a Doze. In Android 12+, Doze è stato integrato con un sistema di gestione della batteria aggiornato che analizza il comportamento dell’utente.

È importante capire: Doze Mode non disabilita completamente le app. Le mette in uno stato con attività posticipate, ma non uccide i processi. Un Foreground Service con notifica continua a funzionare, le notifiche push ad alta priorità (FCM high-priority) vengono consegnate e gli allarmi scattano come programmato. Doze influisce solo sulle operazioni in background che l’utente non vede o non si aspetta in quel momento.

Condizioni di attivazione

Doze Mode si attiva quando sono soddisfatte tutte le condizioni: schermo spento per più di 30 minuti (prima attivazione), dispositivo fermo (tramite accelerometro) e non collegato a un caricabatterie. Se l’utente prende il telefono o collega un caricabatterie, Doze viene immediatamente disattivato. In Android 7+, Light Doze si attiva dopo soli 5 minuti di inattività, anche quando il dispositivo è in movimento.

Come funziona Doze Mode

Doze Mode gestisce l’attività in background tramite il servizio di sistema DeviceIdleController, che analizza lo stato dei sensori, dello schermo e del caricabatterie. Quando tutte le condizioni di attivazione sono soddisfatte, il sistema mette le app in modalità standby, raggruppando le loro richieste in finestre di manutenzione. All’interno di queste finestre, tutte le attività posticipate — chiamate di rete, sincronizzazione, AlarmManager — vengono eseguite in batch.

Il PowerManager di sistema controlla quali app possono uscire da Doze. Le notifiche push ad alta priorità (FCM high-priority) possono riattivare il dispositivo per consegnare un messaggio. Il sistema ignora inoltre Doze per le app aggiunte dall’utente alla whitelist di ottimizzazione della batteria. Tutte le altre app devono attendere la successiva finestra di manutenzione.

La durata delle finestre di manutenzione in Deep Doze aumenta in modo esponenziale: prima finestra dopo 1 ora, seconda dopo 2 ore, terza dopo 4 ore e così via fino a un intervallo massimo di 12 ore. Ciò significa che più a lungo il dispositivo rimane in Doze, meno frequentemente le app possono eseguire attività in background — risparmiando batteria nel modo più aggressivo possibile.

Impatto sulle richieste di rete

In Doze Mode, tutte le richieste di rete vengono sospese fino all’apertura di una finestra di manutenzione. Le uniche eccezioni sono i messaggi FCM ad alta priorità (con il tag “high_priority” nel payload) e i segnali di AlarmManager con i flag setAndAllowWhileIdle() o setExactAndAllowWhileIdle(). Le normali chiamate di rete tramite Retrofit, OkHttp o Volley non verranno eseguite fino all’apertura di una finestra.

Fasi di Doze Mode

Doze Mode è composto da due fasi: Light Doze (sonno leggero) e Deep Doze (sonno profondo). Ogni fase impone le proprie restrizioni e ha diverse soglie di attivazione. Comprendere la differenza tra le fasi è fondamentale per uno sviluppatore che progetta attività in background resilienti alla modalità di risparmio energetico.

Light Doze (sonno leggero)

Light Doze si attiva dopo 5–30 minuti di inattività del dispositivo (schermo spento, nessun movimento). In questa fase, le richieste di rete e la sincronizzazione vengono sospese, ma AlarmManager e JobScheduler continuano a funzionare con lievi ritardi. Le app possono uscire da Light Doze ricevendo una notifica push o collegandosi a un caricabatterie. Light Doze non richiede immobilità totale — il dispositivo può essere in movimento.

Deep Doze (sonno profondo)

Deep Doze si verifica dopo 60–90 minuti di inattività con il dispositivo fermo (l’accelerometro non rileva movimento). In Deep Doze, il sistema è significativamente più aggressivo nel posticipare le attività: le finestre di manutenzione si aprono meno frequentemente (con intervallo crescente in modo esponenziale), AlarmManager si attiva solo con i flag setAndAllowWhileIdle() e WakeLock non funziona nel modo usuale. Le app non presenti nella whitelist vengono quasi completamente private dell’attività in background.

Restrizioni in Doze Mode

Doze Mode impone diverse categorie di restrizioni che uno sviluppatore deve considerare durante la progettazione di un’app. Ignorare queste restrizioni porta alla mancata esecuzione delle attività in background e l’utente vede un comportamento errato dell’app — aggiornamenti mancanti, messaggi non inviati, sincronizzazione incompleta.

Restrizioni di rete

Tutte le richieste di rete vengono bloccate fino all’apertura di una finestra di manutenzione. Questo vale per chiamate HTTP, connessioni WebSocket e download di file. L’eccezione sono i messaggi FCM ad alta priorità, che passano attraverso un canale separato di Google Play Services indipendente da Doze. Per la sincronizzazione di dati critici, si consiglia di utilizzare WorkManager con la policy NetworkType.CONNECTED.

Restrizioni di AlarmManager

AlarmManager in Deep Doze posticipa tutti gli allarmi tranne quelli creati con i metodi setAndAllowWhileIdle() e setExactAndAllowWhileIdle(). Tuttavia, anche questi metodi hanno un limite — non più di 1 attivazione ogni 9 minuti per app. Gli allarmi esatti con setExact() in Deep Doze non garantiscono l’attivazione all’ora specificata.

Restrizioni di WakeLock

WakeLock si comporta in modo insolito in Doze Mode: il sistema non mantiene il blocco di riattivazione per le app al di fuori della whitelist. Anche se un’app ha acquisito correttamente un PARTIAL_WAKE_LOCK, quando Deep Doze inizia, il sistema può rilasciarlo forzatamente. L’unico modo per garantire l’esecuzione di attività in Doze è utilizzare un Foreground Service con una notifica.

• Rete — tutte le richieste posticipate fino alla finestra di manutenzione, eccetto FCM high-priority
• AlarmManager — allarmi esatti posticipati; setAndAllowWhileIdle — non più di 1/9 min
• WakeLock — rilasciato forzatamente per le app fuori dalla whitelist
• JobScheduler — attività raggruppate in finestre di manutenzione con intervallo esponenziale
• Sincronizzazione — Account SyncManager sospeso fino all’uscita da Doze

Whitelist ed eccezioni

La whitelist di Doze è un elenco di app a cui il sistema consente l’attività in background in modalità di risparmio energetico con restrizioni minime. L’utente può aggiungere manualmente app all’elenco tramite Impostazioni → Batteria → Ottimizzazione batteria. Le app di sistema, i launcher e Google Play Services sono nella whitelist per impostazione predefinita.

Uno sviluppatore può richiedere l’aggiunta alla whitelist tramite un dialogo di sistema con l’Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Ciò richiede l’autorizzazione REQUEST_IGNORE_BATTERY_OPTIMIZATIONS nel manifest. Tuttavia, Google non raccomanda di richiedere un’eccezione senza una ragione valida — le app che abusano di questa possibilità rischiano di essere rifiutate durante la pubblicazione su Google Play.

Senza la whitelist, un’app può utilizzare FCM ad alta priorità per riattivare il dispositivo da Doze. Ogni messaggio di questo tipo concede all’app una breve finestra (10–30 secondi) per eseguire un’attività. Per operazioni più lunghe, l’app deve avviare un Foreground Service, che continua a funzionare all’interno delle finestre di manutenzione di Doze. Google fornisce anche un meccanismo di esenzione per alcuni tipi di app: navigazione, mediche, messaggistica.

Come verificare lo stato della whitelist

Per verificare se un’app è nella whitelist di ottimizzazione della batteria, utilizzare il metodo powerManager.isIgnoringBatteryOptimizations(). Se il metodo restituisce false, l’app è soggetta a tutte le restrizioni di Doze. Se restituisce true, l’app può utilizzare Wakelock, AlarmManager e rete senza restrizioni anche in Deep Doze. Tuttavia, abusare di questo privilegio porterà a recensioni negative da parte degli utenti.

Test di Doze Mode

Testare il comportamento dell’app in Doze Mode è un passaggio obbligatorio dello sviluppo, poiché Doze può interrompere le funzioni in background. Android fornisce strumenti da riga di comando tramite ADB per forzare la transizione del dispositivo in Light Doze e Deep Doze. I test devono essere eseguiti su un dispositivo fisico o emulatore con Android 6.0+.

Per entrare in Light Doze, utilizzare il comando adb shell dumpsys deviceidle step light. Per Deep Doze — adb shell dumpsys deviceidle step deep. Il comando adb shell dumpsys deviceidle force-idle deep fa transitare immediatamente il dispositivo in Deep Doze senza attendere il timeout standard. Dopo i test, uscire da Doze con il comando adb shell dumpsys deviceidle unforce.

# Forzare l'ingresso in Light Doze
$ adb shell dumpsys deviceidle step light

# Forzare l'ingresso in Deep Doze
$ adb shell dumpsys deviceidle step deep

# Forzare Deep Doze immediatamente
$ adb shell dumpsys deviceidle force-idle deep

# Uscire da Doze
$ adb shell dumpsys deviceidle unforce

# Visualizzare lo stato di Doze
$ adb shell dumpsys deviceidle

Verifica del funzionamento dell’app

Dopo la transizione in Doze Mode, verificare: se le richieste di rete funzionano (dovrebbero essere posticipate), se AlarmManager si attiva, se i messaggi FCM vengono consegnati e se le attività di WorkManager vengono eseguite correttamente. WorkManager continua a funzionare in Doze: le sue attività vengono eseguite nelle finestre di manutenzione. Tuttavia, se un’attività richiede esecuzione immediata, specificare setExpedited() o utilizzare un Foreground Service.

Best practice per Doze Mode

Sviluppare un’app resiliente a Doze Mode richiede di ripensare l’approccio alle attività in background. Google raccomanda di progettare l’app in modo che funzioni correttamente sotto qualsiasi restrizione di Doze, senza dipendere dall’esecuzione immediata delle operazioni in background. Il principio fondamentale è utilizzare WorkManager per tutte le attività in background che possono essere posticipate.

Utilizzare WorkManager

WorkManager è l’API consigliata da Google per le attività in background perché si adatta automaticamente a Doze. WorkManager utilizza JobScheduler (API 23+) o AlarmManager + BroadcastReceiver sulle versioni precedenti. Le attività di WorkManager vengono eseguite nella finestra di manutenzione Doze più vicina o, se necessario, immediatamente tramite Expedited Work (Foreground Service sotto il cofano).

Foreground Service per attività critiche

Se un’attività non può essere posticipata (riproduzione multimediale, navigazione, VoIP), utilizzare un Foreground Service con una notifica obbligatoria. Un Foreground Service riceve un’esenzione da Doze: può mantenere un WakeLock ed eseguire richieste di rete. Tuttavia, anche un Foreground Service è soggetto alle policy delle finestre di manutenzione di Deep Doze per alcuni tipi di attività — ad esempio, dataSync.

FCM ad alta priorità per le notifiche

Per consegnare messaggi che richiedono attenzione immediata (chiamata in arrivo, notifica urgente), utilizzare messaggi FCM ad alta priorità. Tali messaggi riattivano il dispositivo da Doze e concedono all’app una breve finestra per l’elaborazione. Non utilizzare l’alta priorità per notifiche regolari — ciò causerà un rapido esaurimento della batteria e potrebbe essere considerato una violazione delle policy di Google Play.

• WorkManager — API preferita per tutte le attività in background posticipabili
• Foreground Service — per attività critiche con una notifica visibile
• FCM ad alta priorità — per consegnare messaggi urgenti con riattivazione del dispositivo
• Non richiedere la whitelist senza necessità critica — peggiora l’esperienza utente
• Testa l’app in Light e Deep Doze tramite ADB prima del rilascio