Earlier this week, Google ended months of speculations and announced Android M will be decorated with fluffs of Marshmallow. And with the big name revealed, the official version has been released and it’s time for app developers to make the necessary adjustments towards the new version, set to hit mobile devices late this fall.
What adjustments are those? Well, perhaps the biggest and most exciting one is the new permissions model.
Since its’ inception, Android has employed a then innovative permissions approach. Each sensitive component was wrapped with its’ own set of permissions and each application had to both inform the user of what it will access, as well as request his approval for such accesses. Sensitive data like user’s personal information or location, as well access to the user’s own files or phone records, were no longer done in secret behind the scenes. This was certainly a big important step up from the way things used to be (and still are) with computer applications.
However, Android’s permissions model also had a few stings:
- It bombarded the user upon app installation with the often long and daunting list of permissions.
- It was a package deal – an ‘all or nothing’ situation.
- It was an ever-growing mayhem – Many actions were split into several permissions (for instance, read vs. write) and as features and capabilities continued to grow, so did the complex permissions model.
- Android displayed its’ own description of the permissions, a description that sometime sounded scarier than it was for the casual user.
With Marshmallow, that’s all about to change. Let’s see what it’s all about…
Android A Through L: How It Used To Be
How Things Will Be With Marshmallow
App still declares permissions in Manifest, but…
- User will no longer be prompted to approve all permissions at install. The app will have to:
- Specifically ask for permission
- Check if it is permitted to use the component guarded by that permission before using it
- The app may also explain why it requires that permission.
- The user may choose to grant certain permissions, but not others. The user can revisit this decision at any time using the Settings menu: long after the app has been installed, the user can still revoke or grant permissions to the app.
While the app still needs to ask for individual permissions, Android M groups them together. When the user grants one permission in a group, the app can then ask for another permission and the user won’t be prompted again to approve.
This certainly simplifies the model on one hand, but on the other a quick glance at the permissions group will leave users a bit frightful as to what an app can do vs. what it has been approved.
The Proper Manner in Which an App Should Conduct Itself
Normal is the Watchword
Starting with Android M, permissions dubbed with protection level “normal” will be granted automatically!
The user won’t be prompted, nor would he be able to revoke this permission
Among these permissions are:
And many others (such as NFC, Setting the wallpaper, Reading accounts, Killing background processes and everything Android now deems to be of no potential harm to a user’s privacy).
|While Android M Preview 1 listed the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE as “normal”, the final Marshmallow version has listed them once again as “dangerous” and apps will still need user’s approval to access his files. Phew…|
Best Practices for Android M
Always make sure you’ve been granted access to a permission. Follow the chart flow exactly and to the letter. Remember – your users can revoke permissions at any time. Never assume you have them!
Don’t bombard your users with constant permission requests. Ask for the permissions your app cannot function without once when the app launches and the keep the less integral stuff to when you actually need them.
Explain to your users in a concise and honest manner why you need your permissions whenever you can. Always check to make sure you’re not badgering them and creating a bad user experience with constant permission requests.
Whenever possible try using Android’s built-in capabilities. Like before Android M, opening an intent to capture a video and picture, for example, does not require you to ask the user for the camera permission. Wherever’s possible, limit your permission requests to the bare essentials. User would be more likely to use your app if they’re not scared of all permissions you want.
Always think of backward compatibility – chances are it’s going to be a long time before the vast majority of your users will use an M device. Don’t ask them to grant permissions at runtime if you know they can’t and have granted them all during install.
Test, test, test your app. With permissions, without permissions, always know the behavior of both Android and your app in case of permission deficiency.
And that’s Android M’s new permissions in a nutshell… It has been all the rage around the Droid water cooler. Well, that and what delicious M Candy will finally be choosen…
Of Course, That’s Only the Beginning…
So now you know how to best handle your own code with the new permissions model. But what about the 3rd party SDKs integrated in your app? How do you know the ad-networks, analytics or social media tools you are using are M-compatible (or should I say co-M-patible..?)? Will they gracefully handle lack of permissions? Will they implement the best practices described here? In my next post I’ll address exactly that issue. Coming soon!