Skip to content

PMX FAQs

Why do I need to use PMX?

Because:

  • PMX provides all the scattered (or otherwise unavailable) permission-related information and controls on a single screen so that you can watch and control them in a comprehensive and convenient way.
  • There's no official tool available in stock Android to change AppOps. Only a subset of manifest permissions are exposed to user in permission settings. PMX exposes all the permissions in raw form. Related: Manifest permissions and AppOps.
  • PMX makes it easy for you to keep track of any unwanted changes to permissions.
  • Giving control on your device, PMX enables you to save device resources like battery and network bandwidth, and protect your privacy. You are not entirely left to the mercy of app and ROM developers. Read this article to get an idea.
  • PMX can monitor permission changes in realtime, reverting them automatically when you stop using an app. Or it can perform scheduled scan of permissions. So you don't have to remember things.
  • PMX makes it easy for you to backup and restore permissions state of installed apps so that you don't have to tweak an app's permissions again and again.

Please also see What is PMX?

Why PMX requires root or ADB access?

Android intentionally restricts apps from modifying other apps' manifest or AppOps permissions (and in many cases from changing some of their own). These platform safeguards protect user privacy and system integrity.

To perform actions that require elevated privileges, PMX uses a small, separate privileged helper rather than trying to do everything from the normal app process. By default that helper runs under the ADB UID (2000) when started via ADB, or under the System UID (1000) on rooted devices. If you have a rooted device, you can change the helper's UID in Advanced Settings.

My device isn't rooted. How can I use PMX?

Use PMX with ADB. Please do read the note at the start. There might be some limitations on some devices.

Why does PMX not run or work properly on the latest Android?

PMX relies on Android's hidden APIs or non-SDK interfaces which are not documented (on Android Developers) unlike standard APIs. So with every new Android release, we have to go through the Android source code to find out which APIs have broken (changed or removed).

Also, it takes time to fix the broken APIs; sometimes weeks, sometime months. And it's not guaranteed that we'll always be able to fix the broken APIs. Sometimes Google on purpose makes it difficult or impossible for us to keep using the hidden APIs.

Therefore it's not possible for us to make the PMX immediately work on every new Android release (particularly in beta phase) as long as the final AOSP source code is not publicly released (on Code Search or Git Repository).

PMX's final supported Android version is stated in app description on GitHub and Play Store. When you run the app on an unsupported version for the first time, it shows a warning like this:

Unsupported Android version warning

Why does PMX not work properly on OEM operating systems or custom ROMs?

PMX relies on Android's hidden APIs or non-SDK interfaces which are not documented (on Android Developers) unlike standard APIs. So we need access to the source code of your ROM to know exactly how the hidden APIs work.

Well, AOSP (which is developed by Google) is open-source. But if your OEM or ROM developer makes some changes to AOSP for the customization purpose, we've no way to know exactly what changes they have made to the stock AOSP code. We're quite helpless here. And this fact is stated in app description on GitHub and Play Store. Sorry.

How does PMX change other apps permissions?

PMX itself cannot and does not grant or revoke other apps' permissions. In fact no third party app is privileged to do that. It's the Android OS which controls apps' permissions. PMX just sends a request to the Android framework to change a permission's state. Now it's entirely up to Android how much it honors our request. Not all permissions are changeable. And if you are not able to change a permission's state using PMX, you won't be able to change it in any other way either.

Do the permissions remain changed after ADB is turned off, or root is denied, or PMX is uninstalled?

PMX itself cannot and does not grant or revoke other apps' permissions. In fact no third party app is privileged to do that. It's the Android OS which controls apps' permissions. PMX just sends a request to the Android framework to change a permission's state.

So once a permission is changed, it makes no difference if you uninstall PMX or drop its privileges. The permission remains in whatever state it is, unless changed again by you or the operating system.

Why can't I change XYZ permission?

Manifest permissions with only Dangerous protection level (and a few others) are changeable. AppOps not dependent on some other AppOp are changeable. That's how Android works, we can't change the behavior. See Manifest permissions and AppOps.

Additionally, PMX protects some critical framework apps and permissions; changing them might brick the device. See the related question.

Also see Why do some AppOps cannot be changed?

Note that starting with Android 15, manifest permissions of system apps with Development protection level cannot be revoked. Android silently ignores the request.

I've changed a permission but it's not working. Why?

After changing a permission successfully, if you are not getting the desired results i.e. it reverts back immediately or after some hours or days, it's the Android operating system to be blamed. Please see:

As you use apps, Android may change their permissions. And unfortunately we do not have a way to prevent this. Permission Watcher and Scheduled Checker may help in this regard.

Why do some AppOps cannot be changed?

Sometimes you see "AppOp mode not changed". It means that Android rejected the request to change the AppOp mode. You cannot change it no matter what method or app you use. There could be multiple possible reasons.

  • Some AppOps are dependent on their corresponding manifest permissions. So they cannot be changed independently. For instance you may not be able to deny READ_CONTACTS AppOp if android.permission.READ_CONTACTS manifest permission is granted.

    Also if the app has not requested the manifest permission in its manifest file, its AppOp permission can also not be granted. But it may still appear in the app's permission list if the app has tried to use it (and got rejected). SYSTEM_ALERT_WINDOW is one such example.

  • Some AppOps are only used by Android for compatibility (e.g. LEGACY_STORAGE) and they don't actually control anything. If we explore their underlying working it's revealed that granting / revoking such permissions doesn't make sense.

  • Some permissions cannot be changed if the app is running on or is targeting an older or newer Android version.

  • Some OEM ROMs behave weird when it comes to AppOps. See Why does PMX not work properly on OEM operating systems or custom ROMs?

  • Many AppOps can have 2 modes: package mode and UID mode. It's possible that one can be changed while the other cannot be.

    Usually UID AppOps take precedence over their package AppOp counterparts. In this case the effective mode of the package AppOp is same as that of its UID AppOps. So you cannot change the package AppOp alone.

    Some AppOps prefer to be set in package mode, not UID mode. But if it's wrongly set in UID mode (with commandline tool or by some other app), it becomes non-responsive to any changes. Do "Reset AppOps" from top right menu to make it work again. This is also the case with other AppOps which have a corresponding manifest permission with AppOp protection level.

Actually there come many more explanations if we dig every app and permission individually (which doesn't sound practical). As stated above, PMX doesn't change other apps' permissions on its own. So even if for some unknown reason Android doesn't change a permission, or reverts it back immediately, there's nothing we can do to force it because these are the limitations at Android end. Rather, I should say this is how Android works.

Related:

Why don't I see XYZ app in packages list?

Please check Exclusion Filters. Almost all the stock Android packages are excluded by default. You can exclude / include any package you want from / to visible list.

Why don't I see XYZ permission in ABC package?

Please check Exclusion Filters. Permissions which are not changeable are excluded from the visible list by-default.

Why don't I see XYZ AppOp in ABC package?

Please check Exclusion Filters if XYZ AppOp is excluded from the visible list. Or ABC package might not be using XYZ operation. You don't need to be worried about this.

But if you want to see the XYZ AppOp for all apps, go to Exclusion Filters → Extra AppOps, never excluded and check XYZ AppOp in the list.

For instance, write _CLIPBOARD in search box (with Deep Search box checked) and you'll get all apps which used (or tried to use) READ_CLIPBOARD or WRITE_CLIPBOARD permission. Timestamp is also shown (but not for all AppOps).

So if the app you are concerned about isn't in the search results, check both AppOps in the Exclusion Filters list mentioned above.

What should I select for Privileged Daemon UID in Advanced Settings? System or ADB?

It matters only if you are using root, or adbd on your device is running with root (which is not the case with the final user devices).

Preferably use System (UID 1000) as it allows more privileges than ADB (UID 2000). E.g. changing "System-Fixed" permissions is possible only when running as system.

What are "invalid permissions" in Exclusion Filters?

If an app is requesting a manifest permission but it's not declared (provided) by Android framework or any of the installed packages, it's an invalid permission. For instance com.android.vending.BILLING is an invalid permission if Play Store app is not installed on your device.

What are "extra AppOps" in Exclusion Filters?

Not all AppOps are being used for all installed apps. But you can enforce an AppOp to any app. Selected Extra AppOps appear in all apps' permission lists so that you can set them.

What are different AppOp modes and which one should I use?

Normally you should Allow or Ignore. Or you may want to allow an operation only when the app is in Foreground (only on Android 9 and above). Deny is the intense version of Ignore which may crash the requesting app. Default is the system's default behavior which differs for different AppOps.

Please note that not every AppOp mode can be possibly set on every AppOp for every app. For instance on recent Android releases CAMERA and MICROPHONE are allowed to be used by user apps only in foreground (even if set mode is Allow). Similarly, some AppOps can never be set to Foreground mode.

Related: Why do some AppOps cannot be changed?

Official documentation: AppOpsManager.

What's the difference between "Ignore" and "Deny" AppOp modes?

Ignore silently fails while Deny throws back an error to the app which the app might not be expecting and may crash. You should normally be using Ignore.

Why cannot I set AppOp mode to foreground?

Foreground mode cannot be set for all AppOps. Even when set, it may not give expected results.

Related:

Please note that the permission mode "Allow only while using the app" does not alway set the AppOp mode to "Foreground":

Foreground and one time permission modes

Normally we see only two states for a manifest permission: granted and revoked. But Android uses flags to split these two states into many sub-states. For some permissions the same phenomenon is used to achieve the "grant only when the app is visible" behavior. AppOp permission is not used in this case.

For more details see official documentation of background access and foreground access.

For simplicity, PMX does not watch permission flags at the moment. But in future an option might be added to also track changes to permission flags even if granted / revoked mode remains unchanged.

What does WAKE_LOCK permission do?

Apps hold wakelock to keep the device awake i.e. not entering Doze mode.

How can I change INTERNET permission?

Android doesn't allow changing all permissions, like those with the Normal protection level (e.g. INTERNET) or those with Fixed flag or Signature protection level (usually System or Framework apps). See Manifest permissions and AppOps.

But if you are rooted, Fyrypt gives you very strong control over network activity happening on your device.

What are Fixed permissions?

System-fixed permissions are granted to the preinstalled apps by the OEMs or ROM developers. They are not meant to be changed. But if your device is rooted, PMX can change system-fixed permissions.

Policy-fixed permissions are granted (or denied) by the IT admins on managed devices. They cannot be changed.

User-fixed permissions are fixed by the user. If a user denies a permission a few times when the app requests for it, the operating system marks the permission as user-fixed and shows no more prompts to the user to grant the permission if the app asks for the same permission again. This kind of fixed permissions can be changed easily whenever the user wants.

How can I change System-Fixed permissions, Signature/Privileged permissions, or the permissions of framework apps?

If your device is rooted, in paid version you can Allow Critical Changes in Advanced Settings to make changes to the permissions with the System-Fixed flag, protection level Signature or Privileged, or those of framework app. But it's not recommended to play with the System and Framework apps. You can brick your device.

What is "UID mode" in AppOp permissions?

It's a mode of an AppOp permission which indicates that changing this AppOp will also affect other apps (with the same UID), if installed. See sharedUserId.

Note that UID mode takes precedence over package mode for many AppOps.

Can I control Android's "Remove permissions if app isn't used" feature from PMX?

Yes. This feature is available since Android 11. It's also labeled as "Pause app activity if unused" on some devices.

Auto-remove unused permissions

To change this option from PMX:

  1. Go to Exclusion Filters → Extra AppOps list and check AUTO_REVOKE_PERMISSIONS_IF_UNUSED.
  2. Back on the main screen, type AUTO_REVOKE_PERMISSIONS_IF_UNUSED in the top search bar. Make sure that deep search is enabled in search settings.
  3. Set the mode Allow or Ignore for whichever apps you want.

You can also use Permission View or Batch Operations in place of step 2 and 3. Here's a guide how you would do it using Batch Operations:

Why do I get a lot of "Bad ROM" popups?

OEMs make huge changes to stock AOSP code (which is developed by Google). So the AppOps framework on some custom / OEM ROMs returns unexpected results which PMX cannot understand. You can ignore these popups, but they mean that the functionality is somewhat limited.

You can turn off these popups in Settings → General settings → Disable bad ROM toasts.

See Why does PMX not work properly on OEM operating systems or custom ROMs?

What do the "Hide From List" buttons (on long press) do?

They both just hide the app or the permission from the visible list. If you don't want to change a permission for any app, you may hide it. And it won't appear for any app. To unhide it again go to Exclusion Filters settings.

Similarly, you can exclude an app from the visible list if you are not concerned about its permissions.

Hide app from visible list Hide permission from visible list

Is there a complete list of all permissions available with explanation?

There's no complete list of permissions with description, at least in my knowledge. PMX Pro version shows a brief description of common manifest and AppOp permissions.

There are third party resources like this one by Izzy. Android's official developer site and source code are also good sources for learning.

With every new Android release some new permissions are added, and some also get obsolete. Also, not all permissions are needed to be taken care of by every user.

How to use the app in work profile / multi-user environment?

Pro version supports work profiles and multiple users. Select a user from the drop-down menu.

Multi-user menu

How does PMX compare to XPrivacyLua? Can they replace each other?

PMX is not designed to replace but to compliment projects like XPrivacyLua. They have different design goals.

XPrivacyLua hacks Android's standard functionality by hooking into internal APIs, using Xposed which replaces some Android libraries with the hacked ones. So we get extra functionality like feeding fake data to the apps and get notified of permission related events which we cannot know of by any other normal means.

PMX on the other hand is not targeted to be a framework module. It provides convenient access to some privileged APIs which normal apps cannot use. It's not hacking Android's standard functionality by any means. Most of the tasks PMX performs can also be performed from commandline, except a few like changing System-Fixed permissions.

Rooting and Xposed are two strict requirements for using XPrivacyLua. PMX doesn't require any of the both for the most part. Both aren't available for many devices or many users don't consider them as an option due to the technical difficulties involved, warranty void, SafetyNet failing and other issues.

More explanation here and here.

Can PMX auto remove permissions when an app is closed, like Bouncer does?

Yes. See Permission Watcher and Scheduled Check. But it doesn't use Android's Accessibility feature to perform taps / clicks on screen on user's behalf (though it's a good feature without requiring any extra setup). PMX relies on root or ADB privileges. So it can do far more (see What is PMX?) than what can be done using Accessibility features.

If you are using ADB, and not root, Permission Watcher may not work on some devices. Please see the Limitations of ADB.

Can I get notified when a new app is installed?

Yes. See Permission Watcher.

Since Android 8 it's not possible for background (not running) apps to get notified of the new app installed event. So we've to run a foreground service (with persistent notification) to receive this event. Or you may consider using Scheduled Check to keep things in place.

When a new app is installed, can PMX drop its permissions by default?

Yes. But there are no permissions to drop. All the revocable manifest permissions are already revoked and stay revoked unless the user grants them explicitly. As far as AppOps are concerned, many of them don't appear until at least once used by the app e.g. VIBRATE and READ_CLIPBOARD. Many others (e.g. READ_CONTACTS) have their corresponding manifest permissions already dropped, as pointed out. So it's not predictable at the time of app installation which AppOps should be removed.

But a notification is displayed when a new app is installed (if using Permission Watcher) so the user can set permissions one by one or apply a profile.

Why PMX requires INTERNET permission?

The standalone Pro version requires internet connection for license verification. Other versions can work completely offline. Though Play Store app needs internet connection for license verification.

Optional use of android.permission.INTERNET permission

  • Check for app updates. You can disable this in app settings.

Local (on-device) use of android.permission.INTERNET permission

Android does not allow apps to create network sockets without having the INTERNET permission even if they are meant to be used only locally and not for an internet connection. PMX has two uses of local (on-device) connections (the ability to create localhost sockets at 127.0.0.1) for Inter Process Communication (IPC):

  • PMX starts a background process with root / ADB privileges and talks to that process over network socket. After the initial handshake, both processes start talking over Binder. We have no better way to do this because Android doesn't allow apps to talk over UNIX domain sockets either.
  • If your device is not rooted and you use PMX with ADB, then connecting to adbd requires internet permissions. See Is PMX spying on me using ADB over network?

So if the app is unable to create or use local network sockets, it will fail. And if you want to stop PMX from using internet, it must not stop the app from talking to on-device processes over loopback interface for IPC. This is usually the case with iptables-based firewalls like Fyrypt and VPN based firewalls like NetGuard. But some ROMs have a built-in feature to disallow network access:

Allow network access setting

This not only prevents the app from using internet but also disables its ability to create loopback sockets for IPC. So PMX won't be able to get root / ADB privileges if this permission is denied.

How much privacy friendly PMX is? Do you collect users' data?

No. We do not collect your data. Never. Not even a single byte. PMX has an open source version. We believe in our users being educated and well-informed of why they are using PMX. We respect your privacy, so no data is collected ever, even the crash logs. You may also want to see our Privacy Policy.

Is PMX spying on me using ADB over network?

No.

PMX talks to adbd process over localhost (127.0.0.1). But there's no way to start adbd listen on localhsot only, and not on other network interfaces (because ADB is meant to be used externally from a PC). You can surely stop adbd listening from external IP addresses, if you can. PMX would still work, without any port being exposed externally.

Also you can change 5555 port to whatever number you want in Advanced Settings. It's not hard-coded.

Also ADB since Android 4.2 is meant to be protected with RSA key authentication (one of the strongest authentication mechanism). So even if the device is accessible from internet (which is highly unlikely), no one can make an ADB connection without authentication.

You can verify these claims in whatever way you want. We are here to assist you technically.

Is PMX misusing root privileges to collect my data?

We believe in the principle of the least privilege. But due to the restricted nature of Android operating system, PMX cannot function without having high privileges. What we can offer is, if you are a tech-savvy person, we can teach you how to make it difficult for apps to make internet connections, even with root privileges.

I think PMX is useless. Why was it created?

We respect your opinion. PMX is not for everyone (and that's why it wasn't polished and released to public for years because we knew we've a very small audience). It's only for some extra tech-savvy souls who are extra-conscious about their privacy and device control. Majority of the phone users are just in the hands of their OEMs and app developers. They aren't aware of what's being done to them and their data. Majority prefers convenience over privacy. And it's fine.