Questions about large Android builds and .obb files

Unity Engine
, , , , ,
1

Hi. I’m working on a museum app that has to run locally on Android tablets. The project has many, many videos that total around 8 Go of data. Since it is not meant to get on the Play Store, I figured that having a large .obb shouldn’t be much of an issue. So I just set the project to split the binary files on Android. It builds without any errors, but I’m having several issues:

  1. The files that are in the StreamingAssets folder do not load. In my understanding, this comes from the compression inside the .obb file and the way Android works. Documentation is unclear about how exactly to access the folder. In my understanding, I have to use UnityWebRequest instead of File. This poses an issue since I inherited the project that uses an external plugin to load the videos and doesn’t use UnityWebRequest. Is this something that can be worked around or should I rollback the use of that plugin?

  2. But more annoyingly, development builds do not run. The normal APK build is installable on the tablet and the application launches and runs without the StreamingAssets as expected, but a development build opens then immediately closes. I could not find an explanation in the troubleshooting manual for that only to happen with development builds. Trying to use build and run also creates an app that closes immediately after opening, even though Developer Mode is enabled on the tablet, as well as the USB debugging. Also, given the size of the assets, each build is pretty long and copies the whole .obb every time but I don’t know where. Not in Android/obb as you would expect.

  3. Creation of the obb directory is inconsistent. At first, when I installed the application, it did create a corresponding app directory in the Android/obb/ directory, but since I tried a dev build it stopped doing that. I always can create a folder with the package directory name, but it doesn’t feel right since it’s normally automatic.

  4. Ideally, I’d like the StreamingAssets folder to be exposed and accessible on the tablets and not compressed inside of the obb, so the maintenance teams can change the videos without me having to access the machines. This is easy on Windows, but I don’t know how to ensure that exposure once we have an .obb compressed file.

I am new to Android ports especially with projects that have such ridiculously large assets. I had advised the team that this was a liability but it is out of my control. The application runs fine on the Windows version. Should I decompress the .obb and put it in the Android/data directory?

I’m sorry if this all comes as dumb questions (I hope they are dumb since that would mean easy fixes though), but I’m really confused about how to set this up. Any guidance would be much, much appreciated!

3

So, after a while, I’m going to answer my own questions.

  1. StreamingAssets gets automatically thrown in the .obb file if we chose to use binary splits. In this case, since the amount of data was ridiculous, the compression was failing. I don’t know exactly why, a colleague told me that Unity 2023 did work better for him regarding the compression issues, but in my case that did nothing.

So Instead I ended up entirely removing the data from the Application.streamingAssets to an external location on the computer for the desktop version and to the file://{Application.persistentDataPath} for the Android version, using Unity Web Requests for Android. This worked. Very important not to forget to put file:// beforehand, as this isn’t specified in the documentation…

  1. I think the development builds were failing because it was trying to copy the entirety of the data inside of the data files on the tablet instead of compressing them and sending them to the obb folder, but was eventually capped before finishing, then failed to open the app because nothing was were it was supposed to be.

  2. This was worked around since I used the data folder instead.

  3. This was what happened once I chose to use the data folder. However, a drawback is that it requires the user to manually load the files in the folder from a PC, which is pretty cumbersome but does work out. That said, the manual installation of .obb files require to create the folder manually, so it’s even worse. Working with the data folder is much more straightforward.

The morality of this adventure is: do not let your clients prevent you from properly architecting a project.

The reason why the weight went totally off the charts was because they thought it would be “easier” not to use subtitle files, but hard-write them in the videos. Since the application existed in 4 languages and 2 accessibility modes (visually impaired and normal), that made the weight jump x8. They also refused to wait for the font assets to be ready and correct the kerning and instead of giving me texts to work on it, exported all the contents from InDesign, 4 languages and 2 accessibility versions, into .png backgrounds. Basically each single state of the application isn’t dynamically loaded, they are still images requested by invisible buttons. This results in 5Go of data that could have entirely been cut. If it does sound crazy it because it is crazy.

But more technically, as a dev now I know that working with StreamingAssets while them being huge is simply a bad idea. For applications on small devices, it is preferrable to have some way to load the data externally and decouple the core application from its contents as much as possible. Once that decoupling was done I could entirely circumvent the .obb issue and everything went well.

2 Likes
4

Thanks for documenting all this and sharing the thought process!

I stumbled upon this while trying to search answers to a similar issue.
While your answer doesn’t directly help - the thought process is extremely insightful!

Also your rant hits too close to home to me as a fellow museum exhibit developer!