AppOpsXposed is a module for the Xposed framework that restores AppOps functionality on Android >= 4.4.2, and works on all Android versions from Jellybean 4.3 up to Marshmallow 6.0.1. Why not just install XPrivacy? you may ask - read this post.
Source code is available on github (License: GPLv3+)
ChangeLog:
1.30.3 (2016-02-21):
* Fix missing op labels/summaries
* Fix issue in "Show changed"
* Fix OP_BOOT_COMPLETED on Marshmallow
1.30.2 (2016-02-20):
* Fixed crashes
1.30.1 (2016-02-20):
* Fixed crash
* Updated Slovak translation
1.30 (2016-02-19):
* Better support for Marshmallow
* Fixed crashes
* Fixed label/summary issues
* Fixed multiple icons in "App info" screen
* New "Minimal" variant (disables icon in "Settings" app)
What is AppOps(Xposed)? What's the difference between AppOps and permissions?
AppOps is a feature that is included in Android starting with JellyBean 4.3. It allows the user to limit an apps functionality, regardless of permissions granted; for example, you can prevent an app from reading your contact list, or accessing your current location. The difference between revoking permissions and using AppOps is that in the latter case, the affected app will not know what happend and, most importantly, will (usually) not crash. In the case of the location, the app will think that the location is currently unavailable. In the case of your contact list, the app will see an empty list. See this flowchart for an example:
You'll notice ALLOWED, IGNORED and ERRORED; these are the so-called modes, which can be set for each operation. The AppOps interface is very simple, as it provides an on/off switch for every operation. Using this, you switch between ALLOWED and IGNORED, which is usually enough. ERRORED will (likely) make an app crash, or in some cases it will behave exactly as IGNORED.
In the flowchart above, the permission for reading the contact list is android.permission.READ_CALL_LOG,
the corresponding app op is OP_READ_CALL_LOG. Not every permission has a corresponding op, and likewise some ops don't have a corresponding permission. For example, there's no op for the network access permission android.permission.INTERNET, and there's no permission corresponding to the OP_POST_NOTIFICATION op. Note that some app ops are used internally by Android: for example, starting with KitKat Android only allows one app to act as the messaging app; this is controlled by OP_WRITE_SMS.
You'll also notice that in the AppOps app-list, there are often more ops listed for an app than when clicking it. This is because Android groups certain ops into one switch. For example, the "Location" switch controls 7 ops at once: OP_COARSE_LOCATION, OP_FINE_LOCATION, OP_GPS, OP_WIFI_SCAN, OP_NEIGHBORING_CELLS, OP_MONITOR_LOCATION, OP_MONITOR_HIGH_POWER_LOCATION.
Another important thing to keep in mind is that AppOps was not intended for end-users, so some features do not work as advertised. Limiting "Keep awake" for example has no effect, as this was not implemented by the Android developers.
Now that Marshmallow has permission control, what does this module do on Marshmallow?
It may come as a surprise that permission control on Marshmallow doesn't directly use AppOps directly, but instead operates on the permission level. The mechanism used in Marshmallow is this:
This is in contrast to previous Android versions, where an app was granted all requested permissions after install. Revoking a permission thus most often caused the app to crash, since it generally did not expect the permission to be denied.
The mechanism layed out above leads to a slightly different permission/op flowchart, as compared to pre-Marshmallow:
The major difference here is, as explained above, that the app itself must check whether a permission has been granted, and then handle the result accordingly. This also means that an app will be notified of the users decision on a permission level, but not the AppOps level,
i.e. an app may believe that it can access the user's contact list, because the user permitted the app to do so (i.e. granted it the READ_CONTACTS permission), when in fact it is not, because OP_READ_CONTACTS is set to MODE_IGNORED).
A list of so-called "dangerous" permissions can be found here.
The history of AppOps(Xposed)
I have plans to add several new features in the AppOps interface, but as always, be patient. I'm often busy and this is just my hobby!
READ BEFORE YOU POST
It might seem stupid, but before reporting a crash please try the following: uninstall AppOpsXposed, reinstall it, re-enable it in the Xposed Installer, reboot. It often helps, don't as me why.
Post AT LEAST the following info:
>>> DOWNLOAD LINK (github) <<<
Source code is available on github (License: GPLv3+)
ChangeLog:
1.30.3 (2016-02-21):
* Fix missing op labels/summaries
* Fix issue in "Show changed"
* Fix OP_BOOT_COMPLETED on Marshmallow
1.30.2 (2016-02-20):
* Fixed crashes
1.30.1 (2016-02-20):
* Fixed crash
* Updated Slovak translation
1.30 (2016-02-19):
* Better support for Marshmallow
* Fixed crashes
* Fixed label/summary issues
* Fixed multiple icons in "App info" screen
* New "Minimal" variant (disables icon in "Settings" app)
What is AppOps(Xposed)? What's the difference between AppOps and permissions?
AppOps is a feature that is included in Android starting with JellyBean 4.3. It allows the user to limit an apps functionality, regardless of permissions granted; for example, you can prevent an app from reading your contact list, or accessing your current location. The difference between revoking permissions and using AppOps is that in the latter case, the affected app will not know what happend and, most importantly, will (usually) not crash. In the case of the location, the app will think that the location is currently unavailable. In the case of your contact list, the app will see an empty list. See this flowchart for an example:
You'll notice ALLOWED, IGNORED and ERRORED; these are the so-called modes, which can be set for each operation. The AppOps interface is very simple, as it provides an on/off switch for every operation. Using this, you switch between ALLOWED and IGNORED, which is usually enough. ERRORED will (likely) make an app crash, or in some cases it will behave exactly as IGNORED.
In the flowchart above, the permission for reading the contact list is android.permission.READ_CALL_LOG,
the corresponding app op is OP_READ_CALL_LOG. Not every permission has a corresponding op, and likewise some ops don't have a corresponding permission. For example, there's no op for the network access permission android.permission.INTERNET, and there's no permission corresponding to the OP_POST_NOTIFICATION op. Note that some app ops are used internally by Android: for example, starting with KitKat Android only allows one app to act as the messaging app; this is controlled by OP_WRITE_SMS.
You'll also notice that in the AppOps app-list, there are often more ops listed for an app than when clicking it. This is because Android groups certain ops into one switch. For example, the "Location" switch controls 7 ops at once: OP_COARSE_LOCATION, OP_FINE_LOCATION, OP_GPS, OP_WIFI_SCAN, OP_NEIGHBORING_CELLS, OP_MONITOR_LOCATION, OP_MONITOR_HIGH_POWER_LOCATION.
Another important thing to keep in mind is that AppOps was not intended for end-users, so some features do not work as advertised. Limiting "Keep awake" for example has no effect, as this was not implemented by the Android developers.
Now that Marshmallow has permission control, what does this module do on Marshmallow?
It may come as a surprise that permission control on Marshmallow doesn't directly use AppOps directly, but instead operates on the permission level. The mechanism used in Marshmallow is this:
- When installing an app, so-called "dangerous permissions" [1]are not immediately granted
- An app must check whether a permission has been granted before performing an operation that requires this permission
- The app is notified of the user's decision and must handle it accordingly (displaying an error message, for example).
This is in contrast to previous Android versions, where an app was granted all requested permissions after install. Revoking a permission thus most often caused the app to crash, since it generally did not expect the permission to be denied.
The mechanism layed out above leads to a slightly different permission/op flowchart, as compared to pre-Marshmallow:
The major difference here is, as explained above, that the app itself must check whether a permission has been granted, and then handle the result accordingly. This also means that an app will be notified of the users decision on a permission level, but not the AppOps level,
i.e. an app may believe that it can access the user's contact list, because the user permitted the app to do so (i.e. granted it the READ_CONTACTS permission), when in fact it is not, because OP_READ_CONTACTS is set to MODE_IGNORED).
A list of so-called "dangerous" permissions can be found here.
The history of AppOps(Xposed)
I have plans to add several new features in the AppOps interface, but as always, be patient. I'm often busy and this is just my hobby!
READ BEFORE YOU POST
It might seem stupid, but before reporting a crash please try the following: uninstall AppOpsXposed, reinstall it, re-enable it in the Xposed Installer, reboot. It often helps, don't as me why.
Post AT LEAST the following info:
- Device,
- Android version (4.3, 4.4, etc.)
- Name and type (stock/custom) of ROM
- In AppOpsXposed's settings menu there's an option "Build bug report" (see below) - use it! Normal logcats are not enough!
>>> DOWNLOAD LINK (github) <<<
Attachments
Last edited:
