[Feature Request] Permission removal without root like Bouncer about permissionmanagerx HOT 5 CLOSED

Thanks for the suggestion. If I understand it correctly what you are asking for is very limited as compared to what PMX can do. Let me try to explain.

What I understand is that the app you mentioned uses Accessibility to perform taps/clicks on user's behalf. In general context I'd call it AccessibilityApp in following lines. AccessibilityApp registers itself to get notified of the event when an app requests the user to grant a permission. If user grants the permission, AccessibilityApp asks the user if they want to revoke it automatically after the app goes to background. If the user agrees, AccessibilityApp waits for the next event when the user taps Home/Back button. AccessibilityApp then opens the app's info screen and revokes the permission previously granted by making taps on user's behalf.

This means that AccessibilityApp can automatically revoke only those permissions which can also be revoked by the user manually by opening the app's info screen. That's a really good feature, which spares the user of the hassle of manually revoking permissions after using the app, but PMX is not targeted to do that exactly. Using PMX you can view/grant/revoke all of the manifest permissions and AppOp permissions which can or cannot be granted using app's info screen. And the list of permissions which cannot be granted from GUI is very long.

For instance in stock Android there is no GUI setting to set or fine-tune these permissions:

• READ_EXTERNAL_STORAGE/WRITE_EXTERNAL_STORAGE
• READ_CONTACTS/WRITE_CONTACTS/GET_ACCOUNTS
• ACCESS_COARSE_LOCATION/ACCESS_FINE_LOCATION/ACCESS_BACKGROUND_LOCATION
• CALL_PHONE/READ_PHONE_STATE/PROCESS_OUTGOING_CALLS
• READ_CALL_LOG/WRITE_CALL_LOG
• READ_SMS/SEND_SMS/RECEIVE_SMS/RECEIVE_MMS/WRITE_SMS
• READ_CALENDAR/WRITE_CALENDAR
• WRITE_SECURE_SETTINGS
• GET_APP_OPS_STATS
• PACKAGE_USAGE_STATS/GET_USAGE_STATS
• INTERACT_ACROSS_USERS
• READ_LOGS
• BATTERY_STATS
• DUMP
• RECORD_AUDIO/MUTE_MICROPHONE
• AUDIO_MEDIA_VOLUME/TAKE_AUDIO_FOCUS
• FOREGROUND_SERVICE/START_FOREGROUND
• RUN_IN_BACKGROUND/RUN_ANY_IN_BACKGROUND
• WAKE_LOCK
• VIBRATE
• USE_BIOMETRIC
• READ_CLIPBOARD/WRITE_CLIPBOARD
• TOAST_WINDOW
• CHANGE_WIFI_STATE
• REQUEST_DELETE_PACKAGES

and many other manifest and AppOp permissions.

There are also other permissions like

• SYSTEM_ALERT_WINDOW-
• WRITE_SETTINGS
• REQUEST_INSTALL_PACKAGES

which are available through different GUI settings (listed under Advanced or in Special app access) and AccessibilityApp might not be offering to auto-revoke them.

In addition to these changeable permissions, PMX shows each and every permission which an app has requested but cannot be changed (because either it has Normal or Signature protection level or the permission provider is not installed):

• INTERNET
• ACCESS_NETWORK_STATE
• RECEIVE_BOOT_COMPLETED
• KILL_BACKGROUND_PROCESSES
• START_ACTIVITIES_FROM_BACKGROUND
• MODIFY_AUDIO_SETTINGS
• CAPTURE_AUDIO_OUTPUT
• CHANGE_NETWORK_STATE
• GET_TASKS
• MANAGE_ACCOUNTS
• SEND_SMS_NO_CONFIRMATION
• LOCAL_MAC_ADDRESS
• LOCK_DEVICE
• READ_DEVICE_CONFIG/WRITE_DEVICE_CONFIG
• RESET_PASSWORD

and many others.

Also:

• With root access, PMX allows changing System-Fixed permissions which (are granted to preinstalled apps and) cannot be revoked even using ADB shell.
• For many manifest permissions which are not changeable have a corresponding AppOp permission which can be changed using PMX.
• Some apps check and ask for many permissions unnecessarily. And if not granted they don't work. If a corresponding AppOp exists for such manifest permissions you can grant the manifest permission while still denying the AppOp permission so that the app works without having that permission granted.
• For most of the AppOp permissions PMX shows last access time i.e. the time that permission was last used by the app. See example here for VIBRATE.
• For many of the AppOp permissions it's possible to set Foreground mode using PMX so that the permission is only granted when the app is in foreground.
• There are RUN_IN_BACKGROUND (since Nougat) and RUN_ANY_IN_BACKGROUND (since Pie) AppOp permissions which are used for Battery Optimization. Using PMX we can set these permissions to Ignore or Deny so that the app no more runs in the background and hence there's no need to revoke permissions after using the app.

So the FIRST POINT is that what we can achieve using Accessibility features of Android is a very small subset of what PMX offers. There's no comparison. PMX provides all of 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.

And the SECOND POINT is that, from a developer's perspective, the underlying details how PMX works are entirely different from how Accessibility works. So even if we consider using Accessibility to create a non-root and non-ADB version (as already requested in #5), it'd be more feasible and logical to go for developing an entirely new app rather than injecting that functionality in PMX.

PMX works with ADB which is already a non-root option available on all devices (though there's a hassle involved to turn on the Wireless ADB after every reboot, at least up to Q). As mentioned in #7 (comment) Scheduled Checks feature lets you get notified of any permissions which aren't according to your taste and you may take the desired action to revoke the permission.

from permissionmanagerx.

Well I see this was asked before. Must be hard. Sorry for that. Just one more question. Why don't scheduled check option not be there in fdroid version

from permissionmanagerx.

You don't need to be sorry. It's my pleasure to have explained. Some features are paid-only including Scheduled Checks. Developers are poor souls. They have families to feed, kids to educate :)

from permissionmanagerx.

https://mirfatif.github.io/PermissionManagerX/help/help.html#faq32

from permissionmanagerx.

Thanks for the help but my device is a special case where ADB of your app won't work. Also it seems this needs root which I did say in the query that I didn't want to do

from permissionmanagerx.