Un usuario promedio de Android instala más de 50 apps en sus dispositivos (la cantidad aumenta a medida que aumenta el nivel de RAM de los dispositivos). Sin embargo, el usuario no usa una cantidad significativa de estas apps durante un período prolongado.
La hibernación de apps pone a hibernar las apps que el usuario no usa durante algunos meses, de manera similar a la revocación automática de permisos. Esto detiene la app de forma forzosa y la pone en un estado en el que optimizamos el almacenamiento en lugar del rendimiento. La revocación automática de permisos también se incluye en este estado y comparte la misma configuración de exención en Configuración. Una app detenida de manera forzosa no ejecuta trabajos ni alertas en segundo plano ni puede enviar notificaciones push. Cuando el usuario vuelve a usar la app, esta sale de la hibernación y las tareas, alertas y notificaciones se vuelven a ejecutar como de costumbre. Se deben reprogramar todos los trabajos, las alertas y las notificaciones que se programaron antes de que la app entrara en hibernación.
Los OEMs que modifican la plataforma pueden entrar en conflicto con la implementación de la hibernación de la app. Por ejemplo
- Modificar la definición de uso de la app o introducir formas de activar una app que no están en AOSP puede interrumpir la precisión de la hibernación de la app.
- El mecanismo de restricción propietario de un OEM similar a la hibernación de apps puede cumplir un propósito similar. Si bien ambos pueden coexistir, es posible que haya cierta superposición.
El CDD describe un nuevo conjunto de requisitos para los cambios que se basan en el uso de la app, similar al requisito existente de 3.5.1. La hibernación de apps sigue estos requisitos.
El código del framework se encuentra en:
- repo: platform/frameworks/base
- directorio: services/core/java/com/android/server/apphibernation
La lógica de la política se encuentra en lo siguiente:
- repo: platform/packages/modules/Permission
- Directorio: PermissionController/src/com/android/permissioncontroller/hibernation
Arquitectura de alto nivel
El servicio del sistema de hibernación de apps optimiza las apps que un usuario usa con poca frecuencia para el almacenamiento y evita que esas apps se ejecuten en segundo plano. Para lograr estos resultados, cuando hibernamos una app, hacemos lo siguiente de forma específica:
- Revocación automática de permisos
- Fuerza la detención de la app
- Cómo borrar los archivos ODEX y VDEX
- Cómo borrar la caché de la app
Nuestro objetivo es implementar la hibernación como una acción reversible para que la app siga disponible para el usuario a través del selector y otras plataformas con los datos de la app intactos. Cuando iniciemos la app, la restableceremos desde el estado de detención forzosa y continuaremos con la creación de archivos ODEX y VDEX como de costumbre.
El diseño planificado se centra en dos partes principales:
- Determina cuándo se debe suspender un paquete
- Cómo optimizar el paquete de hibernación
Un servicio de sistema nuevo, AppHibernationService
, y un servicio de trabajo, AppHibernationJobService,
en PermissionController
, es el elemento de unión que controla la lógica y la toma de decisiones generales.
La determinación de cuándo un paquete debe entrar en hibernación se realiza principalmente con UsageStatsService
y se administra con AppHibernationJobService
en PermissionController
. Esta lógica de políticas reside en PermissionController
para permitirnos actualizar de forma dinámica a través de Mainline. Además, planeamos agregar un indicador nuevo, el uso de componentes, para capturar el uso de los componentes del paquete (por ejemplo, servicios, proveedores de contenido) como una métrica nueva en UsageStatsService
.
La optimización de un paquete es donde se producen todos los ahorros y optimizaciones reales. AppHibernationService
se comunica con varias partes del sistema para detener el paquete, borrar datos de la caché, borrar artefactos de ART, etcétera.
La revocación de permisos se inicia directamente desde AppHibernationJobService
para conservar la función de revocación automática en dispositivos con Android 11 y versiones anteriores.
Experiencia del usuario
Se le proporciona al usuario información y controles sobre qué apps se pueden suspender.
Al igual que con la revocación automática, el usuario recibe una notificación sobre las apps que están inhabilitadas y tiene la opción de ir a Configuración directamente desde la notificación para abrir la app y sacarla de la hibernación, o bien borrar la app que no se usa si es necesario.
Seguimos admitiendo la intención del desarrollador de solicitarle al usuario una exención de la hibernación con el intent de exención de revocación automática de permisos existente.
Retrocompatibilidad
Las funciones específicas de la hibernación están disponibles a partir de Android 12. Esta función no podía funcionar en versiones anteriores, ya que no estaban presentes los componentes de la plataforma (como el nuevo servicio del sistema). La revocación automática sigue funcionando como se implementó para las versiones anteriores del SO.
A partir de Android 12, para garantizar la compatibilidad con versiones anteriores, se agrega un botón de activación de hibernación en la página de la app, en Apps y notificaciones en Configuración, y se mantiene el botón de activación de revocación automática original en el submenú Permisos. Este botón de activación controla la exención general del sistema de hibernación de apps para la app.
Personalización
Parte de la implementación forma parte del componente del sistema modular, por lo que se desaconseja a los socios que modifiquen la función. En su lugar, los socios pueden implementar características o funcionalidades similares siempre que cumplan con los requisitos del CDD.
La hibernación de apps debería estar activada de forma predeterminada para todas las apps orientadas a Android 11 o versiones posteriores. Esto es lo mismo que la revocación automática de permisos. Si bien el parámetro de configuración puede estar ACTIVADO, la implementación de la hibernación de la app puede diferir entre las apps orientadas a Android 11 y Android 12. Más específicamente, la hibernación de apps solo funciona para las apps que se orientan a Android 11, mientras que, en esencia, solo es una revocación automática para las apps que se orientan a Android 12.
Además, es posible que los OEM implementen una función similar. Sin embargo, esas funciones se orientan a un plazo mucho más corto para las optimizaciones de la batería, que pueden ser específicas de un OEM. Cualquier función de restricción de apps similar que desarrollen los OEMs puede coexistir con el sistema de hibernación de apps, siempre y cuando cumpla con los criterios existentes definidos en el CDD.
Prueba
La hibernación de apps tiene CTS y pruebas de unidades para garantizar que funcione correctamente.
AutoRevokeTest
AppHibernationIntegrationTest