Aller au contenu

FAQs PMX

Pourquoi dois-je utiliser PMX?

Parce que :

  • PMX rassemble toutes les infos et les commandes liées aux autorisations qui sont éparpillées (ou pas disponibles) sur un seul écran pour que tu puisses les voir et les contrôler de manière claire et pratique.
  • Il n'y a pas d'outil officiel disponible en stock Android pour changer AppOps. Seuls un sous-ensemble de permissions manifest sont exposés à l'utilisateur dans les paramètres d'autorisation. PMX expose toutes les autorisations sous forme brute. Relatif : AutorisationsManifest et AppOps.
  • PMX te permet de suivre facilement toutes les modifications indésirables apportées aux autorisations.
  • En donnant le contrôle sur votre appareil, PMX vous permet d'économiser des ressources de l'appareil comme la batterie et la bande passante du réseau, et de protéger votre vie privée. Vous n'êtes pas entièrement laissé à la merci de l'application et des développeurs ROM. Lisez ceci article pour avoir une idée.
  • PMX peux suivre les changements d'autorisation en direct et les annuler automatiquement quand tu arrêtes d'utiliser une appli. Ou il peut effectuer une analyse programmée des permissions. Vous n'avez donc pas à vous souvenir des choses.
  • PMX vous facilite la sauvegarde et restauration des autorisations de l'état des applications installées, de sorte que vous n'ayez pas à modifier les permissions d'une application encore et encore.

Veuillez également voir Qu'est-ce que PMX ?


Pourquoi PMX requiert un accès root ou ADB?

Android empêche intentionnellement les applications de modifier les autorisations manifest ou AppOps d'autres applications (et dans de nombreux cas de modifier certaines de leurs propres applications). Ces protections protègent la confidentialité des utilisateurs et l'intégrité du système.

Pour effectuer des actions qui nécessitent des privilèges élevés, PMX utilise un petit assistant privilégié séparé plutôt que d'essayer de tout faire depuis le processus normal de l'application. Par défaut, cette aide s'exécute sous l'UID ADB (2000) lorsque démarré via ADB, ou sous l'UID System (1000) sur les périphériques rootés. Si vous avez un périphérique rooté, vous pouvez modifier l'UID de l'aide dans Paramètres avancés.


Mon appareil n'est pas rooté. Comment puis-je utiliser PMX?

Utiliser PMX avec ADB. Veuillez lire la note au début. Il peut y avoir des limitations sur certains appareils.


Pourquoi PMX ne fonctionne pas ou ne fonctionne pas correctement sur la dernière version d'Android ?

PMX s'appuie sur les API cachées d'Android ou les interfaces non-SDK qui ne sont pas documentées (Développeurs Android) à la différence des API standard. Donc, à chaque nouvelle version d'Android, nous devons passer par le code source d'Android pour savoir quelles API ont cassé (changé ou supprimé).

De plus, il faut du temps pour réparer les APIs cassés ; parfois des semaines, parfois des mois. Et il n'est pas garanti que nous serons toujours en mesure de corriger les API cassées. Parfois, Google a pour but de rendre difficile ou impossible pour nous de continuer à utiliser les API cachées.

Par conséquent, il n'est pas possible pour nous de faire en sorte que l' PMX fonctionne immédiatement sur chaque nouvelle version d'Android (particulièrement en phase bêta) tant que le code source AOSP final n'est pas publié publiquement (Recherche de code ou Référentiel Git).

La version finale d'Android prise en charge par PMXest indiquée dans la description de l'application sur GitHub et le Play Store. Lorsque vous exécutez l'application sur une version non prise en charge pour la première fois, elle affiche un avertissement comme celui-ci :

Avertissement de version Android non pris en charge


Pourquoi PMX ne fonctionne pas correctement sur les systèmes d'exploitation OEM ou sur mesure ROMs?

PMX s'appuie sur les API cachées d'Android ou les interfaces non-SDK qui ne sont pas documentées (Développeurs Android) à la différence des API standard. Nous avons donc besoin d'accéder au code source de votre ROM pour savoir exactement comment fonctionnent les API cachées.

Eh bien, AOSP (qui est développé par Google) est open-source. Mais si votre développeur OEM ou ROM apporte quelques modifications à AOSP à des fins de personnalisation, nous n'avons aucun moyen de savoir exactement quels changements ils ont apporté au code AOSP du stock. Nous sommes assez impuissants ici. Et ce fait est indiqué dans la description de l'application sur GitHub et le Play Store. Désolé.


Comment PMX modifie-t-il les autorisations des autres applications ?

PMX ne peut pas et ne donne ni ne retire les autorisations d'autres applis. En fait, aucune application tierce n'a le privilège de le faire. C'est l'OS Android qui contrôle les autorisations des applications. PMX envoie une demande au framework Android pour modifier l'état d'une autorisation. Maintenant, c'est entièrement à Android combien cela honore notre demande. Toutes les permissions ne sont pas modifiables. Et si vous n'êtes pas en mesure de changer l'état d'une permission en utilisant PMX, vous ne pourrez pas non plus le modifier autrement.


Les permissions restent-elles modifiées après la désactivation de ADB ou le root est refusé, ou bien PMX est désinstallé ?

PMX ne peut pas et ne donne ni ne retire les autorisations d'autres applis. En fait, aucune application tierce n'a le privilège de le faire. C'est l'OS Android qui contrôle les autorisations des applications. PMX envoie une demande au framework Android pour modifier l'état d'une autorisation.

Donc, une fois qu'une permission est modifiée, cela ne fait aucune différence si vous désinstallez PMX ou supprimez ses privilèges. La permission reste dans quelque état que ce soit, sauf si vous ou le système d'exploitation avez changé à nouveau.


Pourquoi ne puis-je pas modifier la permission XYZ ?

Les permissions de manifestes avec seulement niveau de protection dangereux (et quelques autres) sont modifiables. AppOps qui ne dépendent pas d'autres AppOp sont modifiables. C'est ainsi que fonctionne Android, nous ne pouvons pas modifier le comportement. Voir les permissionsManifest et AppOps.

De plus, PMX protège certaines applications et autorisations critiques du framework ; les changer peuvent bloquer l'appareil. Voir la question liée.

Voir aussi Pourquoi certains AppOps ne peuvent pas être changés?

Notez que depuis Android 15, les autorisations manifest des applications système avec le niveau de protection Développement ne peuvent pas être révoquées. Android ignore silencieusement la requête.


J'ai changé de permission, mais ça ne fonctionne pas. Pourquoi?

Après avoir modifié une permission avec succès, si vous ne obtenez pas les résultats souhaités i.e. il revient immédiatement ou après quelques heures ou quelques jours, c'est le système d'exploitation Android à blâmer. Veuillez voir:

Lorsque vous utilisez des applications, Android peut modifier leurs permissions. Et nous n'avons malheureusement aucun moyen de l'empêcher. Observateur de permission et Vérificateur programmé peuvent vous aider à cet égard.


Pourquoi certains AppOps ne peuvent pas être changés ?

Parfois, vous voyez " Le modeAppOp n'a pas été changé". Cela signifie qu'Android a rejeté la demande de modification du mode AppOp. Vous ne pouvez pas le modifier quelle que soit la méthode ou l'application que vous utilisez. Il pourrait y avoir plusieurs raisons possibles.

  • Certains AppOps dépendent de leurs permissions manifest correspondantes. Ils ne peuvent donc pas être modifiés indépendamment. Par exemple, vous ne pourrez peut-être pas refuser READ_CONTACTS AppOp si une permission android.permission.READ_CONTACTS manifest est accordée.

    Également si l'application n'a pas demandé la permission manifest dans son fichier manifest , sa permission AppOp ne peut pas non plus être accordée. Mais il peut toujours apparaître dans la liste des permissions de l'application si l'application a essayé de l'utiliser (et a été rejetée). SYSTEM_ALERT_WINDOW en est un exemple.

  • Certains AppOps ne sont utilisés par Android que pour des raisons de compatibilité (par exemple LEGACY_STORAGE) et ils ne contrôlent rien. Si nous explorons leur travail sous-jacent, il est révélé que l'octroie/révocation de telles autorisations n'a aucun sens.

  • Certaines autorisations ne peuvent pas être modifiées si l'application est en cours d'exécution ou cible une version Android plus ancienne ou plus récente.

  • Certains OEM ROMs se comportent bizarrement en ce qui concerne AppOps. Voir Pourquoi PMX ne fonctionne pas correctement sur les systèmes d'exploitation OEM ou ROMspersonnalisés ?

  • De nombreux AppOps peuvent avoir 2 modes : le mode package et le mode UID. Il est possible que l'un puisse être changé alors que l'autre ne peut pas être.

    Habituellement UID AppOps a préséance sur ses homologues AppOp paquets. Dans ce cas, le mode effectif du package AppOp est identique à celui de son UID AppOps. Vous ne pouvez donc pas changer le package AppOp seul.

    Certains AppOps préfèrent être configurés en mode paquet, pas en mode UID. Mais si elle est mal définie en mode UID (avec un outil en ligne de commande ou par une autre application), elle ne répond pas aux changements. Faites "Réinitialiser AppOps" depuis le menu en haut à droite pour le faire fonctionner à nouveau. C'est également le cas pour les autres AppOps qui ont une permission manifest correspondante avec AppOp niveau de protection.

En fait, il y a beaucoup plus d'explications si nous fouillons chaque application et chaque autorisation individuellement (ce qui ne semble pas pratique). Comme on l'a dit plus haut, PMX ne change pas tout seul les autorisations des autres applis. Donc, même si pour une raison inconnue, Android ne modifie pas une permission, ou le remet immédiatement à zéro, il n'y a rien que nous pouvons faire pour le forcer car ce sont les limitations à la fin d'Android. Je devrais plutôt dire que c'est ainsi que fonctionne Android.

Relatif :


Pourquoi ne pas voir l'application XYZ dans la liste des paquets ?

Veuillez vérifier les filtres d'exclusion. Presque tous les paquets Android d'origine sont exclus par défaut. Vous pouvez exclure / inclure n'importe quel paquet que vous voulez de / à la liste visible.


Pourquoi ne puis-je pas voir les permissions XYZ dans le paquet ABC ?

Veuillez vérifier les filtres d'exclusion. Les permissions qui ne sont pas modifiables sont exclues de la liste visible par défaut.


Pourquoi ne puis-je pas voir XYZ AppOp dans le paquet ABC ?

Veuillez vérifier les filtres d'exclusion si XYZ AppOp est exclu de la liste visible. Ou ABC package peut ne pas utiliser une opération XYZ. Vous n'avez pas besoin de vous inquiéter à ce sujet.

Mais si vous voulez voir le XYZ AppOp pour toutes les applications, allez dans Exclusion Filters → Extra AppOps, jamais exclu et vérifiez XYZ AppOp dans la liste.

Par exemple, écrivez _CLIPBOARD dans la boîte de recherche (avec la case Recherche profonde cochée) et vous obtiendrez toutes les applications qui ont utilisé (ou tenté d'utiliser) la permission READ_CLIPBOARD ou WRITE_CLIPBOARD. L'horodatage est également affiché (mais pas pour tous les AppOps).

Donc, si l'application qui vous préoccupe n'est pas dans les résultats de recherche, vérifiez AppOps dans la liste Filtres d'exclusion mentionnée ci-dessus.


Que dois-je sélectionner pour l'UID du démon privilège dans les paramètres avancés ? Système ou ADB?

Cela ne compte que si vous utilisez root, ou adbd sur votre appareil fonctionne avec le root (ce qui n'est pas le cas avec les appareils de l'utilisateur final).

Utilisez de préférence Système (UID 1000) car il permet plus de privilèges que ADB (UID 2000). Par ex. modifier les permissions "Système-Fixed" n'est possible que lorsque le système est lancé.


Que sont les "permissions invalides" dans les filtres d'exclusion ?

Si une application demande une autorisation manifest mais qu'elle ne soit pas déclarée (fournie) par le framework Android ou par aucun des paquets installés, c'est une permission invalide. Par exemple, com.android.vending.BILLING n'est pas une autorisation valide si l'application Play Store n'est pas installée sur votre appareil.


Que sont les « AppOpssupplémentaires » dans les filtres d'exclusion ?

Tous les AppOps ne sont pas utilisés pour toutes les applications installées. Mais vous pouvez imposer un AppOp à n'importe quelle application. L' AppOps supplémentaire sélectionné apparaît dans les listes d'autorisations de toutes les applications afin que vous puissiez les définir.


Quels sont les différents modes AppOp et lesquels dois-je utiliser ?

Normalement, vous devriez autoriser ou ignorer. Ou vous pouvez autoriser une opération uniquement lorsque l'application est en premier plan (uniquement sur Android 9 et supérieur). Refuser est la version intense d'Ignore qui peut faire planter l'application requise. Par défaut est le comportement par défaut du système qui diffère pour différents AppOps.

Veuillez noter que tous les modes AppOp ne peuvent pas être configurés sur chaque AppOp pour chaque application. Par exemple, sur les dernières versions d'Android CAMERA et MICROPHONE sont autorisés à être utilisés par les applications utilisateur uniquement au premier plan (même si le mode défini est Autorisé). De la même façon, certains AppOps ne peuvent jamais être réglés en mode Foreground.

Lié : Pourquoi AppOps ne peut pas être modifié ?

Documentation officielle: AppOpsManager.


Quelle est la différence entre les modes « Ignorer » et « Refuser » AppOp?

Ignore échoue silencieusement alors que Deny renvoie une erreur à l'application que l'application pourrait ne pas attendre et peut crasher. Vous devriez normalement utiliser Ignorer.


Pourquoi ne puis-je pas mettre le mode AppOp au premier plan ?

Le mode de premier plan ne peut pas être défini pour tous les AppOps. Même si elle est définie, elle peut ne pas donner de résultats attendus.

Relatif :

Veuillez noter que le mode d'autorisation "Autoriser uniquement lorsque vous utilisez l'application" ne définit pas toujours le mode AppOp sur "Premier plan":

Modes de permission au premier plan et à une fois

Normalement, nous ne voyons que deux états pour une autorisation manifest : accordée et révoquée. Mais Android utilise flags pour scinder ces deux états en plusieurs sous-états. Pour certaines autorisations, le même phénomène est utilisé pour obtenir le comportement "accorder uniquement lorsque l'application est visible". La permission AppOp n'est pas utilisée dans ce cas.

Pour plus de détails, voir la documentation officielle de accès en arrière-plan et accès au premier plan.

Pour plus de simplicité, PMX ne regarde pas les drapeaux de permission pour le moment. Mais à l'avenir, une option pourrait être ajoutée pour suivre également les modifications des options de permission, même si le mode autorisé/révoqué reste inchangé.


Que fait la permission WAKE_LOCK?

Les applications maintiennent wakelock pour garder l'appareil éveillé, c'est-à-dire ne pas entrer en mode Doze.


Comment puis-je changer la permission INTERNET?

Android ne permet pas de changer toutes les permissions, comme celles qui ont le **niveau de protection Normal niveau de protection (e. . INTERNET) ou ceux qui ont un indicateur fixe ou un niveau de protection Signature (généralement des applications System ou Framework). Voir les permissionsManifest et AppOps.

Mais si vous êtes rooté, Fyrypt vous donne un contrôle très fort sur l'activité du réseau sur votre appareil.


Que sont les permissions fixes?

Les permissions réparées par le système sont accordées aux applications préinstallées par les développeurs OEMs ou ROM. Elles ne sont pas censées être modifiées. Mais si votre appareil est rooté, PMX peut modifier les permissions fixées par le système.

Les autorisations fixées par la politique sont accordées (ou refusées) par les administrateurs informatiques sur les appareils gérés. Elles ne peuvent pas être modifiées.

Les permissions fixes sont fixées par l'utilisateur. Si un utilisateur refuse une autorisation à plusieurs reprises lorsque l'application le demande, le système d'exploitation marque la permission comme réglée par l'utilisateur et n'affiche plus d'invite l'utilisateur à accorder l'autorisation si l'application demande la même permission à nouveau. Ce type d'autorisations fixes peut être facilement modifié quand l'utilisateur le veut.


Comment puis-je modifier les permissions fixées par le système, les autorisations de signature/privilèges ou les permissions des applications du framework ?

Si votre appareil est rooté, dans la version payante, vous pouvez autoriser les modifications critiques dans les Réglages avancés pour apporter des modifications aux permissions avec l'option Système-Fixed, niveau de protection Signature ou Privilèges, ou ceux de l'application Framework. Mais il n'est pas recommandé de jouer avec les applications System and Framework. Vous pouvez briquer votre appareil.


Qu'est-ce que le "mode UID" dans les autorisations AppOp?

C'est un mode d'autorisation AppOp qui indique que le changement de l' AppOp affectera également les autres applications (avec le même UID), si installé. Voir sharedUserId.

Notez que le mode UID a préséance sur le mode package pour beaucoup de AppOps.


Est-ce que je peux contrôler la fonctionnalité Android « Supprimer les autorisations si l'appli n'est pas utilisée » depuis PMX?

Oui. Cette fonctionnalité est disponible depuis Android 11. Il est également marqué comme "Pause l'activité de l'application si non utilisée" sur certains appareils.

Suppression automatique des permissions inutilisées

Pour changer cette option de PMX:

  1. Allez dans la liste Exclusion Filters → Extra AppOps et cochez AUTO_REVOKE_PERMISSIONS_IF_UNUSED.
  2. Retour sur l'écran principal, tapez AUTO_REVOKE_PERMISSIONS_IF_UNUSED dans la barre de recherche supérieure. Assurez-vous que la recherche approfondie est activée dans les paramètres de recherche.
  3. Définit le mode Autoriser ou Ignorer pour toutes les applications que vous voulez.

Vous pouvez également utiliser Permission View ou Batch Operations à la place des étapes 2 et 3. Voici un guide sur la façon dont vous le feriez en utilisant des opérations par lots :


Pourquoi ai-je beaucoup de popupons "Mauvais ROM" ?

Les OEMs apportent d'énormes modifications au code AOSP (développé par Google). Donc le framework AppOps sur certains OEM personnalisés / ROMs retourne des résultats inattendus que PMX ne peut comprendre. Vous pouvez ignorer ces popups, mais cela signifie que la fonctionnalité est quelque peu limitée.

Vous pouvez désactiver ces popups dans ParamètresRéglages générauxDésactiver les toasts ROM mauvaises.

Voir Pourquoi PMX ne fonctionne pas correctement sur les systèmes d'exploitation OEM ou ROMspersonnalisés ?


Que font les boutons "Cacher de la liste" (sur appui long) ?

Ils ne font que cacher l'application ou la permission de la liste visible. Si vous ne voulez pas modifier une permission pour une application, vous pouvez la masquer. Et il n'apparaîtra pas pour aucune application. Pour le décocher à nouveau, allez dans les paramètres de Filtres d'exclusion.

De même, vous pouvez exclure une application de la liste visible si vous n'êtes pas préoccupé par ses permissions.

Cacher l'application de la liste visible Cacher la permission de la liste visible


Y a-t-il une liste complète de toutes les autorisations disponibles avec explication ?

Il n'y a pas de liste complète des permissions avec la description, au moins à ma connaissance. La version PMX Pro montre une brève description des autorisations manifest et AppOp.

Il y a des ressources tierces comme celle-ci par Izzy. Le site officiel du développeur d'Android et le code source sont également de bonnes sources d'apprentissage.

Avec chaque nouvelle version d'Android, de nouvelles autorisations sont ajoutées, et d'autres sont obsolètes. En outre, toutes les autorisations ne sont pas nécessaires pour être prises en charge par chaque utilisateur.


Comment utiliser l'appli dans un profil professionnel / un environnement multi-utilisateurs ?

La version Pro permet d'avoir des profils professionnels et plusieurs utilisateurs. Sélectionnez un utilisateur dans le menu déroulant.

Menu multi-utilisateurs


Comment PMX se compare-t-il à XPrivacyLua? Peuvent-ils se remplacer?

PMX n'est pas conçu pour remplacer mais pour complimenter des projets comme XPrivacyLua. Ils ont des objectifs de conception différents.

XPrivacyLua hate la fonctionnalité standard d'Android en se branchant à des API internes, en utilisant Xposed qui remplace certaines bibliothèques Android par les bibliothèques hackées. Ainsi, nous obtenons des fonctionnalités supplémentaires telles que l'envoi de fausses données aux applications et nous sommes informés des événements liés aux autorisations dont nous ne pouvons pas être informés par d'autres moyens normaux.

PMX d'un autre côté, n'est pas censé être un module de base. Il fournit un accès pratique à certaines API privilégiées que les applications normales ne peuvent utiliser. Ce n'est pas un piratage des fonctionnalités standards d'Android par quelque moyen que ce soit. La plupart des tâches accomplies par PMX peuvent également être exécutées à partir de la ligne de commande, à l'exception de quelques tâches comme la modification des permissions système fixes.

Le rootage et l' Xposed sont deux conditions obligatoires pour utiliser XPrivacyLua. PMX n'a pas besoin des deux pour la plupart. Les deux ne sont pas disponibles pour de nombreux appareils ou beaucoup d'utilisateurs ne les considèrent pas comme une option en raison des difficultés techniques impliquées. garantie annulée, échec de SafetyNet et autres problèmes.

Plus d'explications here et here.


Est-ce que PMX peut supprimer automatiquement les autorisations lorsqu'une application est fermée, comme Bouncer le fait ?

Oui. Voir Gardien de permission et Vérification programmée. Mais il n'utilise pas la fonction Accessibilité d'Android pour effectuer des taps / clics à l'écran au nom de l'utilisateur (même si c'est une bonne fonctionnalité sans nécessiter de configuration supplémentaire). PMX dépend des privilèges root ou ADB. Elle peut donc faire bien plus (voir Qu'est-ce que PMX?) que ce qui peut être fait en utilisant les fonctionnalités d'accessibilité.

Si vous utilisez ADB, et non root, Permission Watcher peut ne pas fonctionner sur certains appareils. Veuillez consulter les Limitations de ADB.


Puis-je être averti quand une nouvelle application est installée?

Oui. Voir Gardien de permission.

Depuis Android 8, il n'est pas possible pour les applications en arrière-plan (pas en cours d'exécution) de recevoir une notification sur la nouvelle application installée. Nous devons donc exécuter un service de premier plan (avec des notifications persistantes) pour recevoir cet événement. Ou vous pouvez envisager d'utiliser Vérification programmée pour garder les choses en place.


Quand une nouvelle application est installée, PMX peut-elle supprimer ses autorisations par défaut ?

Oui. Mais il n'y a pas de permissions à supprimer. Toutes les autorisations manifest révocables sont déjà révoquées et restent révoquées à moins que l'utilisateur ne leur accorde explicitement. En ce qui concerne AppOps , beaucoup d'entre eux n'apparaissent pas avant au moins une fois utilisé par l'application (par exemple VIBRATE et READ_CLIPBOARD). Beaucoup d'autres (par exemple READ_CONTACTS) ont déjà leurs permissions manifest correspondantes, comme indiqué. Il n'est donc pas prévisible au moment de l'installation de l'application que AppOps doit supprimer.

Mais une notification s'affiche lorsqu'une nouvelle application est installée (si vous utilisez Permission Watcher) afin que l'utilisateur puisse définir les permissions une par une ou appliquer un profil.


Pourquoi PMX requiert une autorisation INTERNET ?

La version standalone Pro nécessite une connexion internet pour la vérification de licence. Les autres versions peuvent fonctionner complètement hors ligne. Bien que l'application Play Store ait besoin d'une connexion internet pour la vérification des licences.

Utilisation optionnelle de la permission android.permission.INTERNET

  • Vérifier les mises à jour de l'application. Vous pouvez désactiver cela dans les paramètres de l'application.

Utilisation locale (sur appareil) de la permission android.permission.INTERNET

Android n'autorise pas les applications à créer des sockets réseau sans avoir la permission INTERNET même si elles sont destinées à être utilisées uniquement localement et non pour une connexion Internet. PMX a deux utilisations de connexions locales (sur le périphérique) (la possibilité de créer des sockets localhost à 127.0.0.1) pour la Communication Inter Process (IPC) :

  • PMX démarre un processus en arrière-plan avec les privilèges root / ADB et parle à ce processus via le socket réseau. Après la poignée de main initiale, les deux processus commencent à parler de Binder. Nous n'avons pas de meilleur moyen de le faire parce qu'Android ne permet pas non plus aux applications de parler des sockets de domaine UNIX.
  • Si votre appareil n'est pas rooté et que vous utilisez PMX avec ADB, la connexion à adbd nécessite des autorisations internet. Voir L'espionnage de PMX est-il sur moi en utilisant ADB sur le réseau?

Donc, si l'application est incapable de créer ou d'utiliser des sockets réseau local, cela échouera. Et si vous voulez empêcher PMX d'utiliser Internet, cela ne doit pas empêcher l'application de parler avec les processus sur l'appareil via l'interface de bouclage pour IPC. C'est généralement le cas avec les pare-feu basés sur iptablescomme Fyrypt et les pare-feu VPN comme NetGuard. Mais certains ROMs ont une fonctionnalité intégrée pour interdire l'accès au réseau :

Autoriser les paramètres d'accès au réseau

Cela empêche non seulement l'application d'utiliser Internet, mais désactive également sa capacité à créer des sockets de bouclage pour IPC. Donc PMX ne pourra pas obtenir les privilèges root / ADB si cette permission est refusée.


PMX , c'est cool pour la confidentialité ? Est-ce que vous collectez les données des utilisateurs ?

Non. Nous ne collectons pas vos données. Jamais. Pas même un seul octet. PMX a une version open source. Nous croyons que nos utilisateurs sont éduqués et bien informés de la raison pour laquelle ils utilisent PMX. Nous respectons votre vie privée, donc aucune donnée n'est recueillie jamais, même les journaux de plantage. Vous pouvez également consulter notre Politique de confidentialité.


Est-ce que l'espionnage PMX sur mon réseau utilise ADB?

Non.

PMX parle au processus adbd via localhost (127.0.0.1). Mais il n'y a aucun moyen de commencer adbd à écouter sur localhsot seulement, et pas sur les autres interfaces réseau (car ADB est destiné à être utilisé en externe depuis un PC). Vous pouvez certainement arrêter l'écoute adbd depuis des adresses IP externes, si vous le pouvez. PMX fonctionnerait toujours, sans qu’aucun port ne soit exposé à l’extérieur.

Vous pouvez également changer le port 5555 à n'importe quel numéro dans les Réglages Avancés. Ce n'est pas codé en dur.

Aussi ADB depuis Android 4.2 est destiné à être protégé avec l'authentification par clé RSA (un des mécanismes d'authentification les plus forts). Ainsi, même si l'appareil est accessible à partir d'Internet (ce qui est fortement unlikely ), personne ne peut faire une connexion ADB sans authentification.

Vous pouvez vérifier ces allégations comme vous le souhaitez. Nous sommes là pour vous aider techniquement.


Est-ce que PMX utilise les privilèges root pour collecter mes données ?

Nous croyons au principe du moins de privilèges. Mais en raison de la nature restreinte du système d'exploitation Android, PMX ne peut pas fonctionner sans avoir des privilèges élevés. Ce que nous pouvons vous offrir, c'est si vous êtes une personne avisée de la technologie, nous pouvons vous apprendre comment rendre difficile pour les applications de se connecter à Internet, même avec les privilèges de root.


Je pense que PMX est inutile. Pourquoi a-t-elle été créée?

Nous respectons votre opinion. PMX n'est pas pour tout le monde (et c'est pour ça qu'il n'a pas été peaufiné et sorti pendant des années, parce qu'on savait qu'on avait un public super restreint). Ce n'est que pour certaines âmes de technologie supplémentaire qui sont très conscientes de leur vie privée et du contrôle de leurs appareils. La majorité des utilisateurs du téléphone sont entre les mains de leurs OEMs et de leurs développeurs d'applications. Ils ne sont pas au courant de ce qui leur est fait et de leurs données. La majorité préfère la commodité au respect de la vie privée. Et c'est très bien.