Mise en veille prolongée de l'application

Un utilisateur Android moyen installe plus de 50 applications sur ses appareils (le nombre augmente à mesure que le niveau de RAM des appareils augmente). Cependant, un nombre important de ces applications restent inutilisées par l’utilisateur pendant une longue période.

La mise en veille prolongée des applications met en veille prolongée les applications que l'utilisateur n'utilise pas pendant quelques mois, de la même manière que la révocation automatique des autorisations. Cela force l'arrêt de l'application et la met dans un état dans lequel nous optimisons le stockage plutôt que les performances. La révocation automatique des autorisations est également intégrée à cet état et partage le même paramètre d'exemption dans Paramètres . Une application à l'arrêt forcé 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 veille prolongée et les tâches/alertes/notifications s'exécutent à nouveau comme d'habitude. Toutes les tâches/alertes/notifications planifiées avant que l'application ne passe en veille prolongée doivent être reprogrammées.

Les OEM modifiant la plate-forme peuvent entrer en conflit avec la mise en œuvre de la mise en veille prolongée de l'application. Par exemple

  • Modifier la définition d'utilisation de l'application ou introduire des moyens de réveiller une application qui n'est pas dans AOSP peut interrompre la précision de la mise en veille prolongée de l'application.
  • Le mécanisme de restriction propriétaire d'un OEM, similaire à la mise en veille prolongée des applications, peut remplir un objectif similaire. Même si les deux peuvent exister, il peut y avoir un certain chevauchement.

CDD décrit un nouvel ensemble d'exigences pour les changements basés sur l'utilisation de l'application, similaire à l'exigence 3.5.1 existante. L'hibernation des applications suit ces exigences.

Le code-cadre réside dans :

La logique politique réside dans :

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

Architecture de haut niveau

Le service système App Hibernation optimise le stockage des applications rarement utilisées par un utilisateur 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 :

  • Autorisations de révocation automatique
  • Forcer l'arrêt de l'application
  • Supprimez les fichiers ODEX et VDEX
  • Supprimer le cache de l'application

Notre objectif est de mettre en œuvre l'hibernation en tant qu'action réversible afin que l'application soit toujours disponible pour l'utilisateur via Launcher 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 continuerons 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 paquet doit hiberner
  • optimisation du package d'hibernation

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

La détermination du moment où un package doit mettre en veille prolongée est principalement optimisée par UsageStatsService et gérée par AppHibernationJobService dans PermissionController . Cette logique de politique réside 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 est le lieu où se produisent toutes les économies/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 depuis 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 à la fois des informations et des contrôles sur les applications qui peuvent être mises en veille prolongée.

Semblable à la révocation automatique, l'utilisateur reçoit une notification indiquant quelles applications sont en veille prolongée et a la possibilité d'accéder aux paramètres directement à partir de la notification pour soit ouvrir l'application et la sortir de l'hibernation, soit supprimer l'application inutilisée si nécessaire.

Nous continuons de soutenir l'intention du développeur de demander à l'utilisateur une exemption de la mise en veille prolongée via l'intention d'exemption de révocation automatique des autorisations existantes.

Rétrocompatibilité

Des fonctionnalités spécifiques à l'hibernation sont disponibles à partir d'Android 12. Ces fonctionnalités ne pouvaient 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 est actuellement mise en œuvre pour les versions antérieures du système d'exploitation.

À partir d'Android 12, pour garantir la compatibilité descendante, une bascule d'hibernation est ajoutée sur la page de l'application sous Applications et notifications dans Paramètres tout en conservant la bascule de révocation automatique d'origine dans le sous-menu Autorisations . Cette bascule contrôle l’exemption globale du système App Hibernation pour l’application.

Personnalisation

Étant donné qu'une partie de la mise en œuvre fait partie d'un composant système modulaire, il est déconseillé aux partenaires de modifier la fonctionnalité. Les partenaires peuvent à la place implémenter des fonctionnalités/fonctionnalités similaires à condition qu’ils respectent les exigences CDD.

La mise en veille prolongée des applications doit être activée par défaut pour toutes les applications ciblant Android 11 ou supérieur. C'est la même chose que la révocation automatique des autorisations. Bien que le paramètre lui-même puisse être activé, la mise en œuvre 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, alors qu'il s'agit essentiellement d'une révocation automatique pour les applications ciblant Android 12.

De plus, les constructeurs OEM pourraient implémenter une fonctionnalité similaire. Cependant, ces fonctionnalités sont ciblées sur une échelle de temps beaucoup plus courte pour les optimisations de batterie qui peuvent être spécifiques aux OEM. Toutes les fonctionnalités de restriction d'application similaires développées par les OEM peuvent coexister avec le système App Hibernation tant qu'elles répondent aux critères existants définis dans CDD .

Essai

L'hibernation de l'application comporte des tests CTS et unitaires pour garantir son bon fonctionnement.