We have confirmed your assessment and made a fix. Thanks for your time looking into this as we were a bit stumped as to how the arm libs would be working on x86 devices until they started failing on Lollipop devices.
On Thursday, January 15, 2015 at 12:57:37 AM UTC-9, Xavier Hallade wrote: > > 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 <[email protected]> >>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> 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 [email protected]. >>>> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
