Su Android mobile, il supporto di più utenti consente di eseguire l'app in background (quando è attivo un altro utente) e in primo piano (noto anche come utente corrente). Per risparmiare risorse, se opportuno, il sistema gestisce l'arresto degli utenti. È sempre necessario un utente in primo piano.
A partire da Android 10, Android Automotive ha una configurazione predefinita che consente di eseguire solo un massimo di tre utenti alla volta (config_multiuserMaxRunningUsers). Pertanto, oltre all'utente di sistema headless (utente 0), è possibile configurare un solo utente in primo piano e un solo utente in background.
- In circostanze normali, l'utente corrente viene eseguito in primo piano
e l'utente di sistema senza interfaccia (utente 0) viene eseguito in background. Quando un utente viene spostato in background, viene interrotto, ma non bloccato. Quando viene raggiunto il numero massimo di utenti, l'utente in background meno utilizzato di recente viene interrotto e bloccato (
config_multiuserDelayUserDataLocking). - Gli utenti in background fermi e sbloccati vengono riavviati durante la modalità Garage.
Gli utenti ospiti sono effimeri e possono essere eseguiti solo in primo piano. Quando una persona esce dal profilo ospite, l'utente ospite viene interrotto e non può essere eseguito in background.
Processi utente in background
Quando un utente passa dal primo piano allo sfondo (e viceversa), tutte le attività e i servizi in primo piano per quell'utente vengono interrotti. In questo modo vengono interrotti tutti i servizi collegati da questi servizi. Tuttavia, rimangono alcuni aspetti da sistemare. I servizi permanenti delle app di sistema proprietarie e OEM continuano a funzionare finché l'utente (ora in background) non viene interrotto.
I servizi persistenti sono più problematici, in quanto sono contenuti in un bucket ad alta priorità nel sistema di gestione dell'esaurimento della memoria (OOM) di Android. Anche se le app per l'utente in primo piano richiedono più memoria, queste procedure in background persistenti non vengono interrotte. Di conseguenza, dal punto di vista dell'utente in primo piano, i servizi permanenti allocano in modo permanente una certa quantità di memoria, che viene restituita solo quando una persona riavvia l'auto e tutti gli utenti in background vengono arrestati.
Stato dell'utente
Un utente è in uno stato di fermata (STATE_SHUTDOWN) finché non viene avviato. Se è impostata una credenziale utente (ad esempio un PIN), l'utente Android viene eseguito, ma rimane bloccato (STATE_RUNNING_LOCKED) finché una persona non sblocca la schermata di blocco per quell'utente. Quando l'utente viene sbloccato, lo spazio di archiviazione con crittografia delle credenziali viene decriptato e le directory dei dati per l'utente diventano disponibili. Per il normale cambio utente,
l'utente in background non viene interrotto e rimane in esecuzione e sbloccato
(STATE_RUNNING_UNLOCKED), una volta sbloccato.
Modalità garage, JobScheduler e aggiornamenti delle app per gli utenti
La tecnica consigliata per le app per auto e motori per aggiornare i dati è utilizzare JobScheduler per pianificare l'esecuzione dei job quando un dispositivo è in stato inattivo, tramite la modalità Garage (ad esempio, il download degli aggiornamenti delle app da Google Play). Dopo che le app hanno registrato i job con JobScheduler e
JobSchedulerService,
i job vengono eseguiti, se possibile.
CarService invia un segnale a JobSchedulerService per attivare i job impostati per l'esecuzione quando il dispositivo Automotive è inattivo tramite la modalità Garage. Affinché JobSchedulerService esegua job per un utente in background, questo deve essere nello stato STATE_RUNNING_UNLOCKED. I job in coda
in JobSchedulerService vengono mantenuti e sopravvivono ai cicli di alimentazione.
JobScheduler non può eseguire job per un utente specifico se l'utente non è mai stato sbloccato dopo un ciclo di alimentazione. Tuttavia, quando l'utente è sbloccato e rimane in STATE_RUNNING_UNLOCKED, è possibile eseguire i job per l'utente.