Hey all … so to follow up. Yes after asking for Read permission I was able to access and use the installed Obb file. Strangely I found that the Obb file user remains still set to the Root user after the permission is granted, but the app can use it. The root user is still not changed until the app is restarted. So perhaps it was never about the file being the root user or not. It doesn’t really seem to matter. Although I guess for some devs they have reported that a restart and the user on the file being updated seemed to help the read access without a permission request, and then some saying the restart didn’t help… but at least the read permission seems to work in either scenario.
@jason_yak thanks for the update.
It might be the combination of Android M bug making root the owner until restart, and suppressing the Unity’s permission dialog on the startup. We might lack the permissions to mount the OBB on startup, and we remount it on pause-resume/restart.
Yea not sure. This issue does seem to be fairly wide reaching though and not just affecting Unity Android apps. I noticed that Google’s documentation even acknowledges that problem if that helps at all?!
Since Android 4.4 (API level 19), apps can read OBB expansion files without external storage permission. However, in some implementations of Android 6.0 (API level 23), you may need to declare the READ_EXTERNAL_STORAGE permission in the app manifest and ask for permission at runtime…
Oh Google acknowledges the bug! 
However it still leaves us with this workaround for the lifecycle of Android 6 (like, forever). We’ll think of adding the permission with maxSdkVersion in the manifest.
Yea although I’d be wary of the max value that they specify as 23. I’ve read that Google ‘thought’ that the issue was resolved as of api 24… but plenty of people are reporting the issue on devices running Android 7 / api 24. Read to the bottom of this thread: Google Issue Tracker
So in my case I am actually specifying a min sdk value of 23 for the read permission so it affects from 23 up and leaves from 19 to 22 alone. If you were to add that read permission in asa enforced part of how unity builds ^ it might conflict with peoples custom declarations of that permission in their manifest files. Perhaps not… but I’ve been caught out before where your compiler auto-injects entries into the manifest and would prefer to be able to have control over this myself. I think if you made it so that you don’t add the entry if someone is using a custom manifest that would be best from my point of view.
I’m baffled by this, how is this not affecting everyone that publishes to google play and have apks with more than 100mb ?
Google is doing an horrible move here, it’s forcing pretty much everyone to ask for such an intrusive permission just to run an 100mb+ apk ! And they don’t care at all. It almost makes me put a message on the apk start that if the permission is wrong the user should reset their devices because Google can’t be bothered to fix a bug on their end, and the user should switch to iPhones which are more secure…
We usually have zero issues with publishing to ios, but damn android, everything is complicated and bugged !
Sorry for ranting…
It does amaze me how this issue isn’t bigger, is there some secret we’re missing ? Is there some way to publish +100mb games on google play that doesn’t require obb ?
1 Like
@JustAnotherDude there is no other way, if you publish to Google Play.
You could use asset bundles to try to get into 100Mb.
The issue should be isolated to Android 6 only, but now I doubt that…
1 Like
@jason_yak thanks for pointing to the new google issue.
I have no clear evidence so far that the issue happens on Android 7. If it does for you - I would appreciate the exact model and build fingerprint!
On adding the permission - we will be checking whether the manifest already has READ_EXTERNAL_STORAGE; if it does not - add it with masSdk=23. However I will be holding this change for a while… maybe we just add it without the maxSdk, to be on the safe side.
On the other hand, our user can easily apply a workaround by adding the permission without maxSdk or anything.
1 Like
It is affecting many builds. I’m completely baffled as well. It’s given our android build the worst first impression because I have to deal with long standing OS bugs. It’s so frustrating to know that Google can side step these issues if they were to lift the 100mb APK delivery limit. Other android based platforms like TapTap can deliver APK’s over 100mb and are completely devoid of all of these crazy issues ie. the size limit is enforced at the time of submission to Google Play. The Google Play store even has a warning message to users when an app is over 100mb, to advise them the app download is large and gives them the option to complete the download later when they’re on wifi - this should be enough?! Instead all developers have to deal with all of the broken OS OBB related bugs: Android 6 read permission issues, OBB files that can go missing for various reasons or never install depending on various device OS configs so you need a backup OBB loader which then can’t write the files unless you have write permissions on certain devices etc. Yup… rant from me as well… but all of this could be fixed overnight and would solve issues of older OS versions as well if they would lift the 100mb APK restriction… the only other thing that using an OBB file is meant to do is that it can only be obtained when passing a license check to receive the download URL to the OBB file, but we all know that’s not stopping any piracy on Google Play.
sounds good thanks… and sorry I haven’t been able to test on Android 7 as yet.
I’m pretty sure I tested it on Samsung S7 with android 7 and the problem was there.
Just to be 100% sure I’ll try to test again, bit busy now but will try tomorrow.
Anyway another person posted that also had that problem on android 7 on the bug report I filed in google issuetracker :
https://issuetracker.google.com/issues/37544273
He said :
“Same issue for Galaxy Tab S3 with Android 7.0.”
edit: My android is definitely 7.0
Folks a bit of update from me.
All Samsungs I tried had the bug (root owner, no access until restart without READ_EXTERNAL_STORAGE). Models and build fingerprints for the history:
SGS5 samsung/kltexx/klte:6.0.1/MMB29M/G900FXXU1CPJ6:user/release-keys
SGS5 samsung/kltexx/klte:6.0.1/MMB29M/G900FXXU1CQB3:user/release-keys
SGS6 samsung/zerofltexx/zeroflte:7.0/NRD90M/G920FXXU5EQBG:user/test-keys
SGS7 QCOM Verizon/heroqltevzw/heroqltevzw:6.0.1/MMB29M/G930VVRU2APG3:user/release-keys
SGS7 Mali samsung/heroltexx/herolte:7.0/NRD90M/G930FXXU1DQD7:user/release-keys
SGS8 QCOM samsung/dreamqltesq/dreamqltesq:7.0/NRD90M/G950USQU1AQC8:user/release-keys
SGS8 Mali samsung/dreamltexx/dreamlte:7.0/NRD90M/G950FXXU1AQF7:user/release-keys
It’s definitely not isolated to Android 6, so we are not shipping maxSdkVersion=23 because it won’t simply work on Samsungs with Android 7. We leave it with pure READ_EXTERNAL_STORAGE.
1 Like
I have a app recently reviewed and featured on Google Play. On the review process, here’s what the Google Reviewer wrote to me:
I. Must resolve before feature consideration:
- The Android 6.0 (Marshmallow) release allows users to directly manage app permissions at run time. Because of this, it’s important to handle permissions properly in case a user has denied access to some or all of the required permissions. Be sure to follow the guidelines below when implementing a permission request flow:
• If any permissions must be requested at launch, be sure to provide context to the user as to why they are being asked to allow it.
• In the event of a user denying a permission request, avoid immediately directing the user to the app settings. Instead, educate the user as to why the app needs the permission to run and provide a way to re-trigger the request in the app. Reserve sending a user to the app settings until the app has detected that the ‘Always deny’ option has been selected.
For more info:
Android 6.0 APIs | Android Developers
Request runtime permissions | Android Developers
App permissions best practices | Android Developers
It will be a lot easier if Unity implements this guidelines to avoid user of external plugins to detect if the permission was set and manage all kinds of situation.
@i9mobile this is a bit unrelated to the topic.
No we don’t have a runtime permission solution out-of-box.
Please use a plugin, for example GitHub - Over17/UnityAndroidPermissions: Unity Android Runtime Permissions for Android Marshmallow
I have added READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE and it’s still not working for me. I have tried with unity 5.6.0p4, and 5.6.2p4. When I build to the phone it works fine, but when I upload it to google play and download from there I can’t get to any data in the OBB until I restart the phone.
Are you getting the android permission request when you run on the phone AND allowing it to run ?
I’m not getting any android permission requests
Then you need to manually ask for it, see the top voted answer in this question : unity game engine - Implementing Android 6.0 permissions in unity3d - Stack Overflow
@265lutab your phone model, android version and the manifest would be helpful. Does it work if you just kill and restart the app?
Are you using a plugin to override the permissions dialog in the beginning?
The way Unity asks for the permissions (before loading the OBB) is the most compatible way.
I got it to work by changing the manifest. By default unity has
and I changed it to