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 24, 2016

      I can certainly see your point on the PermissionGroups class. A majority of the documentation is taken straight from Google's own Android API documentation (since this is basically replicating the same functionality) and then tweaked some for context within this native extension. Taking a look at it again after so long, I can definitely see where more explanation could be given to explain the differences. In the case of the Camera group, it only has the Camera permission. In the case of something like the Contacts group, that includes the READ_CONTACTS, WRITE_CONTACTS, and GET_ACCOUNTS. I should probably add all that to the documentation of each group to say what each group includes.

      System Permissions | Android Developers

      The PermissionsManager.isSupported call at the moment, strictly checks to see if the code is running on an Android device or not, no version checking is being made. It is basically just using the flash.system.Capabilities.version property to check to see if contains "AND" for Android. As far as I know there is no way, within Flash/AS3, to detect the version of Android. I would need to change it into or add a new property/method that calls native code to determine if it is running on Android 6.0 or higher.

      Would you be able to take screenshots of both examples so I can see what you mean about the title bar? I may or may not be able to adjust that.


      Sure, I'll try to do that tonight. The title bars are subtle though, not a big deal.

      I can probably confirm that the camera bug is something to do with Adobe's implementation; I was able to use Distriqt's Camera ANE after using  your PermissionManager.  Incidentally, their Camera ANE also comes with a permissions module (though it only handles relevant permissions) and they ask for the same activity added to the manifest. I assume they came up with the same hack you did.

      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