APK size > 100MB


#1

Has someone a cocos2d-x game with a APK size larger than 100 MB, so you had to use OBB files? What’s the best practice to download the OBB while startup? Do you use a separate splash screen activity for checking and downloading if needed?


#2

:smiley: we avoided this by using tinypng.com :smiley: but would be interesting to see for other guys solution on it :slight_smile:


#3

Same user of tinypng, best solution for all this :smiley: Saved a lot o space. Also, I’m not using 4444, but just only 8888, so not getting 2x size increasing of sprite sheets.


#4

That’ll work if you don’t work with picky artists lol


#5

Not every game has pixel art of 240*320 in total screen :wink: Also if you are using 3D graphics, the texture can easily be bigger. And if you put 3 different resolutions of your assets into the APK, you can also reach the limit very fast.

So it has nothing to do with the artist.

PS: Do you create all your assets by code, than your APK size is really small and I respect your coding skill :wink:


#6

PITA! :smiley:

We did a Java-based initial screen that checked for OBB and would call the convoluted example code for downloading and showing a progress bar. Half the time it wouldn’t find the download or would otherwise fail. While obviously it’s our fault for not working on getting it to be fool-proof, we did end up just removing our hi-res png and converted stereo music to mono in order to get < 100MB :frowning:

I do believe the latest github HEAD now has more support for accessing the OBB file date more simply than when we used it.

I’d think that by now there’s a decent example code that checks for all the failure cases and handles them, instead of using our support process: “try uninstall, clear cache, and re-download”, heh.

I have before suggested just pushing up content to AWS S3 or other cheap cloud storage and download with HTTP request client. Especially since it’s cross-platform and if your > 200MB I think iOS would need this as well.


#7

cocos2d-x only supports using OBB (zip) as resource, but there is nothing to download it. Google said, you should include a fail safe implementation, in case the PlayStore don’t download the OBB file or the user delete it (because it’s on the sdcard and world visible).

Hmm. But this way you have to do everything by yourself.


#8

Yep, PITA! Sorry.
There was some download+manifest thing that was meant to make it easier than “do everything yourself”.
YMMV.

godspeed.


#9

We attach our obb in the current version as an expansion file, then our users download all of it during the normal download. It can works for you?

Our file safe implementation is based in opening an alert dialog, that tells the user that the app didnt find the assets, contact us or try to download again the app.
In our case the app without the .obb is just the code, so they only “really” redownload this 10mb code, the other 300mb are the assets in the .obb


#10

This is also my recommendet way. I am downloading assets when needed(when new level, new category opened). Users more likely uninstall bigger app. Better do not download 100MB at once when you need only 10MB for now.


#11

So you hope that the PlayStore will download your OBB file and if not you say to the user, that he has to reinstall the game? Is that right?


#12

That’s interesting. You download everything on demand, but this implies, that the user has a either wifi active or a good data plan and at least 4G (if you download a lot of data). Most user install/update apps/games while on wifi, so this will be the better solution, imho.

And what do you do, if the on demand solution doesn’t work, because of offline?


#13

DialogBox “No Internet”… Always there are trade offs.


#14

Yup, its an absolutely regular download, its not a 10mb download and after a 300mb download, its 310mb all together, the user doesnt know that there is an expansion file. If the download fails it means that the all app installation fails. I think that it is very safe.

The file safe implementation part is in case that the user extracts the sdcard or erase the files.


#15

This part I always forget, because I use Nexus/Pixel devices without a physical sd-card since years.