1

As stated in Android ABIs guide: https://developer.android.com/ndk/guides/abis

The section Automatic extraction of native code at install time states that:

When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:

lib/<primary-abi>/lib<name>.so

If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:

lib/<secondary-abi>/lib<name>.so

Background: My app depends on an external library accessed through the JNI interface, but I was only provided with the e.g. libLibrary.so file for the armeabi architecture. My app also uses another library which supports few different architectures like arm64-v8a etc. So, at runtime, I got an error like this because it couldn't find the libLibrary.so:

java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[... /system/lib64]]] couldn't find "libLibrary.so"

Edit:

I was wondering if it is fine if I copied the libLibrary.so from the armeabi folder into armeabi-v7a folder when the other libraries I depend on have .so files for armeabi-v7a but not armeabi. I have tested my app and it uses the library without problems when I set in gradle:

ndk.abiFilters "armeabi-v7a"

to only output the armeabi-v7a libraries in the apk file to make the app use them only.

So, I am wondering if it is just fine like that. I am using what is suggested here: https://medium.com/livefront/native-android-libraries-gone-bad-e7ff63f34bb

Yao Jenn
  • 55
  • 6
  • 2
    You must provide all of your native libraries for the same set of ABIs; you can't mix and match. Also, if your app contains 32-bit libraries it must also contain the corresponding 64-bit libraries if you want to be able to publish the app on Google Play. – Michael Sep 25 '19 at 05:33
  • 1
    As far as the quote from the NDK guide is concerned, it's a bit strangely worded. I think you should interpret it as _"If none is found, and **the device manufacturer has** defined a secondary ABI, the service scans for shared libraries of the form..."_ – Michael Sep 25 '19 at 06:18

1 Answers1

1

As Michael writes, you cannot deploy an app with partial support for arm64-v8a. As long as you don't upload the app to Play Store (e.g. during development and testing), you should strip away the 64-bit binaries from your APK. As of today, all devices will still run an armeabi binary, but I expect 64-bit only devices in coming years.

If you intend to distribute the app via Google Play Store, you must make sure your app runs without 32-bit binaries. Sometimes, when the sources of a native lib are not available, it's easier to reproduce the missing functionality in Java/Kotlin.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • Thanks for the answer, I am aware of the Google Play restriction. I have edited the question, do you have an idea on the edit? – Yao Jenn Sep 25 '19 at 14:34
  • 1
    To say it's OK would be an overstatement. The differences between armeabi and armeabi-v7a are subtle; as I explained few years ago (https://stackoverflow.com/a/12234840/192373), calls from arnv7 to armv6 libs will probably be ok, as long as they don't involve floating point parameters. – Alex Cohn Sep 25 '19 at 19:01