Bucket di standby delle app

Android 9 (livello API 28) e versioni successive supportano i bucket di standby delle app. I bucket di standby delle app aiutano il sistema a dare la priorità alle richieste di risorse delle app in base alla frequenza e alla data dell'ultimo utilizzo. In base ai modelli di utilizzo delle app, ogni app viene inserita in uno dei cinque bucket di priorità. Il sistema limita le risorse del dispositivo disponibili per ogni app in base al bucket in cui si trova l'app.

Bucket di priorità

Il sistema assegna dinamicamente ogni app a un bucket di priorità, riassegnando le app in base alle esigenze. Il sistema potrebbe utilizzare un'app precaricata che utilizza il machine learning per determinare la probabilità di utilizzo di ogni app e assegnare le app ai bucket appropriati.

Se l'app di sistema non è presente su un dispositivo, il sistema utilizza come impostazione predefinita l'ordinamento delle app in base alla data dell'ultimo utilizzo. Alle app più attive vengono assegnati bucket che danno loro una priorità più alta, rendendo disponibili più risorse di sistema per l'app. In particolare, il bucket determina la frequenza di esecuzione dei job dell'app e la frequenza con cui l'app può attivare gli allarmi. Queste limitazioni si applicano solo quando il dispositivo è alimentato a batteria. Quando il dispositivo è in carica, il sistema non impone queste limitazioni.

I bucket di priorità sono i seguenti:

  • Attivo: l'app è in uso o è stata utilizzata di recente.
  • Set di lavoro: l'app viene utilizzata regolarmente.
  • Frequente: l'app viene utilizzata spesso, ma non quotidianamente.
  • Raro: l'app non viene utilizzata di frequente.
  • Con restrizioni: l'app consuma molte risorse di sistema o potrebbe mostrare un comportamento indesiderato.

Oltre a questi bucket di priorità, esiste un bucket speciale mai per le app installate ma mai eseguite. Il sistema impone severe limitazioni a queste app.

Le seguenti descrizioni si riferiscono al caso non predittivo. Al contrario, quando la previsione utilizza il machine learning per prevedere il comportamento, i bucket vengono scelti in previsione delle azioni successive dell'utente anziché in base all'utilizzo recente. Ad esempio, un'app utilizzata di recente potrebbe finire nel bucket raro perché il machine learning prevede che l'app potrebbe non essere utilizzata per diverse ore.

Attivo

Un'app si trova nel bucket attivo quando viene utilizzata, è stata utilizzata di recente o quando esegue una delle seguenti operazioni:

  • Avvia un'attività.
  • Esegue un servizio in primo piano a lunga esecuzione.
  • Viene toccata dall'utente da una notifica.

Se un'app si trova nel bucket attivo, il sistema impone limitazioni minime ai job o agli allarmi dell'app:

  • A partire da Android 16 (livello API 36), i job in background hanno una quota di runtime generosa se vengono avviati da un'app nel bucket attivo. Sono inclusi i job pianificati direttamente con JobScheduler, nonché i job creati da altre librerie come WorkManager o DownloadManager.

L'interazione utente assegna le app come attive

Su Android 9 (livello API 28) e versioni successive, quando l'utente interagisce con la tua app in determinati modi, il sistema la inserisce temporaneamente nel bucket attivo. Quando l'utente smette di interagire con la tua app, il sistema la inserisce in un bucket in base alla cronologia di utilizzo.

Di seguito sono riportati alcuni esempi di interazioni che attivano questo comportamento del sistema:

  • L'utente tocca una notifica inviata dalla tua app.

  • L'utente interagisce con un servizio in primo piano nella tua app toccando un pulsante multimediale.

  • L'utente si connette alla tua app mentre interagisce con Android Automotive OS, dove la tua app utilizza un servizio in primo piano o CONNECTION_TYPE_PROJECTION.

Set di lavoro

Un'app si trova nel bucket set di lavoro se viene eseguita spesso, ma non è attiva. Ad esempio, un'app di social media che l'utente avvia quasi ogni giorno è probabile che si trovi nel set di lavoro. Le app vengono promosse anche al bucket del set di lavoro se vengono utilizzate indirettamente.

Se un'app si trova nel set di lavoro, il sistema impone limitazioni moderate alla sua capacità di eseguire job e attivare allarmi. Per maggiori dettagli, vedi Limiti delle risorse di gestione dell'alimentazione.

Frequente

Un'app si trova nel bucket frequente se viene utilizzata regolarmente, ma non necessariamente ogni giorno. Ad esempio, un'app di monitoraggio dell'allenamento che l'utente esegue in palestra potrebbe trovarsi nel bucket frequente.

Se un'app si trova nel bucket frequente, il sistema impone limitazioni più severe alla sua capacità di eseguire job e attivare allarmi. Per maggiori dettagli, vedi Limiti delle risorse di gestione dell'alimentazione.

Raro

Un'app si trova nel bucket raro se non viene utilizzata spesso. Ad esempio, un'app per hotel che l'utente esegue solo durante il soggiorno in quell'hotel potrebbe trovarsi nel bucket raro.

Se un'app si trova nel bucket raro, il sistema impone limitazioni severe alla sua capacità di eseguire job e attivare allarmi. Il sistema limita anche la capacità dell'app di connettersi a internet. Per maggiori dettagli, vedi Limiti delle risorse di gestione dell'alimentazione.

Con restrizioni

Questo bucket, aggiunto in Android 12 (livello API 31), ha la priorità più bassa e le limitazioni più elevate di tutti i bucket. Il sistema considera il comportamento dell'app, ad esempio la frequenza con cui l'utente interagisce con essa, per decidere se inserirla nel bucket con restrizioni.

Su Android 13 (livello API 33) e versioni successive, a meno che la tua app non sia idonea per un' esenzione, il sistema la inserisce nel bucket con restrizioni nelle seguenti situazioni:

  • L'utente non interagisce con la tua app per un determinato numero di giorni. Su Android 12 (livello API 31) e 12L (livello API 32), il numero di giorni è 45. Android 13 riduce il numero di giorni a 8.

  • La tua app richiama un numero eccessivo di broadcast o binding in un periodo di 24 ore.

Se il sistema inserisce la tua app nel bucket con restrizioni, si applicano le seguenti limitazioni:

  • Puoi eseguire i job una volta al giorno in una sessione batch di 10 minuti. Durante questa sessione, il sistema raggruppa i job della tua app con quelli di altre app.
    • I job con restrizioni non vengono eseguiti autonomamente. Devono essere in esecuzione o in attesa contemporaneamente almeno un altro job, che può includere qualsiasi altro job.
  • La tua app può eseguire meno job rapidi rispetto a quando il sistema la inserisce in un bucket meno restrittivo.
  • La tua app può richiamare un allarme al giorno. Questo allarme può essere un allarme esatto o un allarme non esatto.

Esenzioni dal bucket con restrizioni

I seguenti tipi di app sono esenti dall'inserimento nel bucket con restrizioni e bypassano l'attivatore di inattività, anche su Android 12 e versioni successive:

Valutare il bucket di priorità

Per verificare a quale bucket è assegnata la tua app, effettua una delle seguenti operazioni:

  • Chiama getAppStandbyBucket().

  • Esegui il seguente comando in una finestra del terminale: 

    adb shell am get-standby-bucket PACKAGE_NAME

Il sistema limita la tua app ogni volta che viene inserita in un bucket di standby delle app il cui valore è maggiore di STANDBY_BUCKET_ACTIVE (10).

Best practice

Se la tua app segue le best practice per la modalità Doze e lo standby delle app, le funzionalità di gestione dell'alimentazione successive non sono difficili. Tuttavia, alcuni comportamenti delle app che in precedenza funzionavano bene potrebbero causare problemi.

  • Non provare a manipolare il sistema per inserire la tua app in un determinato bucket. Il metodo di assegnazione della priorità del sistema può cambiare e ogni produttore di dispositivi potrebbe scegliere di scrivere la propria app di bucketing con il proprio algoritmo. Assicurati invece che la tua app si comporti in modo appropriato indipendentemente dal bucket in cui si trova.
  • Se un'app non ha un'attività di avvio, potrebbe non essere mai promossa al bucket attivo. Valuta la possibilità di riprogettare l'app in modo che abbia un'attività di questo tipo.

  • Se gli utenti non possono interagire con le notifiche delle app, non possono attivare la promozione dell'app al bucket attivo. In questo caso, valuta la possibilità di riprogettare alcune notifiche che consentono agli utenti di interagire. Per alcune linee guida, consulta i pattern di progettazione delle notifiche di Material Design.

  • Se l'app non mostra una notifica alla ricezione di un messaggio Firebase Cloud Messaging (FCM) con priorità elevata, l'utente non può interagire con l'app e quindi promuoverla al bucket attivo. Infatti, l'unico utilizzo previsto per i messaggi FCM con priorità elevata è quello di inviare una notifica all'utente, quindi questa situazione non deve verificarsi. Su 12L (livello API 32) e versioni precedenti, se contrassegni in modo inappropriato un messaggio FCM come priorità elevata quando non attiva l'interazione dell'utente, i messaggi futuri potrebbero essere declassati.

  • Se le app sono suddivise in più pacchetti, questi pacchetti potrebbero trovarsi in bucket diversi e avere livelli di accesso diversi. Testa queste app con i pacchetti assegnati a vari bucket per assicurarti che l'app si comporti correttamente.