Quel est le besoin de pm disable quand pm hide fait déjà son travail ?
J'ai compilé quelques informations sur la base de mes recherches : cliquez ici. aquí pour voir le tableau ( édité ).
Comme vous pouvez le voir, pm hide peut réaliser ce que pm disable peut, mais sans avoir besoin de l'accès Root . De plus, d'après mes tests, je suis arrivé à la conclusion que lorsque pm hide est effectuée, contrairement à pm disable Quoi qu'il en soit, l'application ne sera pas rechargée dans la mémoire.
Je pense que cacher descendant de bloc . Bloc a été introduit pour la première fois dans KitKat 4.4.0 Il est resté jusqu'à Aperçu d'Android L et a été remplacée plus tard par cacher dans Android 5.0.0. Je ne comprends pas très bien ce qui a conduit au changement de nom de l'outil de recherche. bloc a cacher et pourquoi était-elle nécessaire ?
Quoi qu'il en soit, si quelqu'un qui n'a pas accès à Root peut réaliser la fonctionnalité de désactiver alors pourquoi désactiver n'existe pas du tout ?
En outre, pourquoi cacher existe ? Si cacher a été conçu pour aider les utilisateurs à se débarrasser de tout ce qu'ils veulent, sans désinstallation et sans rooter l'appareil, alors l'interface graphique devrait comporter une option appropriée, mais nous avons seulement l'option de désactivation .
Entrecroisez les questions :
-
Quels sont leurs mérites et leurs inconvénients, à l'exception de ceux mentionnés dans ma question ?
-
Pourquoi les deux existent-ils et à quoi servent-ils ?
-
Est-il techniquement vrai que cacher surpasse la fonctionnalité de désactiver y peut vraiment désactiver n'importe quelle application lorsqu'elle est exécutée sur elle ?
-
Nouveau : Compte tenu des résultats d'Andrew T. et de mes tests indiqués dans le tableau, le composant indiqué dans le tableau est le suivant cacher Est-ce que l'usage de l'UE est une erreur ou est-ce que je n'ai pas compris l'usage de l'UE ?
A des fins historiques : cacher L'usage de l'entreprise est actuellement le suivant
pm hide [--user USER_ID] PACKAGE_OR_COMPONENT
Nota: La question ne cherche en aucun cas à obtenir des opinions non fondées, mais des réponses directes et précises. Si vous devez écrire une opinion, assurez-vous de l'étayer en utilisant des sources crédibles et techniques avec un raisonnement solide pour faire la distinction entre ce qui est technique et réel et ce qui est spéculatif.
Tests effectués sur Carbon ROM (Android 5.1.1) et COS12 (Android 5.0.2) pour le OnePlus One.
7 votes
La plus grande différence est que vous pouvez désactiver le composant per-app (activité, service, récepteur de diffusion, fournisseur de contenu) sans désactiver l'application elle-même, mais vous pouvez seulement masquer l'ensemble de l'application . Le site
pmL'usage est légèrement confus pourhidemais le code sous-jacent ne traite que l'ensemble du paquet, et non le composant. En d'autres termes,hideest temporaireuninstall -k.1 votes
C'est une information intéressante. Maintenant que vous avez mentionné cette information, je testerais et rapporterais si
hidepeut désactiver un composant ou non. Son utilisation semble être une copie dedisable: Android.googlesource.com/platform/frameworks/base/+/3 votes
C'est pourquoi c'est trompeur ;
runSetEnabledSetting()vérifie le nom du composant, maisrunSetHiddenSetting()ne vérifie que le nom du paquet. Je ne suis pas sûr qu'il puisse cacher les composants à l'avenir.1 votes
@AndrewT., merci pour ces informations. Mes tests ont donné des résultats conformes à vos informations. Veuillez consulter la question révisée incluant le tableau édité pour plus d'informations. Si cela est possible pour le moment, envisagez de poster une réponse formelle.
0 votes
Je suppose que, puisque désactiver nécessite Root, activer le serait aussi. La désactivation de l'application offrirait alors de meilleures garanties qu'aucune application malveillante ne pourrait l'activer.
0 votes
Je suis arrivé à la même conclusion qu'Andrew...
2 votes
Références : Introduit un nouvel état "bloqué". y Renommer
setApplicationBlockedàsetApplicationHidden