Using App Permissions in Android M

We've long pondered what it might look like if Google decided to implement something that gave users more control over what individual apps are allowed to access on our devices, and at I/O this year it all became clear. Android M is going to allow users quite a bit of control over what information and hardware each app is allowed access to, and this new setup even includes a simplification of permission types into a few convenient categories.

While we know nothing about Android M is set in stone, a quick walkthrough of this new permission setup gives a reasonable look at what is coming in the next version of Android.

We're all used to getting that prompt right after tapping install in the Google Play Store that tells you what permissions the app is expecting when it lands on your device. Those days are over in Android M, or at least they are over for apps that update to support this new permission system. All apps are going to be forced into disabling whatever permissions you tell them to either way, but apps updated to the most recent API target will be able to do so gracefully. Everything else will have an increased risk of breaking the app when you remove the permission, and in our testing that can happen quite frequently if you aren't careful. The hope is Google have given developers plenty of warning and all of the tools needed to make these changes and ensure their apps play nice with these new rules, but it's entirely up to the developer to actually implement the changes and update their app.

Android M Permissions

When you install an app that follows the new API targets, you will no longer see that permissions prompt at the beginning of the install process. Instead, the app will have to ask for permissions when the app actually needs that resource, and it will be up to the user to approve or deny that access. Users can also look at the total list of permissions each app has access to in a new permissions tab in the apps section of settings, but more importantly users can head to the advanced tab in this same view and look at the all of the apps and services that request access to specific kinds of permissions.

In our testing, catastrophic failure when permissions were denied was quite rare.

Disabling permissions in an app that isn't written to function around that ability introduces variables the app may not be able to work around. Android M warns you of exactly this when you try to disable permissions in an app that hasn't been updated to the latest APIs, but doesn't stop you from pulling the lever. Instead, you get to explore the app yourself and see if everything still works without that permission. In a worst case scenario, the app will crash immediately and return you to the home screen, but in most cases the app will just fail to access the information and inform you of the failure. It's going to vary quite a bit from app to app, but in our testing catastrophic failure was quite rare.

Given the lead time before Android M is officially launched, it's likely most of your favorite apps will support this new system without issue. On the other hand, if you take a look at which apps on your phone haven't been updated in quite a while, you've probably got a decent indicator of which apps are going to run into the occasional problem when you do eventually make the switch to M. In the mean time, you can rest assured that a better way to handle apps is on the way.

Russell is a Contributing Editor at Android Central. He's a former server admin who has been using Android since the HTC G1, and quite literally wrote the book on Android tablets. You can usually find him chasing the next tech trend, much to the pain of his wallet. Find him on Facebook and Twitter

22 Comments
  • this is how iOS does it, so i'm not sure they would go that full on, as the feature will already be lauded by apple fans as a direct lift.
  • This is the best thing to happen to "customer/dev" communication since the first crashed app on Android. Design better apps...
    Don't be lazy...
    Normies use your products.... Galaxy Note 4 {Sprint Lollipop}
    Galaxy S III {FreedomPop 4.3}
    LG G2 {Sprint 4.4.2}
  • Ah, I didn't realize what would happen with older apps. I like the ability to kill access on older apps, I thought for sure they were going to not allow that to keep things stable. Instead seems they are going to allow things to go wrong and let the users beat the developers up. Think if they didn't do that developers would just stick with the old API and bypass the better security model.
  • +100 Galaxy Note 4 {Sprint Lollipop}
    Galaxy S III {FreedomPop 4.3}
    LG G2 {Sprint 4.4.2}
  • I'm sure it's going to be at least 2 years before I ever see this on my Note 4, so I'm inclined to root and call it a day. Posted via the Android Central App
  • Or root- xposed and app ops module... boom done! I'm going with marshmallow via AC app.
  • You don't need Xposed to use App Ops, and root isn't always necessary. It sounds like Android M goes beyond what App Ops does - apps will have to ask for permission to access a resource in M, but they don't do that with App Ops which requires the user to set access preferences.
  • Or better use Xsposed and Xprivacy. Xprivacy doesn't break the apps because instead of denying permissions, it simply gives the app blank data. You deny contacts permissions and the app crashes. Xprivacy just says, sure, here's my completely empty contact list.
  • As long as the average user understands this, as I can see a lot of users leaving negative feedback on why apps aren't working well. From the start of Android most people had to figure out the features of an app to understand why permissions are needed, not easily self explanatory when we don't understand the entire app and workings inside. Kudos to devs that write out bullet points on why apps need permissions and list them out. Remembering back in the day finding LWP's that wanted access to contacts, data, internet, and gps, and was like I don't think so. For a beginner people may not understand which apps to not install and which apps are ok to install. I think this will be a good thing, as I don't think the learning curve will be steep. As long as Google emails or notify people basics do's and don'ts
  • That's why there are extra pop-ups for "Normies"... This is going to be really funny really quick in the PlayStore comments.
    (This dialer won't make calls. {Dev} Turn on that permission, Normie.) Galaxy Note 4 {Sprint Lollipop}
    Galaxy S III {FreedomPop 4.3}
    LG G2 {Sprint 4.4.2}
  • Just like the retards who criticised Facebook messenger for wanting location, mic and camera access. "why do they need all that?!" they cried, "they're spying on me!". What they were too stupid to realise is they needed that if you wanted to take a photo or video in the app to send to someone or add your location to a message Sony Xperia Z2
    Nvidia Sheild
    Xperia Z3 Tablet Compact
  • I don't see any network access permissions or start at boot. I skip install of many apps and updates because many don't have any need for that and they are not from some developer that I am familiar with. I do want this feature, but it needs full and granular control of the permissions. Also it should probably only be enabled through developer options.
  • Full control could lead to noobs messing up big time so I agree with the developer options part. However, if word gets out in some of the generic tech sites on how to do it, tutorials will pop up all over the place on how to access developer options. Then all hell will break loose Sony Xperia Z2
    Nvidia Sheild
    Xperia Z3 Tablet Compact
  • This won't break anything except of course applications that absolute need location and the like to function. But it's good to finally have permissions in stock Posted via the Android Central App on my Nexus 5 or Nexus 7 2013
  • Erwta Posted via the Android Central App
  • Any app that doesn't handle a failure of the OS calls is what I'd call buggy or at least poorly written. i don't like that I can only give access to "contacts" where I may be expecting it to read them but by doing so they can delated and update them also.
  • If I were writing the App Permission code, I would make it return generic/default data on permission that were being blocked rather than failing the system call. In that way, apps would still function and not have to worry about writing for faults.
  • That's exactly how Xprivacy functions. It feeds fake info to keep the app from crashing. They should have just build it into the permissions code.
  • Wow.. That's a nice choice
  • Follow Posted via the Android Central App
  • Follow Pollow
    Pyiollf Posted via the Android Central App
  • And for everyone not on marshmallow and those won't see it? The rest of those are still at risk for privacy breaches.. Posted via the Android Central App