Software Archive
Read-only legacy content

Problem with Android application that contain native libraries for multiple platforms

Andriy_Y_
Beginner
687 Views

Hi Guys,

I stuck with one problem and really hope somebody can help me to shed some light on this...

My Android application contains native libraries for the next platforms:

armeabi

armeabi-v7a

x86

It works fine on any ARM based device and uses corresponding armeabi libraries.

I tested it also on Intel based x86 Samsung Galaxy Tab and it also works fine and loads corresponding x86 library.

Today I tested it on ASUS Phonepad and discovered that instead of loading x86 library it prefers to load armeabi instead. If I remove armeabi libraries from APK it does load x86 library and works fine but I need to have all three sets of libraries for all platforms.

From the system log I can also see that system tries to use houdini library to translate my ARM based native library into x86 (which doesn't make any sense as I have x86 based library provided):

07-25 12:37:55.011    9207-9220/net.myapp D/houdini﹕ [9220] Loading library(version: 3.4.7.44914 RELEASE)... successfully.

So my question is, what am I doing wrong so it doesn't load x86 based library? Should I add some other ABI into the APK?

My cpuinfo is as follows:

c/cpuinfo                                                                     <
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 53
model name      : Intel(R) Atom(TM) CPU Z2520  @ 1.20GHz
stepping        : 1
microcode       : 0x10e
cpu MHz         : 800.000
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf nonstop_tsc_s3 pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat dtherm tpr_shadow vnmi flexpriority
bogomips        : 2396.16
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

Thanks for you help!

0 Kudos
2 Replies
Xavier_H_Intel
Employee
687 Views

Hi,

because in certain markets, many developers have a broken set of x86 libraries (mainly missing some libs for x86), a workaround has been implemented on some devices to avoid these apps to crash: by falling back to the arm libs.

if you have different names and count of libs depending on the architecture, this workaround can cause the issue you're encountering.

Device software updates should fix these side-effects as this workaround is being improved, but in the meantime, if you want to support these devices, I can only recommend having the same set of libs names and numbers for each architectures to make it work.

0 Kudos
Andriy_Y_
Beginner
687 Views

Hi Xavier,

Thank you for your response.

I can confirm that making sure that both targets contain the same sets of native libraries makes it choose x86 based libraries which fixes the issue in my case. In terms of my application it means that I have to include some dummy libraries in my x86 target just for the sake of making it matching with what ARM target provides but the fact the this will be resolved in one of the upcoming release is the great news.

Thanks again for your help!

0 Kudos
Reply