Google Play gives us an option not to update OBB file if there was no changes in it and keep the old version even you uploaded a new .apk file with higher VersionCode.
To avoid our users to download again the same huge amount of data which was not even a bit changed and is completely the same.
As you may know there is a problem in Cocos that it’s impossible now to update .apk file in Google Play without updating OBB also.
Because Google Play requires us to increase VersionCode each time you upload new .apk file - current implementation of composing a name for OBB file won’t work.
Cocos implements work with OBB file in that way that to compose OBB file name it uses VersionCode which it gets from package info:
This implementation forces us to re-upload OBB file each time APK was updated to have Google Play update the OBB file name to have proper VersionCode inside the OBB file name.
Let’s discuss how to make it possible to let the Cocos application still be able to work with old version of OBB file without need to update it each time without real necessity.
We see at least two ways how it could be implemented:
We may store the last VersionCode in SharedPrefereces in case if the OBB file was successfully found if it’s name was composed with this current APK’s VersionCode.
Then each time we just take VersionCode code for composing OBB file name from the SharedPrefereces and checking if OBB file with this name exists.
Use it if it exists. That would mean that APK was updated but OBB was left from previous version.
If there is no OBB file when it’s name is composed using stored in SharedPrefereces VersionCode then taking the current APK’s VersionCode code and composing the file name again.
Checking if the OBB file with given name exists. If it exists then updating VersionCode code in SharedPrefereces.
(This way was suggested somewhere in the internet. Not ours idea.)
Composing only a path to the /Android/obb/com.company.gamename folder and seeing if there any OBB files inside.
If some files found then just returning a list of all files, picking a ‘main’ OBB and starting to work with it.
I also mentioned this issue here (as you know), because the current implementation is missing the patch obb file. So I would prefer to use your second way. If you want bonus points, I would be happy to have a “download missing obb file(s)” (explained for Java in the Google sample) within the app. This could be useful, if the user deletes the file.
PS: The current implementation seems to be a one-to-one copy of the sample from google, where they also just check for current versionCode.
Hey @mars3142, thanks for your thoughts.
We also think that it would be great to have an ability to work with patch OBB.
Hope we’ll have a workable solution soon and show it to the community.
Oh, I just see your PR. This is only for main-files. How about patch-files? It would be cool, if we can use a main-file and after that only use patch-files for updates.
@hellobody Sure, you only implemented your needs. It was just an idea for improvement for the future. Maybe someone else (or me) will create a PR for that sometimes.
