UnsatisfiedLinkError - ".so is is 64-bit instead of 32-bit" on an arm64-v8a device

[Kostya Vasilyev]

Hi,

I know there are older similar topics, but this is somewhat different.

I have an app where LoadLibrary fails like this:

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/data/org.kman.AquaMail/files/imageResizer/libimage-resizer-arm64-v8a.so" is 64-bit instead of 32-bit
	at java.lang.Runtime.load(Runtime.java:331)
	at java.lang.System.load(System.java:981)

Some background:

- The .so is not included in "libs", rather I package a bunch of ABI specific variations in the app's assets and extract at runtime based on Build.SUPPORTED_ABIS.

This is to avoid Play blocking installs to devices that have ABIs I don't support (I have: arm-7, arm-8, x86, but not MIPS or x86-64).

- The device is a Lenovo Z90a40, it has a Qualcomm 615 CPU, and runs Android 5.1

- The Build.SUPPORTED_ABI (coming from a debug log) are [arm64-v8a, armeabi-v7a, armeabi]

- Based on the above, my code picks the arm64-v8a variation of the library

- Now we've made it to the error at the start of the message

Am I wrong thinking that since Build.SUPPORTED_ABI has arm64-v8a in the first slot, then this ABI is the one that should be in effect?

I know Android can use a 32-bit process on a 64-bit device if there is a native library packaged in the .apk under a standard path, but this  doesn't apply here.

Further, my Samsung S6 (with a Samsung processor) also reports [arm64-v8a, armeabi-v7a, armeabi], so my code picks the arm64-v8a and then my LoadLibrary succeeds there.

Or, asking in a different way?

What could cause an app's process to be created as 32-bit, even though the first ABI in Build.SUPPORTED_ABI is arm64-v8a?

Is there any way to check for it, to know which ABI asset to use?

-- K

[Detire]

Hi Kostya,

Just wondering did you find any solution for this? I'm having exactly the same issue.

[Wei Ye]

Hi Kostya,

Did you find any solution for it? I'm facing the similar issue on Samsung Galaxy A7.

[Jiri Bruchanov]

This is maybe different problem, but worth to mention it...

My device: Nexus 9 (64bit arm)
One of my app is using library with all ABIs (specifically 32 and 64bit)... 
this library has been loaded first => taken 64bit variation of the .so

Problem raised when i got another library which was only 32bit...
In time of loading this 32bit it crashed, because of incompatibility of mixing 32/64bit native libs...

I guess it could be same problem, that you already loaded some 32bit library and now loading your 64bit version won't work...

It was documented somewhere @google docs, but can't find it..

[Alex Cohn]

Jiri, you should remove all 64-bit libraries from your APK if you have some third-party that does not have a 64-bit flavour (see more in http://stackoverflow.com/a/33928159/192373). With Android Studio, use abiFilters in your build.gradle script.

[Alex Cohn]

The easiest way to choose the correct ABI asset is by analyzing the lib folder prepared by the system installer: if it extracted x86 libraries for you, use the compatible ABI that you extract manually.

If you have no native libraries in your APK that are deployed in 'conventional' way, you can analyze the /proc/self/map file and check which version of system libraries was loaded.

BR,

Alex Cohn

On Tuesday, October 27, 2015 at 11:34:20 PM UTC+2, Kostya Vasilyev wrote:

[Kenneth Geisshirt]

Applying packingOptions is a simple solution: https://corbt.com/posts/2015/09/18/mixing-32-and-64bit-dependencies-in-android.html

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/92b7b813-0c9d-4cd0-892d-faf17ad1497b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kenneth Geisshirt, M.Sc., Ph.D.
Majbøl Allé 18, DK-2770 Kastrup, +45 60 62 71 82

[Yanbo Dang]

Hello everyone, I got the exactly same issues on some of arm64-v8a devices. Did you got some clue to fix it? 

What I am found is that most of the cases happened in Samsung devices and based on our customers feedback,  they downloaded our app from Galaxy Store instead of Play Store. But the problem is our company never push our app to Galaxy Store. OMG.