Skip to main content
M
mola2alex
Inspiring
April 2, 2016
Question

File system permissions in Android Marshmallow

  • April 2, 2016
  • 2 replies
  • 11830 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

    A
    Anonymous
    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

      M
      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.

      J
      jon_huang
      Participating Frequently
      May 22, 2016

      Have you had a chance to use the ANE yet and have any feedback?


      Hi wadedwalked. Wanted to say thank you for writing the permissions ANE and the very clear documentation. You're a hero.

      Feedback: it works!  I'm using Flash Builder, Air 20, testing on a Moto X 2015 phone. Testing permissions for Camera, Record_audio, and write_storage. Can correctly detect if permission has been granted, pop up the request window, get the events, etc.

      I did run into one bug that's probably Adobe's fault. Using the ANE to grant access to the Camera, then creating a Video object and loading the device camera into it doesn't work the first time. Invisible. If the app is restarted after permission is granted it works properly, but it never works the first time. Probably just loading the adobe camera libraries does something that assumes there's already access.

      I will try to update to Air 22 Beta later and see if that makes a difference.

      Colin Holgate
      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.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices