[APP][7.0+] Permission Manager X - manage AppOps and manifest permissions

Search This thread

doggydog2

Senior Member
Good point. Actually it's no way a problem for PMX to drop permissions when it's already showing a notification for a new app. But there is nothing to drop when a new app is installed. All the revokable manifest permissions are already revoked until the user does not grant them. And the AppOps: many of them don't appear until at least once used by the app e.g. VIBRATION and READ_CLIPBOARD. Many others have their corresponding manifest permissions e.g. READ_CONTACTS, which are already revoked, as pointed out.

Profiles / templates is an upcoming feature. We are working on it.


Contacts cannot be read in background without the permission explicitly granted by the user. And even after that, Schedule Checker is there to remind you that you haven't reviewed a newly installed app so far.

Thanks for the feedback. It's appreciated.
Thanks. I hope the templates will be applied to new apps not just to all (or selected) apps per request. By dropping permissions i ment disabling as many appops as possible, rendering user choices ineffective (thanks to "ignore" setting). Because once again, the lazy users don't care, they just click "yes yes yes". Both mentioned apps do this right after app installation and it works quite well. Thanks for your work, I will watch the changes and happily test the new builds.
 
  • Like
Reactions: mirfatif

mirfatif

Senior Member
Oct 18, 2016
680
459
t.me
the lazy users don't care, they just click "yes yes yes"
Privacy cannot be enforced on those who aren't conscious about it :)

Both mentioned apps do this right after app installation and it works quite well
XPrivacyLua does not set permissions. That does something entirely different. See https://mirfatif.github.io/PermissionManagerX/help/help#faq24.

For AppOps, there are nearly 100 AppOps in AOSP code (and OEMs may add more). So all of them should be ignored for every new app? Because, as I already mentioned, system reports only a few AppOps (for new apps) which have their corresponding manifest permissions already revoked. Other AppOps are associated to the apps when they use them at least once. So at the time of app installation it's not predictable which AppOps should be ignored. However user may apply one of the multiple Profiles they already defined, to the new app.

I will watch the changes and happily test the new builds.
Thank you. Beta builds are released in Telegram group. You may want to join us there too.
 

doggydog2

Senior Member
Privacy cannot be enforced on those who aren't conscious about it
I respectefully disagree, users desperately need help and second judgement over permissions:) I use AppOps and XPrivacy for the same purpose (doesn't really matter there are 2 approaches). Yes in my mind the new apps should get all/template manifest permissions revoked in your app, in order to watch it by the Scheduled Checker. That should make sense now.

Nice FAQ really. I see the profiles is the sweet functionality to look for:
"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)."
 
Last edited:

doggydog2

Senior Member
permissions
Re UI, the permissions are mentioned 2 times (or even 3x if there's a checkbox - that's probably a normal permission not AppOp) which is pretty confusing. I dont see a point in keeping both normal and uid. All of these couples have different values in my case. Now i set the reference for one of them, and the other one will trigger alert because it's unset. So i need to sync around 1000 permissions manually (before even going to next step - references).

references
Not sure why references even exist. Why simply what is currently set isn't a reference already. Set it, and start watching. That's it.
When a reference is set, it is only valid for ONE app (so possibly several 1000 combinations). Quoting FAQ, this kind of reference setting will take waaay more than a Sunday:
Suppose you spent a whole Sunday setting wanted permissions on 200+ installed apps
;) I could set all references for one app tho (that will take a weekend only). I wouldn't mind having function to set all references for all apps. Exactly the feature of LSPosed the users beg for (Select all)..hehe.

But the best would be to long click on a permission (or in a separate window) and set a GLOBAL reference (with either the currently visible value apply to all apps or apply value currently set per each app). That would be half of Sunday job and easily the fastest way.
Or have templates to apply to all apps, then tweak couple of apps manually.

I'm now stuck, because there's no way of transitioning in a reasonable time. Current approach is way slower than wgat XPrivacyLua or AppOps app, or LineageOS privacy app, or basic permission settings offer. I support the app and hope to get some ideas in the future. Unfortunately, Telegram registration failed for me, so i watch GIT.
 

xyzqwerty500

Senior Member
Oct 10, 2020
61
2
Can somebody tell me in which file are these appops stored? I have android 6 and this app requires android 7. I will manually update the file.
 

mirfatif

Senior Member
Oct 18, 2016
680
459
t.me
Can somebody tell me in which file are these appops stored? I have android 6 and this app requires android 7. I will manually update the file.
AppOps are stored in /data/system/appops.xml. But do not edit this file directly. Instead use appops cmdline tool. Also PMX is not only about AppOps. It also sets manifest permissions which you can set with pm cmdline tool.
 

xyzqwerty500

Senior Member
Oct 10, 2020
61
2
AppOps are stored in /data/system/appops.xml. But do not edit this file directly. Instead use appops cmdline tool. Also PMX is not only about AppOps. It also sets manifest permissions which you can set with pm cmdline tool.
Here in this file only. How can I identify which <op n=""> is which appops code. Can you provide me the list?
 

mirfatif

Senior Member
Oct 18, 2016
680
459
t.me
Here in this file only. How can I identify which <op n=""> is which appops code. Can you provide me the list?
There's no standard list. It changes with every Android release. OEMs and custom ROM developers can also add or remove AppOp permissions.

I want to turn off this BOOT_COMPLETED permission for many apps. pm revoke com.google.android.apps.docs android.permission.RECEIVE_BOOT_COMPLETED. But it fails.
BOOT_COMPLETED is not an standard AppOp. android.permission.RECEIVE_BOOT_COMPLETED cannot be changed because its protection level is "Normal".

Please see:
 

Top Liked Posts

  • There are no posts matching your filters.
  • 13
    banner.png


    eXtended Permission Manager - a small app to manage permissions and AppOps.

    Features:

    Using eXtended Permission Manager, for each installed app, on single screen, you can:
    • View, grant or revoke manifest permissions
    • View AppOps permissions and choose one of multiple modes
    • Set your desired reference value for every changeable permission

    The app evolved from a shell script to a GUI for my personal needs. After a ROM upgrade or changing device, it's a time-taking process to review all installed apps for granted permissions and revoke the unnecessary ones (after all privacy matters). To come up with a solution, you can set reference states of permissions which can be quickly backed up and restored. Colored bars at left indicate reference states and make it quite easy to review packages and permissions at a glance.

    Manifest permissions are those normally called permissions e.g. Storage, Camera etc. AppOps (app operations) is a robust framework Android uses at back end for access control. With every Android release manifest permissions are becoming more dependent on AppOps. So it's fun to control both simultaneously and see how they relate to each other.

    In short, AppOps provide a fine-grained control over many of the manifest permissions. Plus it provides additional controls like background execution, vibration, clipboard access etc. Explore the app to see more.

    And yes, the basic functionality of Permission Manager X is completely free and open-source. No ads, no trackers, no analytics. You are encouraged and requested to support the development. Source code is available at below Github link.

    Required Privileges / Permissions:

    • In order to let Permission Manager X serve you at its best, either the device must be rooted or you need to enable ADB over network.
    • android.permission.INTERNET is required to use ADB over network. The only connection made outside the device is to check for app updates.
    Download & Screenshots:
    XDALabs |
    Github (Free) | PlayStore (Paid)

    Guide / Help:
    3
    Thanks for a well thought out useful app
    Used it when switching to Android 11 on a new device. Was able to achieve required permission state in a few minutes 👍
    1
    mirfatif thank you for providing this app!
    Would it be possible to use this app to forbid apps to run at start-up?
    If yes, how?
    1
    Extremely useful app, this thread should get much more interest.

    Thank you @mirfatif!

    Also great to have it available on F-Droid!
    1
    So if i understand correctly, the permission enforcement is there as the periodic check can notify or even fix the permissions.
    Yes you are correct. Both Schedule Checker and Permission Watcher help you enforce permissions.

    Now the second important aspect: enforce newly installed apps. In this case, there's just notification? I'd find it extremely useful to be able to drop all (a la XPrivacyLua) or selected permissions (via template a la AppOps app) from the new app until it's manually reviewed
    Good point. Actually it's no way a problem for PMX to drop permissions when it's already showing a notification for a new app. But there is nothing to drop when a new app is installed. All the revokable manifest permissions are already revoked until the user does not grant them. And the AppOps: many of them don't appear until at least once used by the app e.g. VIBRATION and READ_CLIPBOARD. Many others have their corresponding manifest permissions e.g. READ_CONTACTS, which are already revoked, as pointed out.

    Profiles / templates is an upcoming feature. We are working on it.

    Not only because the new apps get often started asap and do their antiprivacy stuff, but also because some lazy users will simply won't review them at all, and let for example, Facebook malware grab contacts asap.
    Contacts cannot be read in background without the permission explicitly granted by the user. And even after that, Schedule Checker is there to remind you that you haven't reviewed a newly installed app so far.

    Thanks for the feedback. It's appreciated.