Back in Android 4.3, a new tool was discovered that for the first time gave users first party granular permissions control for their installed apps. This was, of course, App Ops. As time went on, many users quickly took a liking to the hidden feature, not realizing that the feature was only accessible in the OS for internal debugging purposes. Rather, many took it to mean that Google was looking to bring granular permissions control to the masses. But then, Android 4.4.2 came. Along with the update’s various security upgrades, 4.4.2 also made it more difficult to access the (already hidden) utility.
A few days ago, the EFF publicly chastised Google for “removing” App Ops from Android 4.4.2. Now before getting into the meat of this post, I would take a second to say that here at XDA, we are big fans of the EFF. They do great work protecting the public’s online rights and fighting for what’s right. While we don’t disagree that having granular permissions control is fundamentally a good thing, and in fact we have shared various (superior) means of obtaining such control, it’s a bit unfair to say that this internal debugging feature was “removed” from the OS. After all, it was never officially available in the first place.
Looking back at Android 4.3 when the feature was still accessible, one would have to create a custom shortcut to a specific activity within the Settings app (Settings > App Ops) using a third party app in order to launch the App Ops interface. Alternatively, a user could also install an APK that performed the same task of summoning the aforementioned activity.
Then came Android 4.4.2, which disabled the previously discovered method of accessing the activity. But this change was entirely intentional, as Google always meant to keep the program for internal debugging. As stated by Google Framework Engineer Dianne Hackborn:
That UI is (and it should be quite clear) not an end-user UI. It was there for development purposes. It wasn’t intended to be available. The architecture is used for a growing number of things, but it is not intended to be exposed as a big low-level UI of a big bunch of undifferentiated knobs you can twiddle. For example, it is used now for the per-app notification control, for keeping track of when location was accessed in the new location UI, for some aspects of the new current SMS app control, etc.
The current UI is definitely not something that is appropriate for end users; it is mostly for platform engineers (a tool for examining, debugging, and testing the state of that part of the system), maybe some day for third party developers. In what form these features might be available in the regular UI I couldn’t really speculate about.
In other words, App Ops was never intended to be an end user feature, and as such it was never meant to be seen outside of internal testing. Rather, App Ops was intended for internal debugging of various features that have made or will make their way into other parts of the OS, such as what we saw with the per-app notification control and coarse vs fine location access.
The mere fact that users discovered how to access an internal debug tool, one which has the very real potential to break compatibility in a great deal of applications, does not mean that it was ever “released”—no matter how much any of us want such a feature. After all, most end users don’t even understand the Android permissions model, let alone what could happen when disabling unnecessary permissions.
Now, before you get your pitchforks ready, I want to make it clear that granular permissions control is something that can be quite useful if wielded properly. After all, we’ve publicly commented on the unfortunate state of excessive application permissions in the past. We’ve also covered a few tools such as PDroid and XPrivacy that give users granular control over their permissions. And in the case of XPrivacy, this can be done using fake data that does not break application compatibility. But for those insistent on reacquiring that App Ops functionality that we were never intended to have in the first place, there are various third party workarounds through Xposed framework, Smali editing, or a root-only app.
Ultimately, something has to be done about the Android permissions situation. But criticizing Google for removing a feature capable of breaking application compatibility, one which was never intended to be user-facing, is not the answer. Rather, we should encourage users to use open source privacy management tools such as PDroid and XPrivacy, as well as keep a mindful eye on the applications we choose to install._________