Il sistema dà la priorità alle richieste di risorse delle app in base allo stato del dispositivo, allo stato dell'app e al bucket di standby dell'app.
Il sistema Android può applicare i limiti di risorse in due modi diversi. Un modo per ottimizzare l'utilizzo delle risorse è posticipare l'esecuzione del lavoro fino a quando il dispositivo non esce da uno stato di basso consumo, ad esempio la modalità di sospensione. Ad esempio, i job regolari e le sveglie imprecise vengono differiti in modo da essere eseguiti dopo che il dispositivo esce dalla modalità Sospensione.
Un altro modo è ridurre la frequenza con cui l'app può riattivare il dispositivo ed eseguire operazioni, in base al bucket di standby corrente dell'app. Il sistema può ridurre sia la frequenza (la frequenza con cui l'app riattiva il dispositivo) sia la durata totale (il tempo per cui il dispositivo rimane attivo). Ad esempio, se l'app si trova nel bucket di standby raro, può eseguire job pianificati per un periodo totale di 10 minuti in un periodo di 24 ore.
Tieni presente che WorkManager utilizza JobScheduler per pianificare le attività quando l'app non è visibile e i worker sono quindi interessati dai limiti delle risorse dei job.
Per saperne di più sulle limitazioni, leggi:
- Limiti delle risorse in base allo stato del dispositivo
- Limiti di risorse in base allo stato dell'app
- Limiti delle risorse in base al bucket di app in standby
Tieni presente che lo stato del dispositivo e lo stato dell'app possono sostituire i limiti del bucket standby app. Ad esempio, se il dispositivo è in carica, il sistema consente alle app nel bucket di standby raro di eseguire job per più di 10 minuti in un periodo di 24 ore.
Sono state apportate modifiche al comportamento che hanno influito anche sui limiti di risorse. Per saperne di più, consulta Modifiche al comportamento di Android che influiscono sui limiti delle risorse.
Limiti di risorse in base allo stato del dispositivo
Il sistema può anche esentare o applicare limiti di risorse in base allo stato del dispositivo. Ad esempio, a un dispositivo in stato di ricarica viene concesso l'accesso alle risorse senza restrizioni, indipendentemente dal bucket di standby dell'app.
Stato del dispositivo |
Lavori |
Sveglie |
Accesso alla rete |
Firebase Cloud Messaging |
In carica |
Nessun limite di esecuzione, tranne per il bucket standby con restrizioni |
Nessun limite di esecuzione per tutti i bucket in standby e gli stati dei processi, tranne se l'utente limita manualmente il consumo della batteria delle app |
Nessuna restrizione |
Nessuna restrizione |
Schermo acceso |
I limiti di esecuzione vengono applicati in base al bucket di standby |
I limiti di esecuzione vengono applicati in base al processo dell'app e al bucket di standby |
L'accesso dipende dallo stato del bucket in standby o del processo dell'app |
Nessuna restrizione |
Lo schermo è spento e la modalità Sospensione è attiva |
I limiti di esecuzione vengono applicati in base al bucket in standby e l'esecuzione viene posticipata alla finestra di manutenzione in modalità sospensione |
I limiti di esecuzione vengono applicati in base al bucket di standby. Sveglie regolari: posticipata al periodo di manutenzione della modalità Sospensione Sveglia in caso di inattività: massimo 7 all'ora |
Con restrizioni durante la sospensione |
Priorità elevata: nessun limite di esecuzione Priorità normale: posticipata al periodo di manutenzione di Sospensione |
Limiti di risorse in base allo stato dell'app
L'applicazione o meno dei limiti di risorse del bucket in standby dell'app dipende dall'importanza del processo dell'app. Consulta
ActivityManager.RunningAppProcessInfo.importance
per comprendere i diversi livelli di importanza del processo.
L'utente del dispositivo può anche scegliere di sostituire manualmente le ottimizzazioni di gestione dell'alimentazione delle app, che sostituiscono i limiti del bucket di standby delle app.
Stato dell'app |
Lavori |
Sveglie |
Rete |
Il processo dell'app è visibile o in stato di primo piano |
Nessun limite di esecuzione |
Nessun limite di frequenza |
Nessuna restrizione |
Il processo dell'app sta eseguendo un servizio in primo piano |
I limiti di esecuzione vengono applicati in base al bucket di standby*** |
I limiti di frequenza vengono applicati in base al bucket di standby |
Nessuna restrizione |
L'utente limita manualmente il consumo della batteria da parte delle app |
L'esecuzione è limitata |
L'esecuzione è limitata |
L'accesso dipende dal comportamento del bucket in standby |
L'utente annulla manualmente la limitazione della batteria per le app |
Il limite di esecuzione è generoso*** |
Nessun limite di esecuzione |
Senza restrizioni, a meno che il dispositivo non sia in modalità Risparmio dati |
*** Il comportamento della quota di esecuzione per i job è cambiato in Android 16. Prima di Android 16 non esisteva un limite di esecuzione quando l'app eseguiva un servizio in primo piano o l'utente non limitava l'utilizzo della batteria dell'app.
Limiti di risorse in base al bucket di app in standby
Nota: i valori in questa tabella non garantiscono le durate di esecuzione, poiché altre condizioni del dispositivo o modifiche ai bucket possono influire sui vincoli delle risorse. Inoltre, i valori sono soggetti a modifiche nelle future release di Android.
I job regolari, i job accelerati, gli avvisi e l'accesso alla rete possono essere limitati in base al bucket di app in standby. Scopri in che modo i bucket di standby dell'app influiscono sulla tua app utilizzando come linee guida queste limitazioni approssimative per la gestione dell'alimentazione. Per prestazioni ottimali, segui le best practice per lo stato inattivo delle app e ottimizza l'utilizzo della batteria per le API di pianificazione delle attività.
Tieni presente che, a partire da Android 13, il bucket in standby dell'app non determina più il numero di FCM ad alta priorità che un'app può utilizzare.
Bucket di standby delle app |
Lavori regolari* |
Job rapidi** |
Sveglie |
Rete |
Attivi: |
Fino a 20 minuti in un periodo di 60 minuti*** |
Fino a 30 minuti in un periodo di 24 ore*** |
Nessun limite di esecuzione |
Nessuna restrizione |
Set di lavoro: |
Fino a 10 minuti in un periodo di 4 ore |
Fino a 15 minuti in un periodo mobile di 24 ore |
Limite di 10 all'ora |
Nessuna restrizione |
Frequenti: |
Fino a 10 minuti in un periodo di 12 ore |
Fino a 10 minuti in un periodo di 24 ore |
Limite di 2 all'ora |
Nessuna restrizione |
Raro: |
Fino a 10 minuti in un periodo di 24 ore |
Fino a 10 minuti in un periodo di 24 ore |
Limite di 1 ogni ora |
Disattivata |
Con restrizioni: |
Una volta al giorno per un massimo di 10 minuti |
Fino a 5 minuti in un periodo di 24 ore |
Una sveglia al giorno, che può essere esatta o approssimativa |
Disattivata |
* I job normali descrivono i job che non utilizzano i flag setUserInitiated(true) o setExpedited(true) in JobScheduler o i worker accelerati in WorkManager.
** I job con priorità elevata hanno un limite di esecuzione distinto rispetto ai job normali. Possono essere configurati in WorkManager per continuare a essere eseguiti utilizzando i limiti di esecuzione dei job normali una volta esaurite le priorità elevate.
*** Il comportamento della quota di esecuzione per i job è cambiato in Android 16. Prima di Android 16 non esisteva un limite di esecuzione quando l'app si trovava nel bucket standby attivo.
Modifiche al comportamento di Android che influiscono sui limiti di risorse
I seguenti aggiornamenti di Android hanno apportato modifiche ai limiti delle risorse delle app.
Android 16
Modifica del comportamento delle ottimizzazioni delle quote di JobScheduler
Android ha modificato la quota di runtime per l'esecuzione di job regolari ed eseguiti in modo rapido in base ai seguenti fattori:
- Il bucket di app in standby in cui si trova l'app
- Se il job inizia l'esecuzione mentre l'app è in uno stato superiore
- Se il job è in esecuzione durante l'esecuzione di un servizio in primo piano
Android 13
Modifica del comportamento delle quote di Firebase Cloud Messaging (FCM) con priorità elevata
- I bucket di app in standby non determinano più quanti FCM ad alta priorità può utilizzare un'app.
- Ora il sistema esegue il downgrade dei messaggi con priorità elevata se rileva un'app che invia costantemente messaggi con priorità elevata che non generano una notifica
- Per le linee guida attuali sui messaggi con priorità elevata, consulta la documentazione di firebase su come impostare e gestire la priorità dei messaggi.
Android 9
È stata introdotta la funzionalità dei bucket di standby delle app
Android 9 introduce una nuova funzionalità di gestione della batteria, i bucket di app in standby. I bucket standby delle app aiutano il sistema a dare la priorità alle richieste di risorse delle app in base alla frequenza e alla data dell'utilizzo delle app. 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.