It's the eXtended Permission Manager app for Android which makes it easy to set and review desired permissions on installed apps, keeping track of any unwanted changes. Giving control on your device, it enables you to protect your privacy and save your resources like battery usage.
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.
Using PMX you can:
Also see Github README and detailed app description on Play Store. Or try it out. It's free, for the most part.
Both are the underlying permission control mechanisms in Android operating system.
Manifest permissions are called so as the app needs to request them in its AndroidManifest.xml file. You can allow an app to use Camera or read your Contacts, right? Both are the manifest permissions: android.permission.CAMERA and android.permission.READ_CONTACTS.
But what if you want to allow the app to use the Camera or read your Contacts only when the app is being used in foreground? Or what if you want to disallow an app to make Vibrations or to read Clipboard? It's achieved through AppOps. In short, AppOps provide some extra and more fine-grained control over normal permissions.
Manifest permissions are not always changeable depending on their protection level and the privileged state of the app. For instance:
You cannot revoke an app's android.permission.INTERNET because it has Normal protection level. Neither Internet permission has a corresponding AppOp permission.
android.permission.VIBRATE is another manifest permission with Normal protection level. But it does have a corresponding AppOp permission which you can allow or deny.
"android.permission.SET_TIME_ZONE" is a permission with Signature protection level, so it cannot be granted to the apps installed by the user.
With every coming release both types of permissions are being tightly integrated. For instance in recent Android releases apps cannot use Microphone from background. It's achieved by making use of both manifest and AppOp permissions.
PMX shows you a complete list of manifest and AppOp permissions an app is using, in a plain simple list. So that you can know and control them the way you want.
Suppose you spent a whole Sunday setting wanted permissions on 200+ installed apps. And:
Will you go through the who hassle once again?
No you don't need to. You can make PMX remember your desired permission states. Set a permission, make it GREEN, and done. It will take only a few moments to look at all installed packages and figure out which permissions aren't correctly set e.g. by making a quick search: ":RED|:ORANGE" or "!:GREEN". See Search for more details.
Reference states can be backed up and restored conveniently.
Long press a permission to set or clear its reference state.
Three reference states are:
ORANGE state indicates that no reference value is set.
GREEN indicates that reference value matches currently set value.
RED indicates that reference value and set value differ.
Colored strip at the left indicates reference state
First line shows package label
Second line shows package name and UID
Third line (optionally) shows package's state: Critical (Framework), Framework or System app. Also if the app is Disabled. No state is shown for Enabled, User apps.
Last line shows count of visible out of total manifest permissions and AppOps permissions. Invisible permissions are those excluded in Exclusion Filters.
In case of quick scan this line shows package UID.
If sorted by install or update time, this line also shows date on the right side.
Colored strip at the left indicates reference state
First line shows permission name
Second line shows permission's protection level: Normal, Dangerous, Signature, Development, Privileged, Fixed, AppOps or Unknown. Also if AppOp is per Package or per UID. And if it is an Extra AppOp (never excluded in filter settings).
Third line (in case of AppOp) shows last access time
Fourth line (in case of AppOp) shows the referenced value if it doesn't match the current set value.
If an AppOp is never set, word: Default is shown below currently set value.
Normally package label, name and UID are searched from visible list.
With Deep Search, permission name and other parameters are queried.
Note that the Exclusion Filters are effective when making search.
You can use the following special keywords in search:
:Critical :Framework :System :User :Disabled
:ORANGE :GREEN :RED
Permissions protection level:
:Normal :Dangerous :Signature :Internal :Development :Privileged :Fixed :AppOps :Unknown
Per UID AppOps:
AppOps with last access time:
Extra AppOps (never excluded in filter settings):
& (AND), | (OR) and ! (NOT) operators:
Paid version also shows search suggestions (if set in preferences) to ease the search process.
Do you want to keep track of any unwanted changes to the permissions for all the installed apps? Scheduled Check can do this for you at regular intervals (in minutes, hour or days).
Set Permission References to GREEN and leave the rest to PMX. If any permission is found changed (with RED state) or when a new app is found installed (with ORANGE state permissions), PMX reminds you that something needs your attention.
Additionally, if configured in preferences, Scheduled Check can auto-revoke granted permissions with an informatory notification.
Some apps do not work without having a certain permission granted. But you want to grant the permission for the time only when you are using the app, and revoke the permission as soon as you leave the app.
Permission Watcher does exactly this. As soon as you leave the app, or after the set time has passed, it revokes an app's permissions (manifest and AppOp) on its own, or asks you to do so, depending on the preferences you've set.
Permission Watcher also notifies you to set permissions on newly installed apps (in primary user / owner profile only).
Only the permissions with "RED" reference state are revoked, not those with the "ORANGE" state. So you MUST first set the reference states. See Permission References.
Manifest permissions only with Dangerous protection level are watched. Those are the ones usually changed. Permissions with Signature|Development protection level or those with System-Fixed flag set are not watched, though they are changeable.
PMX watches only User-installed or normal System apps, not Framework apps. Changing them might brick the device.
On some devices Permission Watcher may not work reliably for apps in the secondary user / profile. Using it in combination with Scheduled Checker is recommended.
Why starting Permission Watcher fails?
Are you using ADB? Some OEMs remove permission OBSERVE_GRANT_REVOKE_PERMISSIONS or SET_ACTIVITY_WATCHER from Shell package. If this is the case with you, we are sorry. This is something we cannot fix. On such devices Permission Watcher can work only with root. See the note at the start of Using PMX with ADB.
PMX is integrated with WhatsRunning so you can open one from the other.
So from PMX you can switch to WhatsRunning to find out if an app with restricted permissions is still running. If yes, in what state it is and how much resources it is using.
Similarly, from WhatsRunning you can switch to PMX to find out what permissions a running (or dead) app is granted.
This is particularly helpful when analyzing the effect of permissions like
ADB is not as powerful as root is. In our case, for instance, PMX takes more time to build the list of apps when it's running with ADB.
Additionally, on some OEM ROMs the ADB functionality might be crippled due to lacking permissions or other restrictions. You can check the current status of what ADB can do in About -> Privileges (menu item):
Unfortunately we cannot do anything about it. And therefore some features are available only on rooted devices.
However some OEMs add extra settings to control ADB's privileges. For instance you need to uncheck "Disable Permission Monitoring" on Oppo phones and "Allow granting permissions" in Security Settings on Xiaomi phones. See this question for more details.
The following instructions apply to near-AOSP ROMs. Customized ROMs might have different or missing settings.
So here we start how you can make PMX work with ADB.
If your device is not rooted, you need to turn Wireless ADB on before using PMX. Some devices have ADB over Network or Wireless Debugging setting available in Developer options:
For others, you need to connect the device to a USB host like PC once after every reboot.
Unhide Developer options screen:
Go to Settings -> About and tap Build number five to seven times.
Developer options should appear directly under Settings or in Settings -> System at the bottom.
Enable wireless debugging:
Enable Android debugging in Developer options.
Connect the device to the PC with a USB cable.
On PC open a terminal window (or command prompt on Windows) and run:
adb tcpip 5555
You must have
adb executable available on your PC to run the above command. If not, here's the download link.
Optional steps for verification:
Disconnect the USB cable from the device.
Connect your device and PC to a common Wi-Fi network.
Get the IP address of the device (usually in WiFi settings or in Settings -> About), say it's
On PC run:
adb connect 192.168.1.1
adb shell id -u
It should print
Leave the Android debugging enabled. Run PMX app and check ADB Shell in drawer. It should connect to ADB. Allow USB Debugging if asked:
For more details see this.
On Android 11 and above, it's possible to turn on Wireless ADB without connecting to a PC.
Install Termux and grant Storage permission.
adb binary for your device e.g. from here or whatever source you want. Let's say it's downloaded to the default Download directory (
Connect your device to a Wi-Fi network.
Open Termux and Developer Options in Split-Screen mode.
Enable Wireless debugging and Disable ADB authorization timeout.
Open Wireless debugging and tap on "Pair device with pairing code". Note the port number and pairing code.
Switch to Termux and run:
cp /sdcard/Download/adb.bin ./adb (Copy the file)
chmod a+x adb (Make it executable)
./adb pair 127.0.0.1:41719 (Enter your port number)
Enter the pairing code.
Run (this step might be unnecessary):
./adb connect 127.0.0.1:40901 (Replace the port number)
./adb tcpip 5555
Now you can leave Wireless debugging enabled. Or disable it and enable USB debugging. Open PMX app and start using.
Once after every reboot you need to repeat the last two steps (9 and 10).
For more details see this and this.
PMX is available in two variants: Paid and Free.
Paid version is available in two variants: Play Store and Pro.
Paid version is released on Play Store and Github. Free version is released on GitHub, F-Droid and some other sources. Latest APKs for both variants are also posted in the Telegram Channel.
There's no free version on Play Store.
Pro version can be installed along with any other version on a device. But no other two versions can be installed together (due to same package name). One must be uninstalled before installing the other one.
Free version available on IzzySoft is the same as released on Github and posted in the Telegram channel. But the one available on official F-Droid repo has different signatures. So it cannot be installed over the former two, and vice versa.
In between the major releases some test (beta) releases are also published in the Telegram channel only.
You can update the Play Store version to the latest stable release either from Play Store or by installing the APK file posted in the Telegram channel with -ps in the file name. Sometimes Google team may take up to 24 hours before the update is live in Play Store.
You can update the Pro version to the latest release by installing the APK file from Github or the Telegram channel with -pro in the file name.
You can update the Free version to the latest stable release either from GitHub (or F-Droid; from wherever you installed it) or by installing the APK file posted in the Telegram channel without -ps / -pro in the file name.
Paid version installed by merely downloading the -ps.apk or -pro.apk file from the Telegram channel won't work if you haven't purchased the app.
Once a new version is available for update, PMX app - when launched - shows a notification to download the update (provided that you've enabled the update check in settings). Play Store app also shows update notification according to your settings.
If you've already downloaded and installed the latest release from the Telegram channel, you won't get update notification in the app and Play Store won't show update available.
Free version is completely open-source and free. Source code is available on GitHub. Anyone can view and download the code and build the app. We respect users' privacy, so there's nothing hidden, there are no back-doors, no trackers, no ads. And we don't collect users' data and information for any kind of analytics, profiling or for the sole purpose of selling. Even submitting a crash report is also at user's discretion, though highly recommended.
One can purchase the paid version just to make a donation and/or to use the paid-only features. Other methods of making a donation are available in the Free / Pro version under Donate section. Developers can also support the app development by contributing to the source code e.g. by fixing a bug. Users can help us make the app better by testing the beta releases, reporting any crashes or glitches, suggesting improvements and new features, or translating the app to their native language.
Paid version includes everything that's in the Free version, plus the following extra features which are also listed in the app under About section and in the Play Store description:
Please also see What is PMX?
Android won't allow a normal user app to change other apps' manifest or AppOp permissions, even its own. Only reading AppOps without root or ADB is possible provided that hidden APIs are not blacklisted on your device, which is very unlikely on Android 9+.
That's why we run a separate process with high privileges to circumvent the restrictions.
By default, the background process (daemon) is run with ADB UID (
2000) or (if rooted) System UID (
1000). On rooted devices UID can be changed in Advanced Settings.
Use PMX with ADB. Please do read the note at the start. There might be some limitations on some devices.
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.
After changing a permission successfully, if you are not getting the desired results, it's the Android operating system to be blamed. Please see How does PMX change other apps permissions?
Usually they are AppOp permissions. 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 targeting old Android version. Also some OEM ROMs behave weird when it comes to AppOps. We do not know exactly what changes your OEM has made to the stock AOSP code. That's why the statement on Github and Play Store: "The app is tested on stock Android 7-11. Some highly customized ROMs may behave unexpectedly."
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: What are different AppOp modes and which one should I use?
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.
The core functionality of PMX revolves around Hidden APIs. These are the capabilities required to perform tasks (like granting / revoking permissions) which can only be performed by privileged system apps. So these capabilities aren't available to normal user apps. But PMX uses these capabilities with the help of root or ADB. If "Use Hidden APIs" is checked, the app tries to use some of these capabilities without the help of root or ADB. But this is not very likely to work on Android 9+, so the box is auto-unchecked. Usually a user should not be concerned about this.
If you are interested in underlying details please read here.
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.
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.
Please check Exclusion Filters. Permissions which are not changeable are excluded from the visible list by-default.
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.
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.
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.
Normally you should Allow or Ignore. Or you may want to allow an operation only when the app is in Foreground (only on Pie+). 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 permissions revert to their old state soon after changing them?
Official documentation: AppOpsManager.
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.
READ_MEDIA_[AUDIO|VIDEO|IMAGES] are recent addition to AppOps list, added in Android 10 (IIRC) as a part of Android's Scoped Storage implementation. Source code states: Read media of audio type. In simple terms it controls apps (which use MediaStore) access to audio files in external shared storage.
Apps hold wakelock to keep the device awake i.e. not entering Doze mode.
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.
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.
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|Privileged, or those of framework app. But it's not recommended to play with the System and Framework apps. You can brick your device.
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.
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.
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.
PMX gets a lot of information about apps. It includes package label, name, icon, UID, and its state (framework, system, user, disabled). For manifest and AppOp permissions the information includes permission name, state (granted, revoked, allow, ignore, deny, foreground, default), protection level (normal, dangerous, signature, development, privileged, fixed, AppOp) and AppOp's last access time. Then the set value of every permission is compared with the reference value and the reference state is decided (red, green or orange). After scanning all the permissions for every app, the count of visible vs total permissions and app's reference state is also shown in package information.
You can turn on Quick Scan in settings to disable permissions scan. Or exclude as much information as you can in Exclusion Filters to speed up the scan process. Speed also depends on how much CPU and RAM your device spares for the apps. ROMs investing more on UI (like MIUI) are slower. Also ADB is usually slower than root.
There's no complete list of permissions with description, at least in my knowledge. For some manifest permissions there is a brief description available which is shown when you tap a permission name in PMX app. For AppOps there's no description provided in Android.
There are third part 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.
Paid version supports work profiles and multiple users. Select a user from drop-down menu.
Join the translators team on Crowdin. Let me know which language you are interested in and I'll add that to the project.
Major translators will be credited by adding their names to the app in About section.
No. It's not currently planned.
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 mod. 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.
Here's a related issue.
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 read the note given at the start of Using PMX with ADB.
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 Checks to keep things in place.
Yes. But there's nothing 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. VIBRATION 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 (upcoming feature).
As clearly stated in the app description:
android.permission.INTERNET permission is required to make use of ADB over network. The only connections made outside the device are to check for updates (which you can disable in app settings) and to fetch help contents (this webpage). Pro version also requires internet connection for license verification.
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.
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.
You are correct. 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. And it's fine.
Please visit Github README.
Please contact us via email or Telegram.