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 <javascript:>.
> 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.

Reply via email to