[GEAR VR] UE4 fails to open embedded OBB

New to Android dev in UE4, so please bear with me.

I’m working on a GearVR app. Game works well enough when it’s a separate apk and obb, but I’ve been requested to put the game’s OBB inside the APK. That part works well enough, I open up the APK with WinRAR and see main.obb.png inside it.

Problem is, when I try and run the game on my Samsung S6 Edge, I get the following:

Far as I can tell, it’s failing inside the call to AAssetManager_open() in OpenRead() in AndroidFile.cpp

So, what am I doing wrong? Is there a size limitation to what the Android Asset Manager can open? Or is there some other setting I should change when cooking?

What size is the OBB? The asset manager tries to memory map the file and you may be out of process space.

See the mmap failure above. 1.3 gigs.

So I’m going to assume that it would have issues if it’s trying to do a complete memory map of the file when the S6 only has 3GB RAM total.

What to do, then? Is there a way to “break up” the obb into more digestible chunks? Or should I push back on the request to fit the entire game in the APK?

Make sure you have the “Create compressed cooked packages” checkbox on (it is hidden in Packaging Project Settings in the Packaging section… you need to expand it). Also, instead of Android All, try Android Multi and reduce the number of compressed texture formats you are using. ETC1 will work on all, but it doesn’t compress textures with alpha.

There are more suggestions here: https://docs.unrealengine.com/latest/INT/Platforms/Android/ReducingAPKSize/

So the general answer is, then, “make your game smaller”?

We’re already using a compressed pak, and using exclusively ETC2 for compression. Currently looking through the pak contents to see where we can save space.

Is there a limitation on how many files we can put inside the asset folder? I’m pondering modifying the cook and file access code to add the individual files right into the asset folder of the APK, keeping the directory structure. It would be a nontrivial amount of work, but it would get us around this memory issue!