This I think is the biggest problem with pre-builts on Android.
So all can be fixed, by developers who understand android.
To solve this issue, there needs to be less variables.
I think if cocos2d-x complete switches over to c++_static and use gradle to generate libs, this won’t be a problem at all.
c++static is the future for the NDK and will be supported all the way to C++20 apparently. With tht info, we just need to configure it all. The way ti use prebuilt libraries is probably doing a check for them in the Android.mk files associated with them. This will make sure when building with gradle, it will use pre-built libraries instead of compiling them again
1 Like
I’m really waiting for that 
and also it would be cool, to push forward using prebuilt cocos2d-x libs for games. Easy update, easy to use. Easy to add source code if needed(just drag into Xcode and remove later if not needed).
SDKBox is ready for c++_static
@mozartalouis I found this another cocos2d-x and it has prebuilt libs already with c++_static https://github.com/Senspark/cocos2d-x-lite/issues/2#issuecomment-347485027
Maybe you can help with this and give some examples for official cocos2d-x for prebuilt? Because it’s currently a pain to built it for android…
Are you using prebuilt libs for your games? If so, can you please share process of building them for android.
Because for iOS & macOS it works without any problems of course…
Sounds good.
I’m using only armeabi-v7a for mobile. I wonder why It’s should be any split applied?
For emulator I’m using x86 yes, but currently it(emulator) not works on my Mac, so I will use device only.
Apparently Some people need the benefit of 64 bits (arm64-V8a) and to support the small amount of x86 devices in the world. I’m going to make it in such a way that it relays on the PROP_APP_ABIS variable and only split on release, otherwise there is no point
2 Likes
I see, but for this engine it’s like less needed? I mean what features game devs uses? Maybe I’m wrong, but as I investigating .apk’s of some top games I’m seeing there only armeabi-v7a.
I guess it’s more of a nice to have then need, but one of the key feature for splitting apks is that the overall size of the apk and download is smaller since only the apk with the ABI supported by your phone is downloaded. Google automagically handles which one get downloaded for the particular device.
In theory, this is what it looks like if you build for all 4 abis (armeabi, armeabi-v7a, arm68-v8a, x86)
- Universal apk (includes all Abis) ~ 20mb | 20mb download from Google play | take up 35 mb after it’s uncompressed.
- armeabi apk (Only that abi) ~ 5mb | 5 mb download from Google Play | 12 mb after it’s uncompressed.
- armeabi-v7a apk (Only that abi) ~ 5mb | 5 mb download from Google Play | 12 mb after it’s uncompressed.
- arm68-v8a apk (Only that abi) ~ 5mb | 5 mb download from Google Play | 12 mb after it’s uncompressed.
- x86 apk (Only that abi) ~ 5mb | 5 mb download from Google Play | 12 mb after it’s uncompressed.
In theory of course. You never save that much but it does shave down quite a bit, especially when uncompressed
That may explain why you only see armeabi-v7a. On my phone, I sometimes see only arm64-v8a
I am working on rebuilt 3rd party libraries with clang+libc++ with NDK r16.
2 Likes
Do you know the new app signing with an upload key instead of the release signature? In theory Google will resign it with your release key, if you do it that way and strip of unneeded drawables (hdpi, xhdpi, xxhdpi…).
Here’s my question I didn’t find any information, if the APK size limit of 100MB is still valid for the unstripped file, if we want to use this feature. I mean, this would make a pro active APK split unnecessary, because Google will do it for use.
So it would be the best solution to export your assets into a OBB file and let Google split your APK. Right?
True, but I think were mainly talking about the included .so libraries the are generated for the game. I’m not sure if the new app signing will split the apk by abi as well.
Let me do some research 
1 Like
Currently, Google will only shrink the APK, afaik.
Deprecated in r16. Will be removed in r17. No hard float.
v8a devices runs armeabi-v7a libraries without any problems.
So, developers just use v7s for any mobile games.
This is just your opinion. If someone has a option, he/she will compile for that platform and don’t use old an ABI. The compiler will optimise the code for v8a, so why on earth shouldn’t we use it as target? Only because you are one person who is not willing to use it? I don’t think so.
2 Likes
Sometimes I wish to be able to like a post several times…
2 Likes
update all libs with clang+libc++: https://github.com/cocos2d/cocos2d-x-3rd-party-libs-bin/pull/310
1 Like