On this example, the error is "dlopen failed: "/data/app/com.arcgis.android.samples.maps.helloworld-1/lib/x86/libruntimecore_java.so" has unexpected e_machine: 40", that means the lib in the x86 folder is arm instead of x86.
I've checked and I can confirm that the lib inside arcgis .aar, /jni/x86/libruntime_core.so is ARMv5 instead of x86. They put the same ARMv5 lib in all the architecture folders. That's not a Android Studio issue. Regards, Xavier. On Wednesday, January 14, 2015 at 11:01:13 PM UTC+1, Dan O'Neill wrote: > > Yes, I have confirmed that the APK with libs from AAR is exclusively > failing on x86 emulator and working on ARM emulators/devices and x86 > devices. It works in the x86 emulator when I manually package the libs as > well. So this is quite exclusive to x86 emulators. > > Appetize.io is using x86 emulator in a browser where you can see (similar) > issue I have been reporting in debug mode here > > https://appetize.io/debug/private_t0j871u4wnfnaptd7z568zc6h4. > > Regards > -- Dan > > On Thursday, December 18, 2014 at 1:44:38 AM UTC-9, Xavier Hallade wrote: >> >> This looks fine. >> >> Can you confirm that your APK with libs from the AAR is failing on the >> emulators, but not on a real device, and that it is always working when you >> manually package the libs ? >> In that case, can you also check if this behavior happens only on x86 >> emulators, and not arm emulators/arm devices ? >> >> My first guess would be that when you're using the AAR, ProGuard >> optimizes out a native method that you aren't using, and then load is >> failing because ART expect to have all the methods declared on both sides. >> But the fact that it's also crashing on a API 17 emulator invalidates >> this... >> >> You should be able to get more information than just "dlopen failed". >> Especially in the emulators since checkJNI is enabled by default. >> Maybe you've filtered out the JNI debug informations: they should be >> tagged D/dalvikvm on the API 17 one. >> >> btw, if you need a x86 device running Lollipop, there are two on the >> market right now: the Nexus Player and the Trekstor Xintron Tab 7: >> http://www.amazon.de/dp/B00NQBW7BU/ >> >> Regards, >> Xavier Hallade. >> >> On Wednesday, December 17, 2014 10:28:34 PM UTC+1, Dan O'Neill wrote: >>> >>> Here are the results from running readelf: >>> >>> greadelf -h >>> ELF Header: >>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>> Class: ELF32 >>> Data: 2's complement, little endian >>> Version: 1 (current) >>> OS/ABI: UNIX - System V >>> ABI Version: 0 >>> Type: DYN (Shared object file) >>> Machine: Intel 80386 >>> Version: 0x1 >>> Entry point address: 0x0 >>> Start of program headers: 52 (bytes into file) >>> Start of section headers: 32680124 (bytes into file) >>> Flags: 0x0 >>> Size of this header: 52 (bytes) >>> Size of program headers: 32 (bytes) >>> Number of program headers: 7 >>> Size of section headers: 40 (bytes) >>> Number of section headers: 24 >>> Section header string table index: 23 >>> >>> greadelf -d | grep NEEDED >>> 0x00000001 (NEEDED) Shared library: [libGLESv2.so] >>> 0x00000001 (NEEDED) Shared library: >>> [libjnigraphics.so] >>> 0x00000001 (NEEDED) Shared library: [liblog.so] >>> 0x00000001 (NEEDED) Shared library: [libEGL.so] >>> 0x00000001 (NEEDED) Shared library: [libm.so] >>> 0x00000001 (NEEDED) Shared library: [libc.so] >>> 0x00000001 (NEEDED) Shared library: [libdl.so] >>> >>> I don't have an x86 device with lollipop, but am looking to get one to >>> test on. >>> >>> Regards >>> -- Dan >>> >>> On 12/16/14, 12:46 AM, Xavier Hallade wrote: >>> >>> Hi, >>> >>> Do you have any further information than "dlopen failed" ? >>> In any case, you can use readelf or my application: >>> https://play.google.com/store/apps/details?id=com.xh.nativelibsmonitor.app&hl=en >>> to check if the .so that is getting packaged/installed is well formed, >>> for x86 architecture, and that it has no non-ndk dependencies. >>> >>> If your lib is compiled for arm but is inside your x86 folder, you >>> would get a dlopen failure on x86 emulators as well as x86 devices running >>> lollipop, and it would still work on x86 devices running Jelly Bean. >>> >>> Regards, >>> Xavier Hallade. >>> >>> On Monday, December 15, 2014 9:38:32 PM UTC+1, Dan O'Neill wrote: >>>> >>>> Did some further testing on an x86 device and found the following >>>> results: >>>> >>>> > x86 *.so bundled in AAR is working on Intel x86 device (API 17) >>>> > x86 *.so bundled in AAR is fails as described in this thread on x86 >>>> emulator (API 21 & API 17) >>>> >>>> I am going to try some other devices, but it seems the issue is with >>>> the x86 emulator. Can anybody else confirm this? >>>> >>>> Regards >>>> -- Dan >>>> >>>> >>>> On 12/10/14, 3:26 PM, Xavier Ducrohet wrote: >>>> >>>> Look inside the APK and see how the .so are packaged. We don't do >>>> anything special for x86 libraries, we just package whatever is there. >>>> >>>> From the first email, it just looks like the .so is broken? >>>> >>>> On Wed, Dec 10, 2014 at 12:26 PM, jdONeill gMail <jdonei...@gmail.com> >>>> wrote: >>>> >>>>> I have confirmed a couple of things: >>>>> >>>>> 1. Adding /src/main/jniLibs/x86/<native>.so causes errors when >>>>> building with gradle and the AAR bundle. It detects the presence of >>>>> both >>>>> libs. >>>>> 2. Removing the AAR bundle and adding >>>>> /src/main/jniLibs/x86/<native>.so and all dependency jars in libs/ folder >>>>> at root of project works on x86 emulator. >>>>> >>>>> Can anyone confirm support for x86 native libs bundled in AAR? It >>>>> would seem it is not supported. >>>>> >>>>> Regards >>>>> -- Dan >>>>> >>>>> >>>>> >>>>> On 12/9/14, 4:33 PM, Dan O'Neill wrote: >>>>> >>>>> I am bundling native libs in an AAR bundle under the '/jni/<abi>/*.so' >>>>> location. The ABI native libs work but when running on x86 emulator >>>>> the >>>>> app with AAR dependency crashes with the following cause:  >>>>> >>>>> Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: >>>>> "/data/app/<package>.helloworld-1/lib/x86/<native>.so" >>>>> >>>>> The native libs in the AAR look like this: >>>>> >>>>> /jni/armeabi-v7a/<native>.so >>>>> /jni/armeabi/<native>.so >>>>> /jni/x86/<native>.so >>>>> >>>>> What am I missing?  >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "adt-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to adt-dev+u...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "adt-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to adt-dev+u...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Xavier Ducrohet >>>> Android SDK Tech Lead >>>> Google Inc. >>>> http://developer.android.com | http://tools.android.com >>>> >>>> Please do not send me questions directly. Thanks! >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "adt-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to adt-dev+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "adt-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to adt-dev+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
