Android Expansion files

Help
#1

Hi, we have recently created an android game that is well over the 50M play store limit, I now understand that the game should be split into a main APK and an OBB file for the assets, has anyone managed to do this with openfl / lime? if so has anyone got any resources / tips on how to achieve this?

Regards,

Rich

1 Like
#2

Wow, this looks like a huge pain.

If I understand the format correctly, you are just given the option of hosting two additional files, and must download to a specific directory, but otherwise, the downloading, detection and access of the files is up to you.

I have wanted to make a system for asset packing into external “bundle” files, but that would not handle the downloading or accessing beyond the application package automatically. I suppose it is time to revise the plan for this to support the OBB architecture.

If the OBB file is a ZIP, as they recommend, then it would possible to easily package assets manually for this file, though accessing it or downloading it in the first place is more complicated.

Perhaps the best approach for now would be to use the Java libraries they mention to download and access a ZIP asset file, then to feed the bytes over to the Haxe application, so you call MyExtension.getMyFile ("hello.jpg"); and it handles the rest, but this could definitely deserve something more official :confused:

#3

I just discovered the 50Mo limit…

So, the best solution is to use the .obb files ?

Or can I for exemple, using the app, download directly the Assets stored on my web site, and save it definitively on a SharedObject ?

#4

I’m not sure I would use a shared object, perhaps on the SD card storage. I think that *.obb file support needs to be explored more, if we could support this more automatically, it would be great. In fact, the Assets class supports loadLibrary with a custom AssetLibrary class. I think the ideal for this (might?) be something where an *.obb file is downloaded, then added to the asset system like this, with an AssetLibrary that wraps all the contents of the file. This is beyond what’s supported automatically by the tools right now, but it might be the beginnings of a system that could be made more robust in the future.

I’m sorry if I’m talking too much :smile:

#5

Thanks for the answer =)

http://developer.android.com/google/play/expansion-files.html

“On most devices, Google Play downloads the expansion file(s) at the same time it
downloads the APK, so your application has everything it needs when the user opens it for the
first time. In some cases, however, your application must download the files from Google Play
when your application starts.”

What a pain…

I’ll try to see of I can easily use the .obb format, I’ll let you know :wink:

#6

I’ve got a sort of decent version of the OBB files downloading and handling. I’ll cobble what I’ve got together and see if I can pop it online somewhere.

essentially I went for this process:

-> handle download / verify of OBB files as per android example (native)(http://developer.android.com/google/play/expansion-files.html)
-> extract files to data folder for app (native)
->call native extension that verifies file requested exists and returns the absolute path on the device.
-> load the bitmap with a Loader / URLRequest

I have also written native extensions for playing ogg sounds directly from the OBB file without extraction.

let me see if I can get a working example of this online for you.

#7

Oh, I want to see that !

#8

Hi, I’ve just found out about the Android apk size limit and eventually stumbled upon this topic.

Have you guys found a solution/workaround for this problem?

I’m running some tests with custom extensions, but I’m on a tight schedule with this project and I will really appreciate any help you can give me.
I will comment here any progress I make.

Thank you very much!
-Alfred

#9

Hi All, I’m also interested to know if there any existing solutions to this. I’d like to make a rock solid solution for this, but don’t want to start from scratch. Thanks!!

#10

I just found out about the expansion files myself and was wondering if you could share some more info on this process?

  • Did you have to manually donwload the OBB file from google? I was under the impression that this was automatic, handled by GooglePlay?
  • Are your native extension open source? If so, could you share it?

Thanks!

#11

Hey guys, any progress on this?

#12

Hey Everyone, the current working version I have is currently in a client project that I unfortunately cannot share, I’ll hopefully take a look tonight and give you guys an overview with any code samples I can, but it may require someone with a bit more knowledge of Android (And time!) to clean it up.

1 Like
#13

Hey there, I’m working on an open-source version now. Maybe if I hit a road-block you could have a look? Otherwise I’m just coding away at the moment.

#14

yes of course! I get notifications for this thread or you can dm me. I’ll help out where ever I can.

#15

I think I’m finished, an extension for Android Expansion files!

4 Likes
#16

Thanks Thomas!

This will be an imense help for me!

#17

Btw, any particular reason to use NME instead of OpenFL?

Still didn’t try it, but i’m assuming just changing the api for the OpenFL one will work just fine.

Thanks!

#19

It should work fine for OpenFL. One thing to watch out for is the minSDK might be different in your project file. For my reasons for choosing NME over Openfl ping me on twitter. @thomasuster or ask me in gitter https://gitter.im/haxenme/nme

#20

Thanks! About the “salt”, did you just use “normal” random numbers or was there some specific, more secure method of generating them?

#21

The documentation said “modify salt”, so I’m betting the important thing is that it’s unique-ish and not known.