Mise en veille prolongée de l'application

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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.

L'hibernation des applications met en veille 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 place dans un état où nous optimisons le stockage plutôt que les performances. La révocation automatique des autorisations est également associée à cet état et ils partagent le même paramètre d'exemption dans Paramètres . Une application à arrêt forcé n'exécute pas de travaux ou d'alertes en arrière-plan et n'est pas en mesure d'envoyer des notifications push. Lorsque l'utilisateur utilise à nouveau l'application, l'application sort de l'hibernation et les travaux/alertes/notifications s'exécutent à nouveau comme d'habitude. Toutes les tâches/alertes/notifications planifiées avant la mise en veille prolongée de l'application doivent être reprogrammées.

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

  • La modification de la définition d'utilisation de l'application ou l'introduction de moyens de réveiller une application qui ne sont pas dans AOSP peut interrompre la précision de l'hibernation de l'application
  • Le mécanisme de restriction propriétaire d'un OEM similaire à l'hibernation d'application peut remplir un objectif similaire. Bien que les deux puissent exister, il peut y avoir un certain chevauchement.

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

Le code du framework réside dans :

La logique politique réside dans :

  • dépôt : plate-forme/paquets/modules/autorisation
  • répertoire : PermissionController/src/com/android/permissioncontroller/hibernation

Architecture de haut niveau

Le service système App Hibernation optimise les applications peu utilisées d'un utilisateur pour le stockage 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 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 des données d'application intactes. Lors du lancement de l'application, nous la restaurerons à partir de l'état d'arrêt forcé et poursuivrons la création de 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 travail, AppHibernationJobService, dans PermissionController est le ciment qui contrôle la prise de décision et la logique globales.

La détermination du moment où un package doit hiberner est principalement alimentée par UsageStatsService et gérée par AppHibernationJobService dans PermissionController . Cette logique de politique vit dans PermissionController pour nous permettre de mettre à jour dynamiquement via Mainline. En outre, 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'endroit 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 inférieurs.

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 hibernation et a la possibilité d'accéder aux paramètres directement à partir de la notification pour ouvrir l'application et la sortir de l'hibernation ou supprimer l'application inutilisée si nécessaire.

Nous continuons de soutenir l'intention du développeur de demander à l'utilisateur une exemption d'hibernation via l'intention d'exemption de révocation automatique des autorisations existantes.

Rétrocompatibilité

Les 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 telle qu'elle est actuellement mise en œuvre pour les versions antérieures du système d'exploitation.

À partir d'Android 12, pour assurer la rétrocompatibilité, 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 de système modulaire, il est déconseillé aux partenaires de modifier la fonctionnalité. Les partenaires peuvent à la place implémenter des caractéristiques/fonctionnalités similaires tant qu'ils respectent les exigences CDD.

L'hibernation 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é, l'implémentation de l'hibernation de l'application peut différer entre les applications ciblant Android 11 et Android 12. Plus précisément, l'hibernation de l'application ne fonctionne que pour les applications ciblant Android 11 alors qu'elle est essentiellement simplement révoquée automatiquement pour les applications ciblant Android 12.

De plus, les OEM peuvent 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 a des CTS et des tests unitaires pour s'assurer qu'elle fonctionne correctement.