Android M has introduced the world to system-level permission controls. Granular app permissions allow you to simply flip switches to accept or revoke individual permission requests. While the functionality was always available in Android through the use of third-party apps, this is the first time we've been able to manage permissions through the Android system itself. It's huge news (even if it is a little unsexy), so here's what you need to know about Android M permissions.
How do run-time permissions work?
As you likely know from our Android M features breakdown, the latest developer preview allows users to grant individual permissions to apps as the need arises (run-time), rather than as a batch on installation. That means no group permission request when you first download an app. Android M permissions have also been distilled into a much easier to understand list and are granted one-by-one as the need for them arises.
This means that the first time an app needs access to your camera, microphone, contacts list or location, you'll see a pop-up requesting permission for that action alone. This way you always know the exact reason for the permission and can grant or deny it as you choose. Permissions classed as ''normal'' from a security standpoint, like internet access or the alarm clock, will be granted automatically upon install.
Permissions classed by the Android framework as ''dangerous'' – those included in the granular permissions list – are also reversible, meaning you can grant access when you need to, and then flip the switch again to protect your privacy. This was simply not possible in earlier versions of Android (although App Ops did feature briefly before being pulled), which had more of a ''take it or leave it'' approach.
Will revoking permissions break apps?
As users, we were always told that blocking permissions with third-party apps would cause apps to malfunction, and yet Google has now managed to give complete control at a system level without developers having to completely retool their apps. Or so they told us at Google I/O 2015; but that's not entirely true.
Sure, devs can do nothing and their apps will still be compatible with Android M. However, if they haven't set their app up to handle granular permissions ''gracefully'' so they work with any number of individual permissions denied, then both devs and users can expect some strangeness from their apps.
We may not be talking all-out crashes, but users might not get core functionality without specific permissions and devs may have to factor in warning messages that state an app can't function at all without a particular permission. So while retooling isn't ''necessary'' Google obviously wants apps to be revised with M's permission structure in mind.
What about the apps I already have?
Legacy apps – those apps that were targeted at Android versions prior to Android M – will continue to behave like apps do now: with a long list of permission requests at install that must be accepted to proceed. However, once the app is installed a user can go into M's permission manager and revoke permissions as they wish. Android M's permissions structure is backwards and forwards compatible.
Apps are not entirely likely to simply crash if you deny certain permissions. Android will simply pass the app empty data rather than a security exception. This is the Android system equivalent of kicking your dirty clothes under the bed and telling your mom you cleaned your room; failure to comply gets you in trouble but something that looks about right is enough to get you by.
Also, Google apps – or those apps that are part of the system image – can automatically be granted more permissions upfront. This is obviously Google granting itself and OEMs a kind of VIP access. However, users can still go in later and revoke certain permissions, just like with legacy apps.
What does it all mean for me?
Basically, you now have complete control over what your apps have access to, with the ability to grant and revoke specific permissions whenever you choose. While some apps will undoubtedly malfunction, the onus is placed on developers to manage these issues gracefully (with warning messages or the like) or to simply update their apps. It's a great day for privacy and user control. The only thing you have to do is make sure you actually know what permissions you should accept and which ones are unreasonable.
What do you think about the way Andriod M handles app permissions? Is it a good thing or not very useful?