Search results for

All search results
Best daily deals

Affiliate links on Android Authority may earn us a commission. Learn more.

Android head explains reasoning behind new permission system

Google’s head of engineering for Android and Chrome Hiroshi Lockheimer explained why it took so long for the company to change course when it comes to permissions.
By

Published onJune 12, 2015

Android M App Permissions watermark

One of the most radical changes coming in Android M is a new way to handle permissions for Android apps. Google is finally giving users control over the specific permissions they want to grant to an app, moving away from the current model, where permissions are granted in bulk before the app is installed.

Talking to the Guardian, Google’s head of engineering for Android and Chrome Hiroshi Lockheimer explained why it took so long for the company to change course when it comes to permissions.

First up, Lockheimer clarified why Google released and then quickly pulled App ops, a feature present in Android 4.3 that allowed users to revoke permissions of installed apps.

Applications on Android were not built with the notion that certain functionality could be turned off behind their backs

“Applications on Android, starting in 2008, were not built with the notion that certain functionality could be turned off behind their backs,” said Lockheimer. “App ops was launched somewhat out of context; we really needed to solve the whole story, not just launch App ops without moving apps from install time to run time permission requests.”

Google removed access to App ops in Android 4.4.2, in December 2013.

The jump to Android M (or rather the new corresponding SDK version) gave Google the opportunity to initiate a controlled transfer over to the new system, where users are asked to grant individual permissions when they are needed while running an app.

“We’re starting in M, because every time we have a major release we can change these things, and we were able to modify and create new application programming interfaces (API) to handle it,” said Lockheimer.

Only apps designed to work with the Android M SDK (API level 23) will use the new permission system. App developers can stick to the old system, as long as they target API level 22 (Android 5.1) or earlier. However, if they want to take advantage of the new features supported by Android M and future versions, devs will have to adopt the new system. Google hopes this will be a strong-enough incentive to nudge the ecosystem towards the new permission model.

Hiroshi Lockheimer hopes that the new permission philosophy will help break what he called the “finger memory.” Let’s face it, right now most of us just click Accept without really going through the list of permissions that an app requests.

Developers will have to find thoughtful ways to explain why they need permissions for their apps, as well as account for what happens when a permission is denied. But what happens to older apps, designed for Android pre-M? This video from Google I/O explains that users will still be able to revoke permissions of these apps in Android M. In this case, apps will be fed blank data, which means they won’t break, and instead they will just show empty objects – for instance, if you deny Hangouts access to your camera, when you fire up a video chat, the app will show a blank screen instead of the camera feed.

This compromise gets the job done, but it may cause a lot of confusion for some users. Still, it’s a sacrifice Google is willing to make in order to ensure a reasonable level of consistency.

What do you think of the new Android M permission system? Is the right step or were you fine with the old way of handling permissions?