Hibernation des applications

Un utilisateur Android moyen installe plus de 50 applications sur ses appareils (le nombre augmente à mesure que la quantité de RAM des appareils augmente). Cependant, un grand nombre de ces applications ne sont pas utilisées par l'utilisateur pendant une longue période.

La mise en veille des applications permet de mettre en veille les applications que l'utilisateur n'utilise pas pendant quelques mois, comme pour la révocation automatique des autorisations. Cela force l'arrêt de l'application et la met dans un état où nous optimisons pour le stockage plutôt que pour les performances. La révocation automatique des autorisations est également associée à cet état et partage le même paramètre d'exception dans Paramètres. Une application arrêtée de force n'exécute pas de tâches ni d'alertes en arrière-plan et ne peut pas envoyer de notifications push. Lorsque l'utilisateur utilise à nouveau l'application, celle-ci quitte l'hibernation et les tâches/alertes/notifications s'exécutent à nouveau comme d'habitude. Toutes les tâches/alertes/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 l'hibernation des applications. Par exemple

  • Modifier la définition de l'utilisation de l'application ou introduire des méthodes de réveil d'une application qui ne figurent pas dans AOSP peut interrompre la précision de l'hibernation de l'application.
  • Un mécanisme de restriction propriétaire d'un OEM semblable à l'hibernation d'application peut remplir un objectif similaire. Bien que les deux puissent coexister, il est possible qu'il y ait un chevauchement.

Le CDD définit un nouvel ensemble d'exigences pour les modifications basées sur l'utilisation de l'application, semblable à l'exigence 3.5.1 existante. L'hibernation des applications suit ces exigences.

Le code du framework se trouve dans:

La logique de la stratégie réside dans:

  • dépôt: platform/packages/modules/Permission
  • répertoire: PermissionController/src/com/android/permissioncontroller/hibernation

Architecture de haut niveau

Le service système d'hibernation des applications optimise le stockage des applications peu utilisées par un utilisateur et empêche leur exécution en arrière-plan. Pour obtenir ces résultats, lorsque nous mettons une application en veille, nous procédons comme suit:

  • 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 l'hibernation en tant qu'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. Lors du lancement de l'application, nous la restaurerons à l'état d'arrêt forcé et poursuivrons la création des fichiers ODEX et VDEX comme d'habitude.

La conception prévue se concentre sur deux parties principales:

  • Déterminer quand un paquet doit hiberner
  • Optimiser le package d'hibernation

Un nouveau service système, AppHibernationService, et un service de tâche, AppHibernationJobService,, dans PermissionController sont le lien qui contrôle la prise de décision et la logique globales.

La détermination du moment où un package doit hiberner est principalement assurée par UsageStatsService et gérée par AppHibernationJobService dans PermissionController. Cette logique de stratégie se trouve dans PermissionController pour nous permettre de 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 permet de réaliser toutes les économies et optimisations effectives. AppHibernationService communique avec différentes parties du système pour arrêter le package, supprimer les données de cache, supprimer les artefacts ART, etc. La révocation d'autorisation est lancée directement à 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 dispose d'informations et de commandes sur les applications pouvant être mises en veille.

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

Nous continuons à prendre en charge l'intention du développeur de demander à l'utilisateur une exemption de l'hibernation avec l'intent d'exemption d'annulation automatique des autorisations existantes.

Rétrocompatibilité.

Les fonctionnalités spécifiques à l'hibernation sont disponibles à partir d'Android 12. Cette fonctionnalité ne pouvait 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 implémenté dans les versions antérieures de l'OS.

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

Personnalisation

Une partie de l'implémentation fait partie du composant système modulaire. Il est donc déconseillé aux partenaires de modifier cette fonctionnalité. Les partenaires peuvent plutôt implémenter des fonctionnalités similaires, à condition de respecter les exigences du CDD.

L'hibernation des applications doit être activée par défaut pour toutes les applications ciblant Android 11 ou version ultérieure. Cela s'apparente à la révocation automatique des autorisations. Bien que le paramètre soit activé, l'implémentation de l'hibernation des applications peut différer entre les applications ciblant Android 11 et Android 12. Plus précisément, l'hibernation des applications ne fonctionne que pour les applications ciblant Android 11, tandis qu'elle ne s'applique qu'à la révocation automatique pour les applications ciblant Android 12.

De plus, les OEM peuvent mettre en œuvre une fonctionnalité similaire. Toutefois, ces fonctionnalités sont ciblées sur une période 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 d'hibernation des applications, à condition qu'elles répondent aux critères existants définis dans la CDD.

Tests

L'hibernation d'application est soumise à des tests CTS et unitaires pour s'assurer qu'elle fonctionne correctement.