Yep, that's what happening. For some reason, the device prefers the arm emulation over pure x86. I thought arm was supposed to be the fallback, but it seems that it's not so on these Asus devices.
I wasn't able to find a way to change that behaviour, but I did find something that does work, I'm not sure if it's elegant enough.
I changed the lib name for x86 from OFAndroidApp to OFAndroidApp_x86 by editing the make file:
ifeq ($(ABI),x86)
ABI_PATH = x86
PLATFORM_PROJECT_RELEASE_TARGET = libs/$(ABI_PATH)/libOFAndroidApp_x86.so
PLATFORM_PROJECT_DEBUG_TARGET = libs/$(ABI_PATH)/libOFAndroidApp_x86.so
endif
Then in OFAndroid, I'm trying to load OFAndroidApp_x86 before trying to load the regular OFAndroidApp. That way, x86 devices load successfully and never get to the arm lib part, and arm devices fail the first load and load successfully the second time. Essentially, I disabled the automatic selection of the OS by giving the libs different names:
static {
try{
Log.i("OF","static x86");
System.loadLibrary("OFAndroidApp_x86");
}catch(Throwable ex)
{
try{
Log.i("OF","static init");
System.loadLibrary("neondetection");
if(hasNeon()){
Log.i("OF","loading neon optimized library");
System.loadLibrary("OFAndroidApp_neon");
}else{
Log.i("OF","loading not-neon optimized library");
System.loadLibrary("OFAndroidApp");
}
}catch(Throwable e){
Log.i("OF","failed neon detection, loading not-neon library",e);
System.loadLibrary("OFAndroidApp");
}
}
Log.i("OF","initializing app");
}
What do you think? Is it elegant enough? It would have been better to take the problem out in the root, but I'm not sure where the problem is exactly.. I know it didn't happen on OF from about 3 months ago. My suspicion is in some third parties, probably POCO or openSSL...
Confirmed to be working on both the Asus x86 and regular arm devices.