Skip to main content
Inspiring
April 2, 2016
Question

File system permissions in Android Marshmallow

  • April 2, 2016
  • 2 replies
  • 11917 views

If I set my target SDK to marshmallow and request storage access in my manifest, it will not prompt the user to allow at run time. It will just fail to allow me to access the contents of the local storage. Application directory access is fine but not docs directory. I can change the target sdk back to lollipop but I think users are going to start expecting those granular permissions. Anyone have insight how to do this? I hope we don't need an ane for every permission now...

This topic has been closed for replies.

2 replies

April 4, 2016

The new permission system in Marshmallow requires the developer to check if they have permission or not every time code that requires explicit permission is executed and if they don't, then use the new APIs to request that permission and have a graceful fail in place. A native extension could be built to replicate those APIs to request access to X permission where X would be a passed argument. A single ane could cover all the required APIs for handling permissions. One thing to know is that not every permission you use requires the user to grant it. I believe only ones considered "dangerous" require explicit permission.

The simple workaround is to change the target back to Lollipop. Apps running on Marshmallow that are built targeting Lollipop or lower are not held to the "must request permission" standard. If you are not utilizing Marshmallow APIs then there really isn't a reason to change the target. The next version of Android might change that eventually but the current beta doesn't change the current handling of "older" apps that dont make use of new APIs of the latest Android OS.

System Permissions | Android Developers

mola2alexAuthor
Inspiring
April 4, 2016

The issue is that just because you target lollipop, marshmallow users can still turn off permissions in the settings which may cause unexpected behaviour if you don't account for it. You can likely to a try catch to fail gracefully but it's not going to ask the user for permission, at least from what I have tried, it just fails. This means you will be stcuk on lollipop being able to only fail gracefully. So for instance, you target marshmallow, you will catch an error for not being able to write to file, then what, tell the user to go into the app permission settings? Alternatively, if you target lollipop and the user decides to turn off a permission after the fact, again you are left with a disjointed experience having them re-enable. Users dont want to jump through hoops.

April 4, 2016

While it is true that users can disable permissions manually, that is a very active and purposeful process that must be taken to accomplish that and, in my opinion anyway, not something an everyday user is going to do. For example, on my Nexus phone running Marshmallow, I have to launch the Settings app, scroll down and tap "Apps", click the gear icon in top right corner, tap "App permissions", select whatever permission I have concerns about (Storage in your case), and start tapping toggle switches to the "off" position for apps that I don't want to allow the Storage permission for. That is a decent amount of effort for a normal everyday user to go through. Im not positive, but I think I remember seeing that the first time a user does that, they will get a popup warning message saying that could break an app if they start disabling permissions.

You are correct that it will not ask the user for permissions, just fail at the task, and possibly even crash the app depending on what was going on. The developer is supposed to manually check if permission is granted for X permission every time a block of code is executed that would require explicit permission.

If you would like me to, I could look into making a native extension this weekend to replicate that new API that would allow you to check for permission and if you don't have it, present the popup that requests access to the desired permission.

Colin Holgate
Inspiring
April 2, 2016

Google are changing over to how Apple do things. With iOS you're only asked permission to use a feature at the time you use that feature. Until now on Android you could assume that the user has given permission already.

I have hoped that it will be handled by the OS, but maybe we need to put in the same precautions you have to on iOS. When you attempt to use a feature that might not be approved, you would need to test if the feature is working. A try/catch test would work for most cases. When your code tries to call that feature, marshmallow should ask the user permission, but they might decline, and the catch part of your code would need to tell the user why that feature can't be used.

Something like that!

One thing you should certainly do is test on a real device. It may handle the situation better than I'm guessing it will.