AAR bundle support for x86 native libs

[Dan O'Neill]

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?  

[jdONeill gMail]

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

--
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]

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?

--

Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[jdONeill gMail]

Thanks Xavier:  I looked inside the APK and confirmed the x86 .so is in the libs/ folder.  The java.lang.UnsatisfiedLinkError implys that the app is attempting to load a native lib but the lib could not be found.  Is it possible that it found the lib but could not load it?  It detects the x86 native lib when building as described in #1 below.  Why would that same lib work when adding it manually to an app module?  Loading manually is a workaround, but I would prefer the ability to use the AAR bundle across all platforms. 

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!

[jdONeill gMail]

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!

[Xavier Hallade]

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.

[jdONeill gMail]

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.

[Xavier Hallade]

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.

[Dan O'Neill]

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

[Xavier Hallade]

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.

[Dan O'Neill]

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.