Hibernation des applications

Un utilisateur Android moyen installe plus de 50 applications sur ses appareils (ce nombre augmente avec le niveau de RAM des appareils). Toutefois, un nombre important de ces applications ne sont pas utilisées par l'utilisateur pendant une longue période.

L'hibernation d'applications met en hibernation les applications que l'utilisateur n'utilise pas pendant quelques mois, comme la révocation automatique des autorisations. Cela force l'arrêt de l'application et la met dans un état où nous optimisons le stockage plutôt que les performances. L'annulation automatique des autorisations est également associée à cet état et partage le même paramètre d'exemption dans les Paramètres. Une application dont l'arrêt forcé a été effectué n'exécute pas de tâches ni d'alertes en arrière-plan, et n'est pas en mesure d'envoyer des notifications push. Lorsque l'utilisateur utilise à nouveau l'application, celle-ci quitte le mode hibernation et les tâches, alertes et notifications s'exécutent à nouveau comme d'habitude. Toutes les tâches, alertes et notifications planifiées avant le passage en hibernation de l'application doivent être reprogrammées.

Les OEM qui modifient la plate-forme peuvent entrer en conflit avec l'implémentation de la mise en veille prolongée des applications. Par exemple

  • Si vous modifiez la définition de l'utilisation des applications ou si vous introduisez des méthodes de réveil d'une application qui ne sont pas dans AOSP, vous risquez d'interrompre la précision de la mise en veille des applications.
  • Un mécanisme de restriction propriétaire d'OEM semblable à la mise en veille des applications peut avoir un objectif similaire. Bien que les deux puissent exister, il peut y avoir un certain chevauchement.

Le CDD décrit un nouvel ensemble d'exigences pour les modifications basées sur l'utilisation des applications, semblables à l'exigence 3.5.1 existante. L'hibernation des applications est soumise aux exigences suivantes.

Le code du framework se trouve dans :

La logique des règles se trouve dans :

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

Architecture de haut niveau

Le service système de mise en veille des applications optimise le stockage des applications qu'un utilisateur utilise rarement et empêche ces applications de s'exécuter en arrière-plan. Pour obtenir ces résultats, lorsque nous mettons une application en veille prolongée, nous :

  • Révoquer automatiquement les autorisations
  • Forcer l'arrêt de l'application
  • Supprimer les fichiers ODEX et VDEX
  • Supprimer le cache de l'application

Notre objectif est d'implémenter la mise en veille prolongée comme une action réversible afin que l'application reste disponible pour l'utilisateur via le lanceur d'applications et d'autres surfaces, avec les données de l'application intactes. Au lancement de l'application, nous la restaurerons à partir de l'état d'arrêt forcé et poursuivrons la création des fichiers ODEX et VDEX comme d'habitude.

La conception prévue s'articule autour de deux parties principales :

  • Déterminer quand un package doit être mis en veille prolongée
  • Optimiser le package en veille prolongée

Un nouveau service système, AppHibernationService, et un service de job, AppHibernationJobService, dans PermissionController, sont les éléments qui contrôlent la logique et la prise de décision globale.

La détermination du moment où un package doit hiberner est principalement gérée par UsageStatsService et AppHibernationJobService dans PermissionController. La logique de cette règle se trouve dans PermissionController pour nous permettre de la mettre à jour dynamiquement via Mainline. De plus, nous prévoyons d'ajouter un nouveau signal, l'utilisation des composants, pour capturer l'utilisation des composants du package (par exemple, les services, les fournisseurs de contenu) en tant que nouvelle métrique dans UsageStatsService.

L'optimisation d'un package est l'étape où se produisent les économies et les optimisations réelles. AppHibernationService communique avec différentes parties du système pour arrêter le package, supprimer les données du cache, supprimer les artefacts ART, etc. La révocation des autorisations est directement initiée à partir de AppHibernationJobService pour conserver la fonctionnalité de révocation automatique sur les appareils Android 11 et versions antérieures.

Expérience utilisateur

L'utilisateur reçoit des informations et des commandes sur les applications qui peuvent être mises en veille prolongée.

Comme pour la révocation automatique, l'utilisateur reçoit une notification indiquant les applications mises en veille prolongée. Il peut accéder directement aux paramètres depuis la notification pour ouvrir l'application et la sortir de la veille prolongée, ou supprimer l'application inutilisée si nécessaire.

Nous continuons de prendre en charge l'intention du développeur de demander à l'utilisateur une exemption de mise en veille prolongée avec l'intention d'exemption de révocation automatique des autorisations existante.

Rétrocompatibilité.

Les fonctionnalités spécifiques à l'hibernation sont disponibles à partir d'Android 12. Cette fonctionnalité ne peut pas fonctionner sur les versions antérieures, car les composants de la plate-forme (tels que le nouveau service système) ne sont pas présents. La révocation automatique continue de fonctionner comme elle le faisait pour les versions antérieures de l'OS.

À partir d'Android 12, pour assurer la rétrocompatibilité, un bouton d'activation/désactivation de la mise en veille prolongée est ajouté sur la page de l'application sous Applications et notifications dans Paramètres, tout en conservant le bouton d'activation/désactivation de la révocation automatique d'origine dans le sous-menu Autorisations. Ce bouton bascule contrôle l'exemption globale du système d'hibernation des applications pour l'application.

Personnalisation

Une partie de l'implémentation fait partie du composant du système modulaire. Les partenaires sont donc invités à ne pas modifier la fonctionnalité. Les partenaires peuvent plutôt implémenter des fonctionnalités similaires à condition de respecter les exigences du CDD.

La mise en veille des applications doit être activée par défaut pour toutes les applications ciblant Android 11 ou version ultérieure. Cela équivaut à la révocation automatique des autorisations. Même si le paramètre est activé, l'implémentation de la mise en veille des applications peut différer entre les applications ciblant Android 11 et celles ciblant Android 12. Plus précisément, la mise en veille des applications ne fonctionne que pour les applications ciblant Android 11, tandis qu'il s'agit essentiellement d'une révocation automatique pour les applications ciblant Android 12.

De plus, les OEM peuvent implémenter une fonctionnalité similaire. Toutefois, ces fonctionnalités sont ciblées sur une échelle de temps beaucoup plus courte pour les optimisations de la batterie, qui peuvent être spécifiques à l'OEM. Toutes les fonctionnalités de restriction d'applications similaires développées par les OEM peuvent coexister avec le système de mise en veille des applications, à condition qu'elles répondent aux critères existants définis dans le CDD.

Tests

L'hibernation des applications dispose de tests CTS et unitaires pour s'assurer qu'elle fonctionne correctement.