Eh bien, cela a confirmé mon hypothèse selon laquelle "si personne sur stackexchange ne connaît la réponse, vous allez devoir la trouver vous-même".
C'est ce que j'ai fait.
La réponse à cette question est double. Il y a le gestionnaire de fenêtres et le gestionnaire d'activités, et tous deux jouent un certain rôle dans ce domaine.
Même s'il était tentant d'écrire un TL;DR en haut de page, je ne l'ai pas fait, car, surtout pour la deuxième partie, il faut faire très attention à ce que l'on fait, du moins pour l'instant.
Gestionnaire de fenêtres/Tâches récentes
Commençons par le gestionnaire de fenêtres, car il sera également intéressant pour les personnes ne disposant pas d'une grande quantité de RAM. De plus, c'est un peu plus simple.
Il fonctionne avec un certain nombre de variables : config_activeTaskDurationHours ainsi qu'un certain nombre de NumVisibleRecentTasks variables. config_activeTaskDurationHours détermine, comme son nom l'indique, la durée pendant laquelle une tâche est considérée comme active, c'est-à-dire pertinente pour l'utilisateur. Sur mon appareil, cette durée était réglée sur 6. Après ces 6 heures, la "tâche" n'apparaît plus dans la liste des applications récentes, à une exception près : le nombre d'applications ouvertes est inférieur à, dans mon cas, config_minNumVisibleRecentTasks , lanceur inclus. Dans ce cas, l'application n'est pas supprimée. Si le nombre d'applications ouvertes est égal à config_minNumVisibleRecentTasks Cependant, dès que vous ouvrez une application qui n'est pas encore ouverte, l'application ouverte la plus ancienne qui n'a pas été utilisée depuis plus de 6 heures est supprimée.
Il existe également quelques autres paramètres connexes qui n'étaient pas pertinents dans mon cas :
-
config_minNumVisibleRecentTasks_grid : C'est pour lorsque les apps sont affichées dans une grille. Cette vue n'est cependant pas disponible sur de nombreuses versions d'Android.
-
config_minNumVisibleRecentTasks_lowRam : Le même paramètre pour les appareils à faible mémoire vive.
-
config_maxNumVisibleRecentTasks , config_maxNumVisibleRecentTasks_grid y config_maxNumVisibleRecentTasks_lowRam Il s'agit de limites supérieures pour le nombre de tâches récentes. Dans mon cas config_maxNumVisibleRecentTasks a été fixé à -1, ce qui signifie qu'il n'y a pas de limite maximale.
Ceux-ci sont tous saisis à partir de ressources, et peuvent être modifiés avec GravityBox (Root et XPosed/EdExposed/LSPosed requis), sous la section Advanced tuning, dans la section Framework. Ils nécessitent un redémarrage pour activer les changements.
Dans mon cas, j'ai défini les deux config_activeTaskDurationHours y config_minNumVisibleRecentTasks à un niveau ridicule : 5000. De cette façon, il faut plus de six mois pour qu'une tâche ait une chance d'être supprimée, et ce uniquement s'il y a plus de 5000 applications ouvertes, ce qui, je pense, n'arrivera jamais.
Gestionnaire d'activité/OomAdjuster
Cette question a été un peu plus difficile à résoudre pour moi, et il m'a fallu chercher dans le code source pour trouver la réponse - même si la réponse n'en avait pas vraiment besoin. Mais bon.
J'ai d'abord essayé d'écrire un module XPosed pour remplacer com.android.server.am.ActivityManagerConstants et plus particulièrement updateMaxCachedProcesses . Malheureusement, je n'ai pas réussi à accrocher la méthode correctement, je ne sais pas pourquoi. Je n'ai jamais essayé d'écrire un module XPosed avant, et je l'ai fait avec AIDE - peut-être qu'un jour je déballerai à nouveau Android Studio et que j'essaierai de l'utiliser. Mais si quelqu'un veut un contrôle plus fin, cela devrait offrir une avenue pour le faire.
En fin de compte, mon soupçon initial selon lequel vous pourriez être en mesure d'utiliser la limite des processus en arrière-plan de manière non officielle pour augmenter la limite s'est avéré vrai. Bien sûr, si vous allez dans les paramètres du développeur et changez la limite du processus de fond à, disons, 4, la sortie de su -c dumpsys activity settings ressemble à ça à la fin :
mOverrideMaxCachedProcesses=4
CUR_MAX_CACHED_PROCESSES=4
CUR_MAX_EMPTY_PROCESSES=2
CUR_TRIM_EMPTY_PROCESSES=15
CUR_TRIM_CACHED_PROCESSES=10
Notez que les niveaux de finition ne sont pas modifiés et que, selon l'OMI, cela n'a pas de sens de changer ces niveaux même si l'appareil a une grande quantité de RAM. Essentiellement, si les nombres de processus sont inférieurs aux niveaux d'ajustement, le système ne prend même pas la peine d'ajuster la mémoire.
Alors, comment pouvons-nous attribuer une valeur plus élevée ? C'est là que les choses se compliquent. J'ai essayé d'appeler ActivityManager.setProcessLimit() avec l'autorisation android.permission.SET_PROCESS_LIMIT (qui n'est disponible que pour les applications système mais qui peut également être accordée via ADB) comme défini dans l'interface IActivityManager, mais je n'ai pas réussi à le faire fonctionner (encore une fois, je travaillais avec AIDE, donc cela peut être le problème, je peux essayer à nouveau sur Android Studio plus tard).
Cependant, il existe une commande shell Android peu connue, service call qui vous permet essentiellement d'appeler tout un tas de méthodes à partir de différentes interfaces de service, cf. Où trouver des informations sur la commande shell "service call" d'Android ? . Ce que vous recherchez, c'est le service d'activité, qui est défini dans le document android.app.IActivityManager.aidl et vous cherchez la méthode setProcessLimit(int max) . En utilisant le terminal, nous pouvons faire service list pour obtenir une liste des services qui peuvent être appelés ici. Dans mon cas, le nom du service que je cherche est activité. Ensuite, nous recherchons le setProcessLimit(int max) dans le code source. Comme je suis assez proche d'AOSP, je peux la chercher là-dedans. Dans mon cas, c'est la 40ème commande.
AVERTISSEMENT : Avant de montrer ce dont j'avais besoin pour mon appareil, ne suivez pas aveuglément ce . C'est différent pour chaque version d'Android, et si vous vous trompez, cela pourrait causer des problèmes . Lisez le lien du paragraphe précédent pour en être sûr, assurez-vous au moins de comprendre mon explication dans le paragraphe précédent.
Dans mon cas, j'ai décidé de le fixer à quelque chose de ridicule, j'ai donc pris le décuple de la valeur originale, soit 600. Ce qui l'a transformé en : service call activity 40 i32 600 (assurez-vous d'exécuter su avant cela car cela nécessite des privilèges Root). Maintenant, lorsque j'appelle su -c dumpsys activity settings la section ressemble à ceci :
mOverrideMaxCachedProcesses=600
CUR_MAX_CACHED_PROCESSES=600
CUR_MAX_EMPTY_PROCESSES=300
CUR_TRIM_EMPTY_PROCESSES=15
CUR_TRIM_CACHED_PROCESSES=10
Halleluja ! Nous l'avons fait ! Attention, AFAIK, vous devrez répéter les service call à chaque redémarrage, et si vous modifiez la limite des processus en arrière-plan dans les paramètres du développeur, vous perdrez également ce que vous venez de définir.
Peut-être qu'un jour j'essaierai à nouveau cette approche avec une application Root/adb ou un module XPosed, et si je le fais, je mettrai à jour cette réponse. Mais pour l'instant, je suis satisfait des résultats. L'utilisation de la RAM se situe maintenant plutôt entre 5,5 et 6 Go, par opposition à 4 Go. Les applications semblent moins redémarrer. La vie est meilleure.
