Android support for x86_64 architecture


#1

Hello, the android developpers have stated that begining in august 2019, apps submitted to the store will have to include native support for 64bits architecture (https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html)

For now the cocos prebuilt libraries doesn’t include the x86_64 architecture, so my question is: Is there any plan to support it, if not, why?

Thanks!!

EDIT (with working workaround):

In order to build cocos2dx external libraries with x86_64 architecture, here are the step you have to follow:

get the cocos2d-external-src from github

open android.ini, add this line undercfg_x86_host_machine="i686-linux-android":

cfg_x86_64_host_machine="x86_64-linux-android"

and add “x86_64” to the line cfg_all_supported_arches=("armv7" "x86" "arm64" "mips")

open build.sh, and replace the check at line 379:

if [ $MY_TARGET_ARCH = "arm64-v8a" ] || [ $MY_TARGET_ARCH = "x86_64" ];then

open bootstrap and replace the check at line 324 (I am not sure if it is needed):

if [ ${ANDROID_ABI} = "x86" ] || [ ${ANDROID_ABI} = "x86_64" ];then

then you can call the build script using:

./build.sh -p=android --libs=LIBRARY_YOU_WANT_IN_x86_64 --arch=x86_64

NOTE: for some reason the compilation fails for luajit… I am still investigating into it.


#2

So I have tried to use the lib generation tool at:

But it also doesn’t have support for android x86_64, and when trying to run it with -p=android, I have an error:

./build.sh -p=android --libs=freetype --arch=armv7
You don't specify a valid build mode, use release mode
checking armv7 is in armv7 x86 arm64 mips
checking freetype is in png zlib luajit websockets curl freetype jpeg tiff webp chipmunk openssl bullet box2d

build armv7 for freetype in android
generating android standalone toolchain for arm
./build.sh: line 306: /build/tools/make-standalone-toolchain.sh: No such file or directory

When trying to build it for ios it works. Any update on this, I don’t really want to build all the 3rd party lib by hand.


#3

I made it work (forgot to set the ANDROID_NDK in the shell). Now it works for all platforms, but still not for x86_64 architexture

EDIT2: after fiddling a bit, the problem lies here:
14 is less than minimum platform for x86_64 (21)

but we can modify the build.sh to target api level 21 by modifying line 379 to:
if [ $MY_TARGET_ARCH = "arm64-v8a" ] || [ $MY_TARGET_ARCH = "x86_64" ];then
and the android.ini config file to include x86_64 in the list of valid architecture (l2! in android.ini):
cfg_all_supported_arches=("armv7" "x86" "arm64" "mips" "x86_64")

The toolchain is generated correctly, unfortunately, the compilation crashes when trying to compile the first lib (png) with an obscure:
Compiler error reporting is too harsh for ./configure (perhaps remove -Werror).


#4

I finally made it work! Check first post to see what to do.


#5

I don’t know any x86_64 device with PlayStore support. I believe we can stay at arm64, which is supported.

PS: I always want to remove prebuilt libraries, so everyone can use any needed platform. But this is another part of the story.


#6

Hello and thanks for your answer.

Here is a list of devices that are x86_64 and have google play support:

acer GT-810
nokia n1
xiaomi MIPAD2

and some other obscure devices.

The problem does not lie in whether or not there is devices that use this architecture, it lies in the fact that google blog explicitly says that if you want to submit apps for a specific architecture, from august 2019 google will require that you upload an app with the matching 64bit support.

From a quick survey, it looks like x86 devices accounts for around 1-2% of all android devices, and thus I need to support it, and thus I need to build my app against the x86_64 architecture, whether or not there are devices in this category (which feels a bit dumb on the google side, maybe they will clarify it at some point)


#7

Correct, Google said 64bit, but was missing the ABI. August 2019 is over a year in the future, so I wouldn’t create such a panic about this x86_64 issue.

More important is targetSdk to be at least on API 26, which will be done in v3.17, because this is needed in Nov 2018.