Update Dec/15/2013: Two weeks after I wrote this piece below, Google removed App Ops... See Android App Ops *WAS* a Step Forward, and stay tuned.
One of Android’s top limitations, one that totally drives me nuts, is its security model, in particular the app permissions model. This is a permission security model where developers (the app) requests permissions, and the user grants permissions during the installation process.
To get an idea of how the Android security model works in general, see an old article of mine titled Understanding security on Android (IBM developerWorks).
The problem with Android’s permission model today is that users are limited two options: 1) grant ALL requested permissions, or 2) not install the app at all.
…and that is a sucky permission model that needs revision.
For example, if I liked a new cool camera app, one that accesses the camera and my location, but I do not want the app to track my location, I have to compromise – either I grant all the permissions, including the ones I am not comfortable with granting, and if I don’t like that, even though I may like the app itself, the alternative is not to install the app at all.
Enter App Ops (Permission Manager)
It was with great excitement (yes, sounds geeky) when I learned about the native App Ops app.
I had totally missed the native App Ops app in Android 4.3 that allows users to grant individual permissions post-app installation. Then I learned the app was removed on Android 4.4. But the good news is that it was not removed, it was just hidden. App developers such as Color Tiger allows you to unhide the native App Ops app. With the native App Ops app I can now control and turn off specific permissions per app!
This of course means that apps must be robust and properly handle the unavailability of restricted, un-granted features — by properly testing for null values and handling security Exceptions — vs. just crashing when it cannot perform the (restricted) functions that have been turned off by the user. Perhaps this is the reason the native App Ops app was hidden by Google for now.
I did a quick test on my Nexus 4 (I finally got my Android 4.4 upgrade) – wrote a simple location-based app/activity and put some breakpoints to test/see this behavior while turning the location permission on/off via the native App Ops app.
In the case of the LocationManager.getLastKnownLocation(), turning off the Location permission, it returns a null value (which means that the provider is currently disabled). Note that I was expecting a SecurityException to be thrown instead! Hmm, need to think about that. Thus, I will continue researching this and in the meantime, for LocationManager.getLastKnownLocation() seems that all we have to do is to test for null, something you should be doing anyways.
Location loc = locMgr.getLastKnownLocation(LocationManager.GPS_PROVIDER); if (loc == null) return; // Provider is not enabled
In summary, while the native App Ops app is a step forward (for end-users that is), the selection of permissions to grant for a given app, really should be part of the app installation process itself (an alternative is to prompt the user every time the app attempts to use a restricted API – I think I prefer the former). This will require that developers be aware and properly test for scenarios related to restricted features/APIs not being available, and perhaps new documentation related to permissions guidelines for developers. I am looking forward to see this happening.
Oh, and thank you, Color Tiger!!!
/CEO