mirfatif
commented
3 years ago 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_STORAGEREAD_CONTACTS/WRITE_CONTACTS/GET_ACCOUNTSACCESS_COARSE_LOCATION/ACCESS_FINE_LOCATION/ACCESS_BACKGROUND_LOCATIONCALL_PHONE/READ_PHONE_STATE/PROCESS_OUTGOING_CALLSREAD_CALL_LOG/WRITE_CALL_LOGREAD_SMS/SEND_SMS/RECEIVE_SMS/RECEIVE_MMS/WRITE_SMSREAD_CALENDAR/WRITE_CALENDARWRITE_SECURE_SETTINGSGET_APP_OPS_STATSPACKAGE_USAGE_STATS/GET_USAGE_STATSINTERACT_ACROSS_USERSREAD_LOGSBATTERY_STATSDUMPRECORD_AUDIO/MUTE_MICROPHONEAUDIO_MEDIA_VOLUME/TAKE_AUDIO_FOCUSFOREGROUND_SERVICE/START_FOREGROUNDRUN_IN_BACKGROUND/RUN_ANY_IN_BACKGROUNDWAKE_LOCKVIBRATEUSE_BIOMETRICREAD_CLIPBOARD/WRITE_CLIPBOARDTOAST_WINDOWCHANGE_WIFI_STATEREQUEST_DELETE_PACKAGES
and many other manifest and AppOp permissions.
There are also other permissions like
SYSTEM_ALERT_WINDOW-WRITE_SETTINGSREQUEST_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):
INTERNETACCESS_NETWORK_STATERECEIVE_BOOT_COMPLETEDKILL_BACKGROUND_PROCESSESSTART_ACTIVITIES_FROM_BACKGROUNDMODIFY_AUDIO_SETTINGSCAPTURE_AUDIO_OUTPUTCHANGE_NETWORK_STATEGET_TASKSMANAGE_ACCOUNTSSEND_SMS_NO_CONFIRMATIONLOCAL_MAC_ADDRESSLOCK_DEVICEREAD_DEVICE_CONFIG/WRITE_DEVICE_CONFIGRESET_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) andRUN_ANY_IN_BACKGROUND(since Pie) AppOp permissions which are used for Battery Optimization. Using PMX we can set these permissions toIgnoreorDenyso 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 https://github.com/mirfatif/PermissionManagerX/issues/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 https://github.com/mirfatif/PermissionManagerX/issues/7#issuecomment-778622834 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.
Thewisem
I would like to remove permission without root like Bouncer which makes it easier for me to remove permissions without root. :)