CODEWITHSUNDEEP
android-ndkandroid-gradle-plugin
Nepho
Nepho

Reputation: 1112

Shared library bundled in the apk is not found at runtime

I do some native Android development which involves OpenSSL.

I cross compile it for armeabi (32b) using the Android NDK stand-alone toolchains. I cross-compile the native C libraries, copy the OpenSSL/native library .so files inside of my libs/ folder, which is referenced by my gradle this way:

sourceSets {
    main {
        jniLibs.srcDir(file("libs/"))
    }
}

Anyway, the end result is that my .apk looks like this:

 - > classes.dex
 - > lib/
     -> armeabi/
        -> libcrypto.so
        -> libssl.so
        -> libmynativelibrary.so
 - > res/ (...)
 - > resources.arsc
 - > META-INF/ (...)
 - > kotlin/ (...)
 - > AndroidManifest.xml

The shared libraries are correct 32-bit ARM ELF files. I've been using this exact APK on an API level 24 device with great success (Android 7.0+).

The issue: When I switch to an API level 21 device (Android 5.1-, I suspect that I would have the same issue with Android 6.0), the program instantly crashes when loading libmynativelibrary.so.

Since libcrypto.so is a dependency of libmynativelibrary.so, the program attempts to load it. It actually works fine on API level 24+, but crashes on API level 23-. It's because the loaded library is not the one in my .apk, but the one in the system. And such libraries seem to not be available below API level 24.

My question: How do I explicitly tell Android to look for the library in the .apk file first instead of the regular system libraries directories?

Thanks in advance.

Upvotes: 2

Views: 1447

Answers (1)

Alex Cohn
Alex Cohn

Reputation: 57203

Before Nogut, the system libraries were not protected from user apps. The name collisions are problematic, they caused Google to invent a separate namespace for the C++ shared runtime library, which is part of Android NDK.

The OpenSSL libraries are also widely used beyond your control. They may get loaded into your process even before you have a chance to load your own libssl.

Therefore, the best choice would be to build OpenSSL as static libs, and have libmynativelibrary.so linked to it statically. This way you have a monolithic binary that does not depend on others.

If you cannot follow this course, you should build OpenSSL libraries with mangled names, e.g. libmyssl.so and libmycrypto.so. This may help to avoid the simple name clash with system libraries.

Even better, follow the example of NDK and provide a unique namespace to you SSL API.

Don't expect that loading the libraries explicitly from their unpacked location at ApplicationInfo.nativeLibraryDir will be a robust solution: as I hunted before, the system libraries may happen to get loaded into your address space before.

Note that before Lollipop, you have too manually load all non-system dependencies, and in the proper order.

Also, the new NDK has dropped armeabi , so consider switching to armeabi-v7a.

Upvotes: 2

Related Questions