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.
