Ibernazione dell'app

Un utente Android medio installa più di 50 app sui propri dispositivi (il numero aumenta man mano che aumenta il livello di RAM dei dispositivi). Tuttavia, un numero significativo di queste app non viene utilizzato dall'utente per un lungo periodo di tempo.

L'ibernazione delle app mette in ibernazione le app che l'utente non utilizza da alcuni mesi, in modo simile alla revoca automatica delle autorizzazioni. In questo modo, l'app viene arrestata forzatamente e viene impostata in uno stato in cui l'ottimizzazione è incentrata sull'archiviazione anziché sulle prestazioni. Anche la revoca automatica delle autorizzazioni è inclusa in questo stato e condivide la stessa impostazione di esenzione nelle Impostazioni. Un'app arrestata forzatamente non esegue attività o avvisi in background e non è in grado di inviare notifiche push. Quando l'utente utilizza di nuovo l'app, questa esce dalla modalità di ibernazione e le attività/gli avvisi/le notifiche vengono eseguiti di nuovo come di consueto. Tutti i job/avvisi/notifiche pianificati prima che l'app entri in sospensione devono essere ripianificati.

Gli OEM che modificano la piattaforma potrebbero entrare in conflitto con l'implementazione dell'ibernazione delle app. Ad esempio

  • La modifica della definizione di utilizzo dell'app o l'introduzione di modi per riattivare un'app che non sono in AOSP potrebbe interrompere l'accuratezza dell'ibernazione delle app.
  • Un meccanismo di limitazione proprietario dell'OEM simile all'ibernazione delle app può svolgere una funzione simile. Sebbene entrambi possano esistere, potrebbe esserci una certa sovrapposizione.

Il CDD delinea un nuovo insieme di requisiti per le modifiche basate sull'utilizzo delle app, in modo simile al requisito 3.5.1 esistente. L'ibernazione delle app segue questi requisiti.

Il codice del framework si trova in:

La logica dei criteri si trova in:

  • repo: platform/packages/modules/Permission
  • directory: PermissionController/src/com/android/permissioncontroller/hibernation

Architettura di alto livello

Il servizio di sistema di ibernazione delle app ottimizza le app utilizzate di rado da un utente per l'archiviazione e impedisce l'esecuzione in background. Per ottenere questi risultati, quando mettiamo in ibernazione un'app, in particolare:

  • Revoca automatica delle autorizzazioni
  • Forzare l'arresto dell'app
  • Eliminare i file ODEX e VDEX
  • Eliminare 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 il launcher e altre piattaforme 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 di consueto.

Il design pianificato si concentra su due parti principali:

  • Determinare quando un pacchetto deve andare in sospensione
  • Ottimizzazione del pacchetto di ibernazione

Un nuovo servizio di sistema, AppHibernationService, e un servizio di job, AppHibernationJobService,, in PermissionController è il collante che controlla la logica e il processo decisionale complessivi.

La determinazione del momento in cui un pacchetto deve andare in sospensione è principalmente basata su UsageStatsService e gestita da AppHibernationJobServicein PermissionController. La logica di questo criterio si trova in PermissionController per consentirci di eseguire aggiornamenti dinamici tramite Mainline. Inoltre, prevediamo di aggiungere un nuovo indicatore, 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 punto in cui si verificano tutti i risparmi e le 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 delle autorizzazioni viene avviata direttamente da AppHibernationJobService per mantenere la funzionalità di revoca automatica sui dispositivi Android 11 e versioni precedenti.

Esperienza utente

L'utente riceve informazioni e controlli sulle app che possono essere messe in ibernazione.

Analogamente alla revoca automatica, l'utente riceve una notifica relativa alle app inattive e ha la possibilità di andare direttamente alle Impostazioni dalla notifica per aprire l'app e riattivarla o eliminare l'app inutilizzata, se necessario.

Continuiamo a supportare l'intento dello sviluppatore di chiedere all'utente un'esenzione dall'ibernazione con l'intent di esenzione dalla revoca automatica delle autorizzazioni esistente.

Compatibilità con le versioni precedenti

Le funzionalità specifiche per l'ibernazione sono disponibili a partire da Android 12. Questa funzionalità non poteva funzionare nelle versioni precedenti perché i componenti della piattaforma (ad esempio il nuovo servizio di sistema) non sono presenti. La revoca automatica continua a funzionare come implementato per le versioni precedenti del sistema operativo.

A partire da Android 12, per garantire la compatibilità con le versioni precedenti, viene aggiunto un pulsante di attivazione/disattivazione dell'ibernazione nella pagina dell'app in App e notifiche in Impostazioni, mantenendo il pulsante di attivazione/disattivazione della revoca automatica originale nel sottomenu Autorizzazioni. Questo pulsante controlla l'esenzione complessiva dal sistema di ibernazione delle app per l'app.

Personalizzazione

Parte dell'implementazione fa parte del componente del sistema modulare, pertanto i partner sono invitati a non modificare la funzionalità. I partner possono invece implementare funzionalità simili, purché rispettino i requisiti di CDD.

L'ibernazione delle app deve essere impostata su ON per impostazione predefinita per tutte le app destinate ad Android 11 o versioni successive. È la stessa cosa della revoca automatica delle autorizzazioni. Sebbene l'impostazione possa essere ATTIVA, l'implementazione dell'ibernazione delle app può variare tra le app che hanno come target Android 11 e Android 12. Più nello specifico, l'ibernazione delle app funziona solo per le app che hanno come target Android 11, mentre per le app che hanno come target Android 12 è essenzialmente una revoca automatica.

Inoltre, gli OEM potrebbero implementare una funzionalità simile. Tuttavia, queste funzionalità sono mirate a un intervallo di tempo molto più breve per le ottimizzazioni della batteria, che possono essere specifiche per l'OEM. Qualsiasi funzionalità di limitazione delle app simili sviluppata dagli OEM può coesistere con il sistema di ibernazione delle app a condizione che soddisfi i criteri esistenti definiti nel CDD.

Test

La sospensione delle app dispone di test CTS e delle unità per garantire che funzioni correttamente.