App Standby — cos’è, livelli di attesa e principio di funzionamento

Cos'è App Standby

App Standby è un componente del sistema di gestione energetica di Android, introdotto in Android 6.0 (API 23) e significativamente rielaborato in Android 9 (API 28). Il suo compito è identificare quali app l'utente usa raramente e limitarne l'attività in background: richieste di rete, sincronizzazione, JobScheduler e AlarmManager. A differenza di Doze, App Standby non dipende dallo stato dello schermo o dal movimento del dispositivo.

Il sistema classifica le app in quattro bucket (livelli): Active, Working Set, Frequent e Rare. Ogni livello determina quanto fortemente l'attività in background viene limitata. Le transizioni tra i livelli avvengono automaticamente in base ai modelli di utilizzo dell'app: quanto spesso l'utente la apre, riceve notifiche, interagisce con i widget.

App Standby lavora insieme a Doze Mode ma non lo sostituisce. Mentre Doze limita l'attività in background di tutte le app quando il dispositivo è inattivo, App Standby limita app specifiche indipendentemente dallo stato del dispositivo. Un'app al livello Rare subirà restrizioni anche quando il telefono viene usato attivamente, se l'utente non l'ha aperta per diversi giorni.

Bucket in Android 9+

A partire da Android 9 (API 28), Google ha introdotto App Standby Buckets — una classificazione formale con valori numerici. Il sistema utilizza l'apprendimento automatico per prevedere il prossimo avvio dell'app. Se il modello prevede che l'app verrà aperta nelle prossime ore, riceve un bucket Active. Se la previsione indica un uso raro — viene assegnato Rare.

Come funziona App Standby

App Standby analizza diversi fattori per determinare il bucket: tempo dall'ultima apertura dell'app da parte dell'utente, frequenza di interazione (numero di avvii al giorno/settimana), ricezione di notifiche FCM, presenza di widget attivi sulla schermata home e sottoscrizione ad AlarmManager. Più a lungo un'app rimane inutilizzata, più il suo bucket si abbassa e più severe sono le restrizioni.

Il servizio di sistema UsageStatsManager raccoglie le statistiche di utilizzo delle app e le passa a StandbyController — un componente del framework che calcola il bucket per ogni app. StandbyController tiene conto anche degli eventi di sistema: dopo un aggiornamento dell'app, il suo bucket viene resettato ad Active per alcuni giorni in modo che l'utente possa valutare le nuove funzionalità.

Una caratteristica importante: App Standby non uccide il processo dell'app, ma limita le sue capacità in background. L'app continua a funzionare se l'utente interagisce con essa (bucket Active). Non appena l'utente minimizza l'app e non vi ritorna, il sistema inizia a contare il tempo di inattività e può abbassare il bucket a Working Set o Frequent.

Impatto di FCM sul bucket

Ricevere un messaggio FCM ad alta priorità può aumentare temporaneamente il bucket dell'app ad Active. Questo dà all'app l'opportunità di eseguire un'attività (elaborare il messaggio, sincronizzare i dati) senza restrizioni. Tuttavia, dopo il completamento dell'elaborazione, il bucket torna al suo valore originale. Google raccomanda di utilizzare questo meccanismo per la consegna di notifiche importanti, non per mantenere l'app in vita.

Livelli di App Standby

App Standby utilizza quattro livelli (bucket) per classificare le app. Ogni livello determina il tempo di ritardo per le attività in background: più il livello è basso, più lungo è il ritardo. Il sistema sposta automaticamente l'app tra i livelli in base alle statistiche di utilizzo raccolte negli ultimi 7–14 giorni.

Active — App attiva

Active — un'app con cui l'utente ha interagito recentemente (avviata, ricevuto una notifica o usato un widget). In questo bucket non ci sono restrizioni: JobScheduler viene eseguito immediatamente, la rete è disponibile, AlarmManager scatta con precisione. L'app rimane in Active finché l'utente non smette di interagire con essa per diverse ore.

Working Set e Frequent

Working Set — l'app viene usata regolarmente (diverse volte a settimana). Ritardo delle attività in background fino a 2 ore. Frequent — l'app viene usata diverse volte al mese. Ritardo fino a 4 ore. In entrambi i livelli, la rete è disponibile solo nelle finestre di manutenzione e AlarmManager può essere differito. JobScheduler esegue le attività nella finestra più vicina.

Rare — Usata raramente

Rare — il livello più severo, assegnato alle app che l'utente non ha aperto per più di 30 giorni. Il ritardo delle attività in background raggiunge le 24 ore. La rete è completamente bloccata al di fuori delle finestre di manutenzione, AlarmManager scatta solo con i flag setAndAllowWhileIdle() con un limite di 1 volta ogni 9 minuti. Le notifiche FCM ad alta priorità vengono ancora consegnate ma non possono aumentare il bucket.

Restrizioni in App Standby

App Standby impone restrizioni su diverse categorie di operazioni in background. A differenza di Doze, le restrizioni di App Standby si applicano indipendentemente dallo stato dello schermo e dalla carica. Lo sviluppatore deve progettare l'app tenendo conto di queste restrizioni, specialmente se il pubblico di destinazione usa l'app in modo irregolare.

JobScheduler e WorkManager

JobScheduler — l'API principale influenzata da App Standby. A seconda del bucket, il ritardo nell'esecuzione delle attività varia da 2 a 24 ore. WorkManager, che utilizza JobScheduler internamente (su API 23+), è anch'esso soggetto a questi ritardi. Per le attività critiche in termini di tempo, utilizza Expedited Work, che avvia un Foreground Service internamente e non viene influenzato dal bucket.

Restrizioni di rete

Le app nei bucket Working Set, Frequent e Rare non possono effettuare richieste di rete arbitrarie in qualsiasi momento. Il sistema consente l'accesso alla rete solo durante le finestre di manutenzione, sincronizzate con Doze. Per inviare dati critici, utilizza FCM ad alta priorità con successiva sincronizzazione nella finestra di manutenzione.

AlarmManager

AlarmManager in App Standby segue le stesse regole di Doze: gli allarmi esatti (setExact()) vengono differiti e setAndAllowWhileIdle() è limitato a 1 attivazione ogni 9 minuti. Per il bucket Rare, il ritardo può raggiungere le 24 ore, rendendo AlarmManager inadatto per la pianificazione precisa di attività in app usate raramente.

• JobScheduler — le attività vengono differite per 2–24 ore a seconda del bucket
• Rete — accesso solo nelle finestre di manutenzione per Working Set e inferiori
• AlarmManager — allarmi esatti differiti; setAndAllowWhileIdle — 1/9 min
• SyncManager — la sincronizzazione degli account viene ritardata fino alla finestra di manutenzione
• Widget updates — la frequenza di aggiornamento dei widget può essere ridotta

Come ottenere un'esenzione

Un'esenzione da App Standby può essere ottenuta in due modi: attraverso le impostazioni della batteria dell'utente (Whitelist manuale) o tramite l'Intent di sistema ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Tuttavia, Google regola rigorosamente l'accesso alle esenzioni — le app senza un valido motivo rischiano il rifiuto su Google Play.

L'utente può disabilitare manualmente le restrizioni per un'app specifica tramite Impostazioni → App → [App] → Batteria → Ottimizzazione → Non ottimizzare. Questo rimuove completamente le restrizioni di App Standby e Doze per l'app selezionata. Lo sviluppatore può mostrare istruzioni o un dialogo di sistema all'utente, ma non può forzare l'aggiunta di un'app alle esenzioni.

Foreground Service con una notifica ottiene automaticamente un'esenzione temporanea da App Standby. Mentre il servizio è in esecuzione e mostra una notifica, l'app viene spostata nel bucket Active indipendentemente dal suo livello effettivo. Dopo l'arresto del servizio, il bucket torna al suo valore originale. Questo è il modo più affidabile per garantire il lavoro in background senza richiedere esenzioni di sistema.

Quando richiedere un'esenzione

Richiedere una Whitelist ha senso solo per app con funzionalità critiche in background: navigazione in tempo reale, monitoraggio sanitario, chiamate VoIP, protezione del dispositivo. Per la maggior parte delle app, è sufficiente utilizzare Foreground Service o WorkManager. Google Play può rifiutare la pubblicazione se l'app richiede un'esenzione senza una necessità evidente.

// Richiedere esenzione da App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Verificare lo stato corrente
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testare App Standby

Testare App Standby tramite ADB consente di assegnare forzatamente qualsiasi bucket a un'app e verificarne il comportamento. Questo è criticamente importante per le app che si affidano alla sincronizzazione in background, alle notifiche o agli aggiornamenti periodici. Il test deve essere eseguito su un dispositivo fisico o emulatore con Android 9+.

Per impostare forzatamente un bucket, usa il comando adb shell am set-standby-bucket [package] [bucket], dove bucket può essere: active, working_set, frequent o rare. Per visualizzare il bucket corrente — adb shell am get-standby-bucket [package]. Il sistema consente anche di simulare l'inattività prolungata dell'app tramite il comando adb shell dumpsys usagestats.

# Impostare bucket Rare per l’app
$ adb shell am set-standby-bucket com.example.app rare

# Visualizzare bucket corrente
$ adb shell am get-standby-bucket com.example.app

# Reimpostare tutti i bucket ad Active
$ adb shell dumpsys usagestats clear

# Visualizzare tutti i bucket di sistema
$ adb shell dumpsys usagestats

Cosa verificare

Dopo aver impostato il bucket su Rare, verifica: se l'attività di WorkManager viene eseguita entro 24 ore, se AlarmManager scatta, se le notifiche FCM vengono consegnate e se Foreground Service funziona senza restrizioni. WorkManager con politica Expedited Work dovrebbe essere eseguito immediatamente anche nel bucket Rare, poiché utilizza Foreground Service. Le attività WorkManager regolari verranno differite in base al bucket.

Migliori pratiche

Sviluppare un'app resiliente a App Standby richiede un approccio consapevole alle attività in background. Il principio principale: non presumere che l'app sia sempre nel bucket Active. Progetta il lavoro in background in modo che venga eseguito correttamente con i ritardi caratteristici dei bucket Frequent e Rare.

Usa WorkManager con Expedited Work

Expedited Work (WorkManager 2.7+) avvia un Foreground Service internamente, dando all'attività un'esecuzione immediata indipendentemente dal bucket. Questa è la scelta ottimale per le attività che non possono essere differite: invio di un messaggio, sincronizzazione dopo un pagamento, elaborazione di una chiamata in arrivo. Le attività WorkManager regolari vengono eseguite nelle finestre di manutenzione in base al bucket.

FCM per la riattivazione

Usa messaggi FCM ad alta priorità per risvegliare un'app da App Standby. Quando l'app riceve tale messaggio, il suo bucket viene temporaneamente elevato ad Active, consentendole di eseguire le attività necessarie (sincronizzazione, aggiornamento dati). Dopo il completamento dell'elaborazione, il bucket torna al suo livello originale.

Evita la permanenza costante in memoria

Non tentare di bypassare App Standby con servizi in background persistenti, WakeLock o messaggi FCM periodici. Google combatte attivamente tali pratiche — l'app può essere etichettata come dispendiosa e limitata ancora più severamente. Usa WorkManager per le attività periodiche e Foreground Service solo quando l'attività è effettivamente visibile all'utente.

• WorkManager — API preferita; Expedited Work esegue le attività senza ritardo
• FCM ad alta priorità — aumenta temporaneamente il bucket ad Active per l'elaborazione del messaggio
• Non bypassare App Standby — questo porta al blocco dell'app da parte del sistema
• Foreground Service — sposta temporaneamente l'app in Active durante l'esecuzione
• Testa l'app nei bucket Rare e Frequent tramite ADB prima di ogni rilascio