App Ops Controlling Permissions on Android

app-ops-controlling-permissions-on-android-0

The new Android 4.3 brought us a hidden section in Settings which enables revoking of permissions used by installed apps. Let’s see what effect this will have on users, developers and companies when it comes to privacy, improved usability, profit and software design.

First of all, let’s see what the competition already has in comparison to App Ops. Afterwards, we will have a look at the current implementation of App Ops. Finally, we’ll cover benefits and drawbacks of this new feature and the extent of its impact on developers, users and Android as a whole.

iOS vs Android permissions

Application on iOS asking for permission to use microphone

Unlike Android, iOS doesn’t ask the user to accept app permissions when installing the app. On iOS, the user is prompted to allow the usage of private data only once the data is requested. In my opinion, this is a fine approach, because the user can see the specific moment when the permission is requested and, therefore, transparency is guaranteed.

Contrary to iOS, Android asks for permissions once, when the app is being installed, and doesn’t provide the user with the possibility to disable some permissions/features of the app later on.

This is all changed with a hidden feature released in version 4.3 (Jelly Bean), which allows users to revoke permissions after installing a particular app. If you are lucky enough to have an Android 4.3 device in your pocket, you can try App Ops Starter, a simple app which unlocks Google’s hidden App Ops interface for managing permissions of installed applications.

The guys from Android Police who discovered this feature also found a textual resource in the package manager, indicating that the user will also have the possibility to revoke permissions at the time of installation as well.

Please beware: when you start revoking app permissions, most, if not all, of your apps will crash and won’t be usable. That’s expected, because current versions of installed apps are not yet aware that their permissions can be forcefully revoked after installation.

Permission grouping

iOS permissions are grouped in a pretty simple manner: Location Services, Contacts, Calendars, Reminders, Photos, Bluetooth Sharing, Microphone, Twitter, Facebook and Push Notifications. The user can revoke them at any time from the Notification Center (Push Notifications) and Privacy (all other permissions).

Privacy menu located in iOS settings

Android has quite a bit more of permissions and it will be interesting to see how App Ops will group them in order to logically disable parts of the app. Will it follow the permission groups that already exist or will it use a more fine grained approach with smaller groups of interest?

App Ops appearance

There are four handy tabs: Location, Personal (Contacts, Accounts), Messaging and Device (hardware features, such as camera). Each tab displays when an app used OS features or collected data.

App Ops apperance

NOTE: Some permissions only appear in the permission list once they are first used.

Benefits and drawbacks

So, it seems that selective permission handling on Android could be a great thing. The openness of the platform strikes once again and gives users the possibility to even more freely choose the interaction and behavior of apps installed on their smartphone or tablet. Let’s check some benefits and drawbacks of the current implementation of App Ops.

Benefits

  • It adds transparency to the whole interaction between the user and app, meaning that, in time, users should feel much safer about private data handling. This could push some of the more paranoid users to view Android as a viable platform.
  • In my opinion, the biggest benefit from App Ops in the long term is improved quality of code. I think that, in order to build apps which allow the user to turn permissions/features ON and OFF, we have to think a bit more about the architecture of the app we are building. In other words, we will have to focus our efforts on building modular architectures with plug and play capability.
  • Making apps compatible with App Ops will be mandatory, and that opens the opportunity for additional profit.

Drawbacks

  • Many apps crash at the moment.
  • No real way of knowing that the user has revoked permissions through App Ops (current methods still return that the permission is available) → tech support hell
  • Blindly catching null pointers? Ha, Google?

Third party players

  • Manufacturers with custom Android versions will most probably remove App Ops in order to limit the user’s possibility to mess around with their custom launchers and apps.

So what to expect on the horizon

As stated before, in the long term, App Ops could provide a nice boost in terms of quality of code, as it will force a more modular approach in app development, which will reflect in a plug-in architecture dev approach/design.

Android will benefit in the way that users will see that Google cares about their privacy and freedom of choice by forcing software companies to adapt. Users just have to sit back, relax, and wait for the change.

The biggest drawback will once again be slower adoption of the feature due to Android fragmentation. Some users won’t be able to update to the latest version of the OS and some will be left out intentionally by some Android device vendors.

Overall, the reputation of the platform should see a positive boost and push the competition further away.

Stay tuned for updates!