Android M Permissions Overhaul: the Good, the Bad and the Ugly
For those who may have missed the announcement at Google I/O: Android M permissions handling will introduce new handling and behavior. The new Android M permissions system support allows apps to be installed without requiring user review and grant of permissions. Instead, most permissions are disabled by default when an app is installed. When the user starts the app and it requires a feature which requires a permission, the user must grant it. The user can also go back at any time and either grant or deny permissions to individual apps.
While this type of functionality has been available in other AOSP derived versions of Android, such as CyanogenMod, it has not been part of the official Android open source codebase. This is quite a departure from the original permission paradigm used in Android. I’ve talked about the original Android permissions system in my previous article on Android Permissions, in case you are unfamiliar. This auto-grant/revoke with user interaction sounds like a very simple change, but trust me when I say it is not a simple or straightforward for the framework or for app developers.
This is an important step forward for the platform security wise and for the end user. Several reasons for the changes come to mind:
The original user experience of one time grant was better than nagging the user, but was very limited due to the all-or-nothing permission grant at install time with no ability to revoke permissions
Android M permissions support brings it closer to parity with Android’s biggest rival: iOS
As users become more savvy, they are demanding a selective permission control type system. They are finally catching on that malware exists and want to have more refined control over what things apps can use.