11 votes

Existe-t-il un moyen (avec Root ?) d'empêcher le tueur de tâches Android de tuer certaines applications ?

J'aimerais qu'une application de navigation (FireFox) ne soit pas tuée de temps en temps par le tueur de tâches du système, car j'aimerais utiliser certaines applications à page unique qui contiennent des données et ne sont pas chargées très rapidement. Existe-t-il un moyen de résoudre ce problème, même si Root est nécessaire ?

Il y a quelque temps, j'ai mis à jour mon appareil d'une RAM de 1 Go à une autre de 3 Go et tout s'est bien passé (le navigateur a cessé d'être tué). Mais après une mise à jour du système en janvier 2016, les choses ont empiré, maintenant FireFox est généralement tué même après la sonnerie d'un réveil ou l'ouverture d'une application de caméra. C'est un problème majeur pour moi donc j'apprécie toute aide à ce sujet.

PS oui, j'ai essayé SettingsBatteryBattery Optimization où j'ai à la fois ajouté FF aux exceptions (cela n'a pas aidé) et désactivé l'optimisation de la batterie (cela n'a pas aidé non plus).

12voto

xavier_fakerat Points 9582

Tl;dr

C'est possible avec Root, vous pouvez modifier oom_adj pour empêcher les applications d'être tuées, pour forcer l'application cible à rester en mémoire en la "verrouillant" ou pour modifier certains paramètres responsables de la mort des applications en cas de manque de mémoire.


Fond d'écran : Gestion de la RAM sous Android

Android utilise une manière différente de gérer les processus. Au lieu de tuer chaque processus après la fin de son activité, les processus sont conservés jusqu'à ce que le système ait besoin de plus de mémoire. L'idée est de donner des améliorations de vitesse si vous recommencez cette activité. Mais comment/quand Android tue-t-il un processus s'il a besoin de plus de mémoire et quel processus tuer en premier ?

Ceci est géré par le pilote LMK (Low Memory Killer) d'Android. Vous savez peut-être déjà que chaque application/processus d'Android se voit attribuer une oom_adj qui indique la probabilité qu'il soit tué lorsque lorsqu'une situation d'absence de mémoire (OOM) se produit. Plus sa valeur est élevée, plus la plus la probabilité qu'il soit tué est élevée. La plage valide est -17 à +15 . (si dans le -17 signifie qu'il ne sera pas tué). D'après ça, il y a six groupes (groupes OOM), dans lesquels les applications/processus sont classés sont catégorisés :

  1. Application de premier plan
  2. Application visible
  3. Serveur secondaire
  4. Application cachée
  5. Fournisseur de contenu
  6. Application vide

En gros, on pourrait les décrire comme suit :

FOREGROUND_APP : C'est le processus qui exécute l'application de premier plan actuelle courante. Nous préférons vraiment ne pas le tuer !

VISIBLE_APP : Il s'agit d'un processus n'hébergeant que des activités qui sont visibles pour l'utilisateur, donc nous préférerions qu'elles ne disparaissent pas.

SECONDARY_SERVER : C'est un processus qui tient un serveur secondaire -- le tuer n'aura pas beaucoup d'impact pour l'utilisateur. l'utilisateur.

HIDDEN_APP : Il s'agit d'un processus n'hébergeant que des activités qui ne sont pas visibles, il peut donc être tué sans aucune perturbation.

CONTENT_PROVIDER : Il s'agit d'un processus avec un fournisseur de contenu qui n'a pas de clients attachés à lui. S'il avait des clients, son ajustement serait celui du processus le plus prioritaire parmi ces clients. processus.

EMPTY_APP : Il s'agit d'un processus sans rien en cours d'exécution il. C'est certainement le premier à disparaître.

Ces groupes sont définis par oom_adj et les pommes seraient classées dans l'un de ces groupes en fonction de leur valeur limite. oom_adj valeur attribuée à cette application particulière. Les "applications d'avant-plan" ont généralement une valeur oom_adj valeur de 0 ou moins (afin qu'ils soient les moins susceptibles d'être tués, c'est-à-dire une priorité élevée).

Les "applications vides" ont un taux de oom_adj (ils sont tués tôt, c'est-à-dire en basse priorité). Aussi, oom_adj La valeur change en fonction de l'état de l'application de l'utilisateur. 0 lorsque l'application est active au premier plan et une valeur plus élevée lorsque l'application passe en arrière-plan.

Pourquoi leur "tuabilité" diffère-t-elle ? Les applications appartenant à ces différents groupes (qui ont des oom_adj's ), commencent à être tués à différents niveaux de RAM libre. Ces limites de déclenchement de la RAM sont définies par les valeurs de LMK minfree. Les 6 catégories ci-dessus correspondent à 6 limites de RAM qui sont définies dans LMK minfree. eg : Stock Android 4.3 dans mon est livré avec les valeurs minfree suivantes 48,60,72,84,96,120 . (ces sont en MB).

enter image description here

En pratique, cela signifie que les applications vides seront tuées lorsque la mémoire vive descend en dessous de 120mb, les fournisseurs de contenu lorsqu'elle descend en dessous de 96mb, les applications cachées lorsqu'elle descend en dessous de 84mb et ainsi de suite enfin, les applications d'avant-plan sont tuées lorsque la mémoire vive descend en dessous de 48mb.

NB :

  1. Dans les noyaux plus récents, oom_ score _adj est utilisé à la place de l'ancien oom_adj . (la plage valide de oom_score_adj est de -1000 à 1000). Mais oom_adj est également maintenu pour une éventuelle compatibilité.

  2. Il est dit qu'il existe de nombreuses catégories de processus d'OOM auxquelles sont attribuées différentes oom_adj priorités par le ActivityManagerService Mais finalement, tous ces éléments seront considérés comme faisant partie des six slots/groupes ci-dessus (selon oom_limits), dans le but d'être tués par les triggers LMK minfree. Par conséquent, ces six sont les plus importants pour les utilisateurs normaux.

    • Nous pouvons vérifier les valeurs de minfree (ou les modifier) et voir les OOM. des applications/processus avec cette application Memory Manager.
  3. Tous les appareils n'ont pas la même configuration d'OOM.


Améliorer la gestion de la RAM

Aujourd'hui, le mécanisme de gestion de la RAM est mis en œuvre de manière très conviviale dans les paramètres du système (par exemple, l'optimisation des applications dans les paramètres de la batterie), Applications protégées dans certains ROMS, par exemple EMUI de Huawei etc.) et peuvent avoir le même effet que celui décrit ci-dessus :

enter image description here

Cela dit, nous pouvons maintenant explorer les moyens d'utiliser la RAM sans tuer trop souvent les applications de premier plan. Les domaines ciblés seront les suivants :

1. ajuster les valeurs de minifree en fonction de ses besoins

2. le verrouillage des applications en mémoire pour éviter qu'elles ne soient détruites.

3. passer outre la limite des applications cachées d'Android


  1. Ajustement des valeurs minifree

    • Vous pouvez modifier les valeurs minfree avec le gestionnaire de mémoire et appuyer sur appliquer. (En outre, il y a une option "appliquer au démarrage" et cocher pour préserver les paramètres entre les démarrages). Plusieurs applications peuvent réaliser cela, par exemple Gestionnaire de mémoire , Gestionnaire Minfree etc.

    • Vous pouvez également utiliser terminal/adb en utilisant les pages :

      #!/system/bin/sh echo “values” > /sys/module
  2. Verrouiller les applications pour qu'elles restent en mémoire (les rendre résidentes)

a) Utiliser les paramètres de l'application (Xposed)

  • Une méthode simple consiste à utiliser le module Xposed, les paramètres de l'application (vous avez besoin de Cadre Xposed installé)
  • Après avoir installé le framework, téléchargez le module 'App Settings' via l'installateur Xposed.
  • Ouvrez les paramètres de l'application et permettez aux applications de se charger, sélectionnez l'application cible (dans ce cas-ci navigateur firefox )
  • Dans la page des paramètres, activez le commutateur et activez le mode d'édition, cochez l'option "Résident" et enregistrez. ( En rendant les applications résidentes, les applications restent en mémoire sans être tuées et il est conseillé d'utiliser le bouton de sortie de l'application cible si elle n'est plus nécessaire, sinon elle privera les autres applications de mémoire).

enter image description here

b) En utilisant armoire à souvenirs

Une autre mise en œuvre de ce concept consiste à verrouiller l'application cible en mémoire en contrôlant les fichiers système pour la mise en place de oom_adj pour tous les processus en cours.

Comment fonctionne l'application :

Memory locker contrôle les fichiers du répertoire /data et contrôle également les fichiers système dans Root pour définir oom_adj pour les processus en cours.

Toutes les applications applications verrouillées sont automatiquement verrouillées après chaque redémarrage. Les applications sont classées en tant qu'applications téléchargées/système. et cliquez sur le verrou sur le côté droit. (Vous pouvez éventuellement définir oom_adj priorité)

  1. Remplacer la limite des applications cachées

    • En plus du mécanisme de destruction de la mémoire faible, il existe un autre paramètre qui contrôle la destruction des applications cachées et vides. Les applications sont détruites lorsqu'elles dépassent les limites spécifiées.

    • Il existe un paramètre du fichier build.prop qui permet de contrôler cette valeur (la valeur par défaut est généralement un nombre faible, inférieur à 25, et la modifier peut augmenter cette valeur à une valeur beaucoup plus grande, comme 80)

    • Ajoutez cette ligne au fichier build.prop dans /system et laissez une autre ligne vierge en dessous (assurez-vous de faire un back up avant)

ro.sys.fw.bg_apps_limit=80


Références et crédits

  1. Gestion de la RAM sous Android (Crédits spéciaux : mrhnet )
  2. Casier à mémoire
  3. Xposed - Informations générales, versions et journal des modifications

3voto

Zediiiii Points 111

Le post ci-dessus est très complet, mais je vais ajouter des instructions pour quelques modèles spécifiques (volées de la page d'application ASM). Notez que pour les applications qui utilisent plus de mémoire (par exemple Firefox), le système finira probablement par tuer l'application de toute façon lorsque d'autres applications demanderont de l'espace mémoire. Si la mémoire cache est nécessaire, les applications les plus grandes et les plus anciennes passent en premier, quels que soient les paramètres d'économie de batterie, et Firefox est un grand dépensier.


Comment faire face aux économiseurs de batterie (connus) ?

Samsung Dans les paramètres Android > Maintenance de l'appareil > Batterie, ajoutez l'application à la liste des applications non surveillées.

Huawei (selon les modèles) Dans les paramètres Android > Paramètres avancés > Gestionnaire de batterie, ajoutez l'application à la liste des applications protégées. ou : Batterie > Fermer les apps après le verrouillage de l'écran, décocher l'app du nettoyage de l'écran de verrouillage.

Xiaomi Dans votre application Sécurité : Batterie % > Économiseur de batterie d'application, sélectionnez l'application puis Aucune restriction. et : Dans votre application Sécurité : Permissions > Démarrage automatique puis autoriser le démarrage de l'application.

Asus (Zenfone) Ouvrez votre gestionnaire de démarrage automatique et autorisez le démarrage de l'application.

OnePlus Dans les paramètres Android > Batterie > Menu > Veille prolongée et hibernation des applications, cochez l'application pour l'exclure des applications optimisées.

Infinix Ouvrez votre application Xmanager, Démarrage automatique du gestionnaire et autorisez le démarrage de l'application.

2voto

Guillermo Gomez Points 423

Cette application, Gestionnaire de RAM prétend pouvoir verrouiller certaines applications de la mécanique de gestion de la RAM d'Android.

Vous pouvez également vous rendre sur le site ParamètresBatterieOptimisation de la batterie et régler Firefox sur N'optimisez pas peut aider un peu.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X