Un utente Android medio installa più di 50 app sui propri dispositivi (il numero aumenta all'aumentare del livello RAM dei dispositivi). Tuttavia, un numero significativo di queste app rimane inutilizzato dall'utente per un lungo periodo di tempo.
L'ibernazione delle app iberna le app che l'utente non utilizza per alcuni mesi, in modo simile alla revoca automatica delle autorizzazioni. Questo arresta forzatamente l'app e la mette in uno stato in cui ottimizziamo l'archiviazione anziché le prestazioni. Anche la revoca automatica dell'autorizzazione è inclusa in questo stato e condivide la stessa impostazione di esenzione in Impostazioni . Un'app con arresto forzato non esegue processi o avvisi in background e non è in grado di inviare notifiche push. Quando l'utente utilizza nuovamente l'app, l'app esce dalla modalità di ibernazione e i processi/avvisi/notifiche vengono eseguiti nuovamente come al solito. Eventuali processi/avvisi/notifiche pianificati prima che l'app entrasse in ibernazione devono essere riprogrammati.
Gli OEM che modificano la piattaforma potrebbero entrare in conflitto con l'implementazione dell'ibernazione dell'app. Per esempio
- La modifica della definizione di utilizzo dell'app o l'introduzione di modalità di riattivazione di un'app che non sono in AOSP potrebbero interrompere la precisione dell'ibernazione dell'app
- Il meccanismo di restrizione proprietario di un OEM simile all'ibernazione delle app può svolgere uno scopo simile. Sebbene possano esistere entrambi, potrebbero esserci delle sovrapposizioni.
CDD delinea una nuova serie di requisiti per le modifiche basate sull'utilizzo dell'app, simili al requisito 3.5.1 esistente. L'ibernazione dell'app segue questi requisiti.
Il codice quadro risiede in:
- repository: piattaforma/framework/base
- directory: services/core/java/com/android/server/apphibernation
La logica politica risiede in:
- repository: piattaforma/pacchetti/moduli/autorizzazione
- directory: PermissionController/src/com/android/permissioncontroller/hibernation
Architettura di alto livello
Il servizio di sistema Ibernazione app ottimizza l'archiviazione delle app utilizzate meno di frequente da un utente e ne impedisce l'esecuzione in background. Per ottenere questi risultati, quando ibernamo un'app, nello specifico:
- Revoca automatica delle autorizzazioni
- Forza l'arresto dell'app
- Elimina i file ODEX e VDEX
- Elimina la cache dell'app
Il nostro obiettivo è implementare l'ibernazione come azione reversibile in modo che l'app sia ancora disponibile per l'utente tramite Launcher e altre superfici con i dati dell'app intatti. All'avvio dell'app, la ripristineremo dallo stato di arresto forzato e continueremo con la creazione dei file ODEX e VDEX come al solito.
La progettazione prevista è incentrata su due parti principali:
- determinare quando un pacchetto dovrebbe ibernarsi
- ottimizzando il pacchetto di ibernazione
Un nuovo servizio di sistema, AppHibernationService , e un servizio di lavoro, AppHibernationJobService, in PermissionController costituiscono il collante che controlla il processo decisionale e la logica complessivi.
La determinazione del momento in cui un pacchetto deve essere ibernato è basata principalmente su UsageStatsService e gestita da AppHibernationJobService in PermissionController . Questa logica di policy risiede in PermissionController per consentirci l'aggiornamento dinamico tramite Mainline. Inoltre, prevediamo di aggiungere un nuovo segnale, l'utilizzo dei componenti, per acquisire l'utilizzo dei componenti del pacchetto (ad esempio, servizi, fornitori di contenuti) come nuova metrica in UsageStatsService .
L'ottimizzazione di un pacchetto è il luogo in cui si verificano tutti i risparmi/ottimizzazioni effettivi. AppHibernationService comunica con varie parti del sistema per arrestare il pacchetto, eliminare i dati della cache, eliminare gli artefatti ART e così via. La revoca dell'autorizzazione viene avviata direttamente da AppHibernationJobService per mantenere la funzionalità di revoca automatica sui dispositivi Android 11 e versioni precedenti.
Esperienza utente
All'utente vengono fornite informazioni e controlli su quali app possono essere ibernate.
Similmente alla revoca automatica, l'utente riceve una notifica su quali app sono ibernate e ha la possibilità di accedere alle Impostazioni direttamente dalla notifica per aprire l'app e farla uscire dalla modalità di ibernazione o eliminare l'app inutilizzata, se necessario.
Continuiamo a supportare l'intento dello sviluppatore di chiedere all'utente un'esenzione dall'ibernazione tramite l'intento di revoca automatica delle autorizzazioni esistenti.
Retrocompatibilità
Le funzionalità specifiche dell'ibernazione sono disponibili a partire da Android 12. Queste funzionalità non potevano funzionare nelle versioni precedenti poiché i componenti della piattaforma (come il nuovo servizio di sistema) non sono presenti. La revoca automatica continua a funzionare come attualmente implementato per le versioni precedenti del sistema operativo.
A partire da Android 12, per garantire la compatibilità con le versioni precedenti, viene aggiunto un interruttore di ibernazione nella pagina dell'app in App e notifiche in Impostazioni mantenendo l'interruttore di revoca automatica originale nel sottomenu Autorizzazioni . Questa opzione controlla l'esenzione complessiva del sistema di ibernazione dell'app per l'app.
Personalizzazione
Poiché parte dell'implementazione fa parte di componenti del sistema modulare, i partner sono scoraggiati dal modificare la funzionalità. I partner possono invece implementare caratteristiche/funzionalità simili purché rispettino i requisiti CDD.
L'ibernazione delle app dovrebbe essere attivata per impostazione predefinita per tutte le app destinate ad Android 11 o versioni successive. Equivale alla revoca automatica delle autorizzazioni. Sebbene l'impostazione stessa possa essere ATTIVA, l'implementazione dell'ibernazione dell'app potrebbe differire tra le app destinate ad Android 11 e Android 12. Più specificamente, l'ibernazione delle app funziona solo per le app destinate ad Android 11 mentre è essenzialmente solo revocata automaticamente per le app destinate ad Android 12.
Inoltre, gli OEM potrebbero implementare una funzionalità simile. Tuttavia, queste funzionalità sono mirate a un arco di tempo molto più breve per l’ottimizzazione della batteria che può essere specifica dell’OEM. Eventuali funzionalità di restrizione delle app simili sviluppate dagli OEM possono coesistere con il sistema di ibernazione delle app purché soddisfino i criteri esistenti definiti in CDD .
Test
L'ibernazione dell'app dispone di CTS e unit test per garantire che funzioni correttamente.
- Test di revoca automatica
- AppHibernationIntegrationTest