Avoid Requiring Permissions for OBB Usage

We use the GooglePlayDownloader plugin to download our OBB in the rare case that Google Play did not successfully push it to the device.

Unfortunately, this requires the read/write permissions to be set, and we are concerned that the associated permissions dialog may turn off some users. (The wording is a bit "scary.") For a Free-to-play game, every "neck" in the retention funnel needs to be addressed!

So, is there any known way to add the "just in case" OBB downloader code without requiring the permissions? Clearly, Google Play does this internally.

 

Wow, after researching this more it appears to be a very big and complicated problem. Does anybody at Unity have a whitepaper on the best way to handle OBB files?

 

Does this help? https://docs.unity3d.com/Manual/android-OBBsupport.html

 

Ha, no. But I'm very, very glad you responded as this seems to be a critical issue to developers that require Android expansion files.

The problem is complex, but the TLDR is that games do NOT have read/write access to the OBB directory without explicitly requesting READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE in the manifest.

By doing this, however, newer versions of Android display an onerous permissions warning: "Allow YOUR APP to acces photos, media and files on your device." After casual research, some publishers state that this results in a 10%-15% loss of customers. (They download the game, but do not run it.)

There are some fairly lengthy threads on this subject, which I have included below for reference. While I know this isn't really a "Unity problem", I was hoping somebody there may have a best-practice suggestion for this situation.

Some references:

• https://forum.unity.com/threads/apk...ne-until-the-phone-has-been-restarted.465714/
• https://stackoverflow.com/questions/38355912/android-6-0-permissions-and-mounting-obb

 

Unity seem to refuse to address this situation properly. As you point out you need this permission for expansion files to work correctly on all devices, and it has to be obtained on boot, any later (via the SkipPermissionsDialog manifest flag) and Unity will occasionally fail to mount it correctly based on our experience with devices in the wild. Google's requirements state that you must inform the user why you're asking for a sensitive permission before asking, but Unity provides no way for you to do this given the above.

In order to get around this we've had to make a plugin that delays the startup of the UnityPlayerActivity in order to present the user with some context for the permission request before allowing Unity to start up. This works as a jar/manifest combo but not as an AAR for some reason so far (ref my post today).

 

Hi Hutch:

So are you saying if you use SkipPermissionsDialog and ask for the permission later, you have still encountered devices (or OS versions) that won't properly grant access to the OBB?

So, it sounds like your solution was to simply include the permissions, and politely ask the user to say "OK' to the onerous "This App wants to read and write all your data and send it to hackers" warning that Android pops up?

So, we seem stuck in the risky position of either A) implementing a bunch of hacky workarounds or B) just asking for the permission and risk loosing a portion of our users over a perceived security issue.

Any more advice?

Ack!

 

Hi Matthew,

Yes, due to Google insisting we address the lack of context before the permission request we enabled SkipPermissionsDialog but still asked for storage permission as soon as possible on boot after displaying some context for the user, and this caused hangs on a significant proportion of devices in the wild and we had to revert to Unity's default handling.

Our more recent title was under 100mb so we avoided the issue but with our next title we'll need to ask for the permission, but with a friendly message in front of it via the method I outlined. It's possible this will scare away some users but I think if the messaging is correct it shouldn't be too bad, the permission text isn't quite as scary as that Unfortunately I'm not aware of any other solution short of shrinking your app under 100mb which may or may not be doable.

 

Hey, thanks so much for the advice. So when you say "them method I outlined", you mean firing up an activity to do some messaging before Unity boots?

I just want to be extra clear since after reading some more threads on this - I'm getting more confused, not less

Thanks again - ain't this fun!

 

Yep that's correct, we fire off a new activity in onStart of the main activity to show some messaging and request the permission before letting Unity continue booting up. It's definitely not exactly a valuable use of time but in our experience Google won't give your app any support unless you comply with this requirement

 

Man, what a hassle. Thanks much for your help on this. I have one more quick question... do you only do this for Android 6 and above? (since the run time permission "upgrade")

I hope you don't mind if I pester you again if I get stuck It kills me that I have to do anything to extend the bootup time.

BTW: What is the name of your app, can I check it out?

 

Yeah we do that via maxSdkVersion. The app with the changes isn't yet live unfortunately so I can't point you at it but I believe CSR2 has a similarly (extremely) basic implementation of the requirements (not via Unity but it works similarly). I have a watch on this thread so feel free to post in here if you need!

 

Hey Hutch:

We just about have this working. However, would you be willing to look at our code and let us know if it is similar to what you are doing? I feel there is too much at stake to have this dumb issue be a potential point of failure

 

Hi Matthew, yes sure no problem, feel free to DM me!

 

@hutch_jl
I'm currently attempting to implement the same solution as you, and have made a library project in android studio that handles the permissions requests.
I've tried to export an aar file and note in my manifest that the 'permission checker' activity is the entry point by using:
<action android:name="android.intent.action.MAIN" />

My logcat shows the error "java.lang.RuntimeException: Unable to instantiate activity ComponentInfo java.lang.ClassNotFoundException: Didn't find class: "

I then found this thread and saw that you went with a "jar/manifest combo"
Would you care to elaborate how you managed to pull this off?

I have tried simply taking the generated .jar file from Android studio, with my classes in them, putting them in the Plugins/Android folder, and using the package name from my java classes in my manifest in Unity (overriding the default).

I used the following naming structure:

the Apk has package name: com.company.gamename
the .jar classes have package name: com.company.gamenamelauncher

so to declare an activity from the launcher package I do the following in my manifest:

<activity android:name="com.company.gamenamelauncher.ClassName">

I get the same "fatal error" and a crash as noted above as when I did the aar method.
Any help would be super appreciated!

 

Hey guys,

I'm running into the same problems. Headaches and annoyance over the 100mb apk app limit that is at the base of the problems.
I hadn't yet heard of the problem hutch_jl mentions:

This was actually what I was trying to implement but did not yet know that "this caused hangs on a significant proportion of devices in the wild"
Do you know which devices suffer from this problem?

So you disabled the "SkipPermissionsDialog" (removed it or set to false)? Or what do you mean with "Unity's default handling"?

Could either of you share some implementation details or pointers? How do you delay the Unity activity? And you still need to ask the permission (with context) in the start-up/downloader activity (which would also need localization).

 

So. I finally got the method of "Wrapping the app in another app" working.
There were a lot of steps to it, but some general pointers:

You need just ONE activity that handles these permissions, and then you need to import the unity library in your android library, and simply start the UnityPlayerActivity when you want to proceed with the game.
See specifically this page: https://docs.unity3d.com/Manual/AndroidAARPlugins.html
and the section about "Android Library Projects".
You can put a .jar file in the Plugins/Android folder, and the manifest for your custom activity in your ".plugin" folder.

You need to override the default manifest, and the only real difference you have to include, is that the UnityPlayerActivity is NOT flagged as the main activity, but the activity that you created in your library instead. If you just copy the "Resulting" manifest of a build, you're going to include the same "build tag" every build, which is supposed to be unique for every build, which is also included in the .obb file. And if those two don't match across manifest and .obb, your expansion will not load. So make sure not to override this.
See: https://docs.unity3d.com/Manual/android-manifest.html

If anyone gets truly stuck with this, feel free to message me and I'll try to help out the best I can.

 

@NecrosDk We currently have a situation where people in early access / beta are reporting a black screen on startup and it may be related to what is being reported in this thread. None of us here are Java / Android developers although I can mess around with the code and run gradle tasks through Android Studio. I would say we are close to being stuck on this. Any assistance would be GREATLY appreciated.

 

I assumed Unity would provide some way to check permissions states and to be able to call the native request window ...
And I don't feel like re-writing an android plugin just to manage this -_- (let alone having the skills necessary to do it without any hiccups).

Hopefully one day...

 

Is This obb permission problem solved?

 

Sorry for some reason I didn't see the notifications on this thread! The way I did this which might be a little different to @NecrosDk was to derive my activity from the main activity (in our case was Prime31's but could be the default Unity player). If you then override the activity lifecycle methods to start your permission request activity, which displays whatever context information you like (we just used a system dialog) before requesting permission, then stopping your activity to give control back to Unity again.

This seems to be acceptable for Google, we've been through featuring review with it a couple of times.

@StijnPaladin: We tried SkipPermissionsDialog but we found in the wild it generated black screen on boot issues on some devices as it sounds like @trj_1 is seeing also. We couldn't find a pattern to the issues so it seemed to be a timing issue on boot where Unity in some cases would try to access the obb before permission had been granted and would then hang.

If anyone is still struggling with this I'll see if I can provide our workaround here. I really do think Unity's attitude with this isn't good enough, Google have required proper handling of this for 3 years now and we're still forced into hacky workarounds.

 

Cool. With the new permissions API can we ask for permission before Unity tries to mount the OBB?

 

I'm not sure if anyone here can clarify for me, because I THINK I'm running into a similar issue:

- Our app utilizes OBB files.
- Our app downloads said OBB file from the Play Store simultaneously with the APK, and places it in the Android/obb/folder section (for what it's worth, I don't have an SD Card storage setup, just space on the Pixel XL tester phone).
- Our app asks for permission to use the camera (it's an AR app) and then to read/manage our photos, videos, files on first-time running. (I presume this encapsulates the OBB file as well, feel free to correct me)
- Our app then runs through the Preloader scene and the loading bar for it... and then does nothing. Sits at 100% on the loading bar, where normally it would load our Main (AR) scene. Based on this, we can only conclude that the OBB is NOT being accessed despite location, and the rest of the scenes and content are not being loaded.

Now, we're somewhat new to app development here at the office, so I must ask - Is there something that I need to add to the Preloader scene, like a script or a plugin, that "puts humpty-dumpty back together again" so to speak? Is there something that the first scene (from the APK) needs to properly access the OBB file's contents?

We're sort of lost on this one, can someone illuminate this aspect of the process? Or is this simply part of the permissions problems you guys are running into?

 

Thanks for all the help. If you can, I will sum up the permissions situation and please tell me if I'm wrong anywhere.

1. Unity asks for READ_EXTERNAL_STORAGE on startup, regardless of skipPermissionDialog if OBB split is enabled.

(which shouldn't be required normally, but since Android is a buggy mess, in some versions (6.0, maybe 7.0, 7.1 I don't know about newer), it sets the folder the OBB is in as root, so permission is needed...).

My question is: How can we "provide context" in order to comply with Google's guidelines for the READ_EXTERNAL_STORAGE permissions prompt, if it gets automagically asked before we can actually do anything? It seems that there is no way currently?

(although, if we're being truthful, the true context is "We need this permission, because android is a buggy mess" and I'm not sure if Google would appreciate it)

2. Because of the same bug, if the OBB doesn't get downloaded with the APK, we need to ask for WRITE_EXTERNAL_STORAGE before we launch the OBB downloader, because otherwise the OBB downloader will not be able to download anything.

3. What do I have to do in order to make Google raise the APK limit in order be rid of the .OBB mess they have created? (okay you don't need to answer this one ). All other Android stores have managed it, I don't understand why Google is insisting on keeping this around.

 

I was actually able to solve this one Yury! There was an issue where I had modified the manifest file directly (as per another user's instructions from one of these discussions), and it corrupted the interaction between the APK and OBB file. I instead went back and applied a different plugin fix for the issue, which allowed for the correct interpretation of the OBB! I then had to patch Vuforia's target acquisition with their own official fix script, which I embedded in a scene that loads before my own Preloader to reacquire their targets from the OBB. Shazam! Works great.

Thanks for taking the time to respond!

For your own info on the subject:
- Running Unity 2018.2.14f1
- Running Vuforia 7.5.26
- I don't have skip permission dialogue, but instead let the standard asking of permissions (Camera, then Devices and Files) occur on first startup.
- There wasn't a log that I ever looked over, as a crash never actually occurred as far as I can tell. The app just figured it was finished with its tasks, because there wasn't technically another scene to load in without a proper read of the OBB.

Again, thanks for taking the time! (It's a pretty rare phenomenon to see on a dev forum these days )

 

Thanks @Yury-Habets for the reply.

Unfortunately I don't see Android App Bundle being a solution for anything I care about.

It seems like overkill and overly complicated for our purposes. We don't do different assets per device, so I don't have any use for "dynamic" stuff.

We just have a bunch of stuff our game uses that we'd like to be downloaded on the device before the our game starts, but apparently that's too much to ask.

We are also over 500mb in size, so I guess we'll be stuck with the OBB and permissions mess forever.

Yay.

 

Also have been struggeling with this problem for a week now. But i have solved it by using https://github.com/Over17/UnityAndroidPermissions

1. In my first scene i check if i can access the OBB file
- If i can i just continue loading the menu scene
- If not i show a native dialog that explains why we need the READ permission and then i ask for it.
- If the user still denies the permission i show him a dialog explaining that he must accept it in order to play. I then ask again.
- If the user ticks the "Never show again" checkbox that becomes available the second time i ask for the permissions i show him another dialog that explains that he now has to go to Settings->Application>->AppName and manually grant the permission.

I have some problems still tough. For instance the documentation states

• APK - Consists of the executables (Java and native), plug-ins, scripts, and the data for the first Scene (with the index 0).
• OBB - Contains everything else, including all of the remaining Scenes, resources, and streaming Assets

I find this to not be true. In my first scene(index 0) i have a background image setup in a canvas. This image is not available and has been packed in to the OBB. It renders the usual purple(missing) texture.

It would be nice to have the ability to explicitly choose files that should not be packed in the OBB.

 

I would be careful to make sure this works for you "in the wild" - we had a non-negligible number of reports of the device booting to a black screen and not making it to the first scene to do the checks. This was a while ago though so I can't say if it's still the case. The only 100% reliable way I found at the time to address this problem was the approach described above that doesn't rely on Unity starting up at all.

 

Thanks for the comment @hutch_jl . I'll definitely consider your approach as it's probably the safest one. But correct me if i'm wrong. Since Android 4.4 we actually get access to the OBB without the READ permission, we only need it for Android 6 where Google F***ed up and had to enable it again? Because on all our phones here at the office our game always pass the OBB check and go straight to the menu scene.

 

And @hutch_jl . If it is possible it would save me a couple of days if you could share your solution. It would be much appreciated.

 

Hi Kristofer, yeah it's because of this bug:

https://issuetracker.google.com/issues/37075181

Your best bet may be to move to app bundles if you can as Google are raising the limit for those to 500mb without using expansion files, so you avoid the whole problem. I'll see if I can pull together what we did though, it's very basic but does the job.

 

@Yury-Habets I'd love to submitt a bug report, i have several bugs in our backlog that are Unity/Android specific. However, i can not attach the entire project, and thats the case for all our projects at our company.

Reproducing issues in empty projects takes a lot of time and rarely works, at least that is our experience and we only proceed trying to reproduce something if it is critical for the project to move forward and no workaround is available.

 

@Yury-Habets I totally understand that you need the project, and like you say the issues are almost always related to the project itself, and that is of course the reason it is hard to reproduce issues in empty projects.

We can unfortunately still not attach our projects for many reasons.

I'm not sure the image has made it into the OBB, it's either in there or it's lost somewhere else But it's not in the APK anyway, if it was i would assume it would render correctly in the scene. It only renderes if i also install the OBB.

 

@Yury-Habets No, it's not in the StreamingAssets folder. It's a Sprite placed in a Canvas in our first scene with scene index 0.

 

Hi. So is it possible to use the OBB file without requiring write external storage permission?