you can create another activity which does the all stuff(download and unzip) and make it as the main ativity, when you are ready call the cocos2d-x activity (you can pass to it the path of your expansion file)
thanks @yagoub , i will try it.
My first try ends in an error when I pressed the OK button of the DownloadUI after validateXAPKZipFiles() returns. I have to look whats going on there. The error is;
E/ActivityThread(30924): Activity org.cocos2dx.cpp.DownloaderActivity has leaked ServiceConnection com.google.android.vending.expansion.downloader.DownloaderClientMarshaller$Stub$2@42a3fd20 that was originally bound here
E/ActivityThread(30924): android.app.ServiceConnectionLeaked: Activity org.cocos2dx.cpp.DownloaderActivity has leaked ServiceConnection com.google.android.vending.expansion.downloader.DownloaderClientMarshaller$Stub$2@42a3fd20 that was originally bound hereHi guys,
Just wanted to let you know that I am currently working on the same thing.
I got the āuncompress obbā scenario working already ( using google code sample, with two activities ).
I still need to find a way to use the obb contents directly ( as it would be the best for the user ).
Anyway, feel free to get some inspiration there : https://github.com/asmodehn/WkCocos/commits/feature/apk_expansion
Hope this helps.
Hi @Asmodehn, if you find something please let us know. I also want to use the obb directly. It wastes a lot of memory to unzip the assets.
I think I got it workingā¦ Very rough for now, but a successful test on my (very basic) sample app.
Let me know if you see anything strange, but I will do more tests and fixes in the next few days anyway.
Itās based on cocos v3.2 but I will leave the task to port it to a more recent cocos version to someone else.
For inspiration, check this :
https://github.com/asmodehn/WkCocos/commit/05ebed3a4b82876d751fe4550c4e83c4e0a2f472
and this :
https://github.com/asmodehn/cocos2d-x/commit/ebdd51031d17cef91e582cc9cd3397704e8d41ce
Nice, thanks! Has the download and verification process worked well for you from the Play Store? Weāve had issues where some people (doesnāt seem device specific) find themselves unable to download the expansion file through Play or our app through a modified version of the sample app.
Excited that hopefully our android build will migrate from 2.x to 3.x much more quickly.
I havenāt tested the full process on a released version yet.
For now Iām just accessing data from inside an obb file that is already there, in external storage.
However I just finalized a version that works on a full game, so probably using most use-cases for reading files.
Changes are still in the same repos, in the same branches.
A quick warning though, after my tests today :
It seems CCZipUtils is not thread-safe, so using TextureCache::addImageASync() ( which call FileUtils, and then use ZipUtils ) will randomly crashā¦ at least on cocos2d-x v3.2
I spent my whole day on this :ā(
Not sure how much of an effort it is to make it thread safe, or if it is at all worth itā¦ I just went for the simple solution to revert to synchronous image loading and crashes disappeared.
1 Like
I am trying to test the full download process on a published apk ( alpha ).
When I go to google play and install the app it downloads the whole apk + obb.
So I never need to download anything.
Any hint about forcing the download to be only the apk, so that I can test downloading the obb from the app ?
Thanks.
When testing our cocos2d-x 2.x version of our game I think I just SSHd into my phone to remove the .obb file from the data folder. You have to do this using adb shell or something so that you have access since normally you canāt access the folder unless you have sudo or admin rights.
You could maybe push up a new version of the APK without the extension file? And then update it with a version bumped APK+OBB? Itās definitely a weird process.
I wish theyād just make it so that if your app hasnāt received an OBB file you can send a message or specific URL or something and the Play store app would open and attempt to download the OBB file again). Weāve only had a small % of users not get the OBB or otherwise have issues getting both APK+OBB. ugh, Iām not looking forward to trying again now that weāve upgrade to 3.x ā¦ let me know if you get it working!
OK, Thanks for the tips.
So I tested by removing the Obb, and the download service downloaded the obb after I made a few changes :
- While debugging in cocos C++ code it kept crashing because of https://github.com/cocos2d/cocos2d-x/blob/v3/cocos/base/CCConsole.cpp#L253 and https://github.com/cocos2d/cocos2d-x/blob/v3/cocos/base/CCDirector.cpp#L109 -> I would hope we initialize and then check for pointers before using themā¦ I spent 3 days to find why log crash on device when I CCLOG during initialization, but not after Director::init()ā¦
I canāt make a pull request for it because I am on v3.2 with different build system, but I m sure it would help many people to get this properly fixed. - Make sure you have the same ApplicationId in GooglePlay and in your APK, with a versioncode that is equal or superior to the one published.
- Make sure you set your test account to receive the LICENSED response from Google Play ( in dev console parameters )
Latest version is there : https://github.com/asmodehn/WkCocos/tree/game/dragonfall
enjoy, and let me know if there is any other question. I ll stop working on APK expansion for the next few days as it is working well enough for me.
Cheers.
1 Like
Hi @Asmodehn,
I am unable to load any assets(sprite, audio, video, ccz or plist) from obb.
My path for the obb file is ā/storage/emulated/0/Android/obb/myPackageName/main.1.myPackageName.obbā and i am setting the search path as follows:
std::vector<std::string> resDirOrders;
resDirOrders.push_back("/storage/emulated/0/Android/obb/myPackageName/main.1.myPackageName.obb");
FileUtils::getInstance()->setSearchPaths(resDirOrders);
I have also changed the files suggested by you.
Please let me know if i am missing something or if I am on the wrong path.
Hi,
It depends how cocos loads these assetsā¦ For audio files I read somewhere else that they shouldnt be compressed by the zip algorithm, but just stored inside the zip file as they are, so that the audio engine can use them directly.
However in my case I only have images, plist, json inside the obb, so I didnt test other usecase.
Also my files in my zip are under an āassets/ā folder.
But I think in your case you might have missed some changes I did on my cocos forkā¦ please check https://github.com/asmodehn/cocos2d-x/blob/asmo_v3_dragonfall/cocos/platform/android/CCFileUtilsAndroid.cpp again.
But once these changes are made in FileUtils, you shouldnt need to change anything in the search path. It will look first into the obb ( provided it was set by the java code like that https://github.com/asmodehn/WkCocos/blob/develop/Android/lib/src/main/java/com/asmodehn/wkcocos/lib/MainActivity.java#L154 ). And only if the file is not found in the Obb, it will go look into the apk.
This is different ( almost unrelated ) behavior than going through the search paths to find a file.
Putting debug logs into FileUtils will help you track down the problems.
Good luck !