La suppression automatique des tâches se produit-elle dans les versions modernes d’Android?

Selon la documentation Android, le système effacera une tâche (terminer toutes les activités au-dessus de celle qui a lancé la tâche) qu’il considère avoir été abandonnée par l’utilisateur:

https://developer.android.com/guide/components/tasks-and-back-stack.html#Clearing

Si l’utilisateur quitte une tâche pendant une période prolongée, le système efface la tâche de toutes les activités, à l’exception de l’activité racine. Lorsque l’utilisateur revient à la tâche, seule l’activité racine est restaurée. Le système se comporte de cette façon, car, après une longue période de temps, les utilisateurs ont probablement abandonné ce qu’ils étaient en train de faire et retournent à la tâche pour commencer quelque chose de nouveau.

https://developer.android.com/guide/topics/manifest/activity-element.html#always

Normalement, le système efface une tâche (supprime toutes les activités de la stack au-dessus de l’activité racine) dans certaines situations lorsque l’utilisateur sélectionne à nouveau cette tâche à partir de l’écran d’accueil. En règle générale, cela se produit si l’utilisateur n’a pas visité la tâche pendant un certain temps, par exemple 30 minutes.

Ce comportement peut être facilement reproduit sur les périphériques exécutant Gingerbread et versions antérieures. Lancez une application et créez un historique, puis appuyez sur le bouton d’accueil et attendez une demi-heure. Lancez à nouveau l’application depuis l’écran d’accueil et l’état a été effacé comme s’il commençait une nouvelle tâche. Parfait.

Cependant, sur les périphériques exécutant ICS et les versions ultérieures, il semble impossible de reproduire ce comportement, même après une inactivité après plusieurs heures ou jours. Lorsqu’une application est relancée depuis l’écran d’accueil, la tâche est toujours dans l’état où je l’ai laissée.

En supposant que la documentation est correcte, dans quelles conditions les versions modernes d’Android (API 14+) effaceront-elles automatiquement une tâche?

Si le comportement a changé et que la documentation est obsolète, à quoi sert l’atsortingbut alwaysRetainTaskState pour ? La valeur par défaut est-elle passée à "true" ou cet atsortingbut est-il maintenant obsolète?

Remarque: je ne parle pas ici de la gestion du cycle de vie des processus Android, qui dépendra des ressources de l’appareil. Tuer un processus doit de toute façon être transparent pour l’utilisateur et n’affecte pas l’état de la tâche.

Bonne question, après un peu de plongée de source, la réponse m’a certainement surpris!

Un rapide coup d’œil aux sources Android semble fournir la réponse. Commençons par revenir sur Android 2.2 à ActivityManagerService.java . Remarquez autour de la ligne 186 une constante définie par ACTIVITY_INACTIVE_RESET_TIME qui est définie sur 30 minutes.

 // How long until we reset a task when the user returns to it. Currently // 30 minutes. static final long ACTIVITY_INACTIVE_RESET_TIME = 1000*60*30; 

Regardez un peu plus loin la méthode resetTaskIfNeededLocked() autour de la ligne 7021 et vous verrez cette valeur cochée pour déterminer si la tâche doit être réinitialisée avant d’être lancée.

Avance rapide vers les sources Android 4.3 et le code a été déplacé dans ActivityStack.java qui est appelé par ActivityManagerService, mais la structure de base est la même. Cette fois, la constante est définie autour de la ligne 125:

 // How long until we reset a task when the user returns to it. Currently // disabled. static final long ACTIVITY_INACTIVE_RESET_TIME = 0; 

La même méthode resetTaskIfNeededLocked() se trouve autour de la ligne 1973 et vous pouvez voir qu’elle vérifie maintenant si la valeur est supérieure à zéro avant d’appliquer le même contrôle de délai d’attente pour effacer l’état de la tâche. Notez, cependant, que cette méthode vérifie toujours FLAG_ALWAYS_RETAIN_TASK_STATE , donc cet indicateur peut toujours être utilisé pour protéger un état clair, mais il semble qu’avec la vérification externe désactivée, ce code ne sera jamais exécuté.

Dans l’ensemble, cela semble une preuve assez convaincante que la fonctionnalité a été désactivée dans AOSP pour les versions ultérieures d’Android. Je ne vois aucun moyen externe (via les propriétés du système, etc.) pour que cette valeur soit réactivée par périphérique à moins que le fabricant ne reconstruise le code avec une valeur ajoutée ici … mais cela est rare. La plupart des ODM adhèrent aux propriétés de configuration dans XML ou aux propriétés système qu’ils peuvent contrôler via une superposition.

Donc, bien que techniquement la fonctionnalité n’ait pas été “supprimée”, il me semble que la documentation n’est plus correcte en termes de déclenchement automatique après un délai.