Pourquoi les applications désactivées sont-elles toujours en cours d'exécution?

8

J'ai remarqué que les applications (telles que Google Contacts Sync) qui ont été désactivées à l'aide du gestionnaire d'applications Android (KitKat) apparaissent toujours comme en cours d'exécution lors de l'utilisation des outils d'observation des processus. Cela est vrai même après le redémarrage de l'appareil.

Pourquoi les applications désactivées sont-elles toujours en cours d'exécution? Existe-t-il un moyen efficace (et sûr) de les désactiver?

Les solutions nécessitant des privilèges root sont acceptables.

(Notez que pour l'exemple spécifique ci-dessus, vous pouvez dire à Android de ne pas synchroniser vos contacts, mais il exécute toujours le processus de synchronisation des contacts Google. Mais ne nous attardons pas sur cet exemple ... c'est juste un exemple.)

applications 4.4-kitkat task-management disable-app RockPaperLizard
la source
Juste à côté du bouton "Désactiver" se trouve un bouton "Forcer l'arrêt". Appuyez dessus et le processus devrait se terminer et ne plus démarrer.
GiantTree
@GiantTree Merci. Après un redémarrage, ne recommencera-t-il pas tout simplement?
RockPaperLizard
4
Dans votre cas, c'est le cas, car une application système a explicitement appelé un service exporté de ce package et le seul moyen de tuer de manière fiable ce processus (et tout autre) est de le tuer activement en utilisant Greenify, Amplify (nécessite Xposed) ou des applications similaires. Remarque: cela ne doit pas se produire et doit être considéré comme un bogue, car le PackageManager a la tâche de ne pas autoriser l'exécution d'une application désactivée.
GiantTree
1
Eh bien à cet égard, j'ai désactivé tous les services, récepteurs, activités et fournisseurs de contenu, ainsi que désactivé l'application SystemUI. Redémarrez l'appareil et devinez ce que l'application a encore été chargée dans la mémoire (ce n'est pas le cas avec pm block/hide), ce qui me fait me demander ce qui provoque le chargement de l'application maintenant. C'est une autre question que pendant qu'il était chargé dans la mémoire, vous pouvez observer son absence superficielle par manque de fond, de thèmes, de barre d'état et plus encore. Peut-être, une nouvelle question peut être forgée à partir de cela.
Firelord
1
@Firelord Je suppose que c'est ce que j'ai souligné ci-dessus: si vous désactivez une application, elle est simplement "marquée comme désactivée" (et ne s'affiche pas dans le lanceur, etc.) - mais elle est toujours enregistrée auprès du système (gestionnaire de paquets), afin que d'autres applications puissent la trouver et appeler ses intentions. Il semble que le masquage / blocage soit plutôt comparable à une "désinstallation laissant .apket les données derrière" - donc l'application est "complètement non enregistrée et invisible pour tout sauf le gestionnaire de fichiers", de sorte que d'autres applications ne sont plus en mesure d'appeler ses intentions comme elles le peuvent ne les trouve pas.
Izzy

Réponses:

7

Votre Android n'a pas besoin d'avoir un accès root pour vraiment désactiver une application, si vous avez la version 4.4.x ou supérieure. Tout ce dont tu as besoin c'estadbconfiguration sur PC et débogage USB activée sur un appareil non rooté, ou une application d'émulation de terminal pour un appareil rooté (vous pouvez également utiliser adb).

Si vous vérifiez l'utilisation de Package Manger ( pm), vous verrez

pm pm [--user USER_ID] PACKAGE_OR_COMPONENT ")
pm débloquer [--user USER_ID] PACKAGE_OR_COMPONENT ")

Pour Lollipop, ce serait

pm hide [--user USER_ID] PACKAGE_OR_COMPONENT ")
pm afficher [--user USER_ID] PACKAGE_OR_COMPONENT ")

Pour bloquer ou cacher un paquet (c'est sûr), faites simplement 

pm block PACKAGE # for KitKat
pm hide PACKAGE  # for Lollipop

Pour débloquer ou afficher le package, faites

pm unblock PACKAGE #for KitKat 
pm unhide PACKAGE  # for Lollipop

PACKAGE→ nom du package d'une application. Pour connaître le nom de package d'une application:

Ajoutez adb shellavant toute commande de les exécuter à partir du PC.

La fonction derrière hide a le commentaire suivant à l'intérieur du code source

Place le package dans un état masqué, ce qui est presque comme un état désinstallé, ce qui rend le package indisponible, mais il ne supprime pas les données ou le fichier de package réel. L'application peut être masquée en réinitialisant l'état masqué ou en l'installant

Des commentaires similaires sont effectués pour bloquer ici .

Afin de vérifier la demande, vous pouvez utiliser certains services système tels que meminfo, procstatset en activityutilisant l' dumpsys outil ou même la liste de tous les processus utilisant ps. Vous ne trouverez pas une présence active de l'application bloquée / masquée.

Il en va de même pour de nombreuses applications système désactivées à l'aide de l'interface graphique ou pm disablepas pour toutes les applications, car même une application désactivée peut recevoir des émissions pour lesquelles elle est enregistrée, ce qui ne peut être fait que si elle est chargée dans la mémoire 1 . Néanmoins, une application désactivée ne peut pas agir seule, ni être exécutée par une autre application.

J'ai argumenté certaines des différences entre masquer / bloquer et désactiver sur ma question pm hide VS pm disable - la crise d'identité . Il ne fournit que des informations supplémentaires à cette réponse, vous pouvez donc les ignorer.

ÉDITER:

Il semble que la technique ne fonctionne pas pour toutes les applications sur Android KitKat. Dans ce cas, révoquez simplement l'autorisation de lecture de l'APK de l'application ou supprimez l'extension .APK du nom de fichier de l'application (ce dernier suggéré une fois par Jaskaranbir), suivi d'un redémarrage logiciel / complet. Cela revient à supprimer une application du système, à la seule différence que tous les fichiers resteront à leur place.

Les deux étapes peuvent être exécutées à l'aide de n'importe quelle application de gestion de fichiers racine. La manière en ligne de commande est:

adb shell su -c 'chmod 000 /data/app/PACKAGE*'             # 000 means no read-write-executable permission to user,group and others. 
adb shell su -c 'mv /data/app/PACKAGE* /data/app/PACKAGE'  # doing renaming by moving the file
adb reboot

1: Manque de preuves techniques pour étayer le fait

Seigneur du feu
la source
Très bonne réponse! Je vous remercie! Est-il préférable de désactiver d'abord l'application à l'aide du gestionnaire d'applications Android d'origine, ou de s'assurer qu'il n'y est pas désactivé?
RockPaperLizard
Il n'est pas nécessaire de désactiver l'application si vous optez pour, pm block/hidealors laissez-la intacte.
Firelord
S'il est déjà désactivé, est-il préférable de le réactiver?
RockPaperLizard
1
C'est bizarre. J'ai testé le blocage de systemui sur mon Kitkat et à ma grande surprise, le blocage fonctionne comme désactivé, cette application reste en mémoire. Le processus SystemUI a été bifurqué même si je l'ai tué. Je ne sais pas si c'est un bug ou un comportement souhaité, mais en tout cas, c'est en contraste avec mes conclusions liées à Lollipop énoncées dans la réponse. Je suppose que la réponse est assez inutile maintenant.
Firelord
1
@RockPaperLizard, j'ai oublié de vous dire une astuce très simple. Révoquer les autorisations de lecture du fichier de package (ou du répertoire de base, dans le cas de Lollipop), redémarrer et faire pour de bon. Par exemple, avec les permissions root, vous pouvez arrêter SystemUI de cette façon, adb shell su -c "chmod 111 /system/app/SystemUI.apk". 111 signifie définir uniquement les autorisations exécutables pour le propriétaire, le groupe et les autres. Redémarrez et l'application sera manquante sur le système. Vous pouvez également le définir 000.
Firelord