Android app linking with updated aosp libraries

Question

This is rewording of a previous questionof mine.

I have a test application I am trying to link with ibicuuc and libicui18n. (This is the first step in a larger project).

I am including these in my project as prebuilt libraries

LOCAL_SHARED_LIBRARIES := libicuuc libicui18n

compiled as-is from the git repository:

https://android.googlesource.com/platform/external/icu4c/

This is the build log from clean:

$ ndk-build
[armeabi-v7a] Prebuilt       : libicui18n.so <= /usr/local/opt/android/libs/libs/armeabi-v7a/
[armeabi-v7a] Install        : libicui18n.so => libs/armeabi-v7a/libicui18n.so
[armeabi-v7a] Prebuilt       : libicuuc.so <= /usr/local/opt/android/libs/libs/armeabi-v7a/
[armeabi-v7a] Install        : libicuuc.so => libs/armeabi-v7a/libicuuc.so
[armeabi-v7a] Compile++ thumb: main <= main.cc
[armeabi-v7a] SharedLibrary  : libmain.so
[armeabi-v7a] Install        : libmain.so => libs/armeabi-v7a/libmain.so

but when the application is run, it links with the libs in /system, not mine

root@flo:/proc/27311 # grep icu maps                                           
40665000-40756000 r-xp 00000000 b3:16 722        /system/lib/libicuuc.so
40756000-4075f000 r--p 000f0000 b3:16 722        /system/lib/libicuuc.so
4075f000-40760000 rw-p 000f9000 b3:16 722        /system/lib/libicuuc.so
4076a000-4089a000 r-xp 00000000 b3:16 721        /system/lib/libicui18n.so
4089b000-408a2000 r--p 00130000 b3:16 721        /system/lib/libicui18n.so
408a2000-408a3000 rw-p 00137000 b3:16 721        /system/lib/libicui18n.so
6fe85000-710ac000 r--s 00000000 b3:16 897        /system/usr/icu/icudt51l.dat
73454000-7467b000 r--s 00000000 b3:16 897        /system/usr/icu/icudt51l.dat

as "my" libs are HEAD, they are linked against version 53 of the library, not the system 51 and the application fails to find symbols.

How can I make the run-time linker load my libraries from /data/data/.../lib ?

(The next stage of this project is to build some libraries not part of aosp, that require libicu)

If I use System.loadLibrary() in the java static, the correct libs appear to be added, but still don't seem to 'replace' the /system versions

D/dalvikvm(28077): Trying to load lib /data/app-lib/com.example.test.nativelibs-2/libicuuc.so 0x41e65670
D/dalvikvm(28077): Added shared lib /data/app-lib/com.example.test.nativelibs-2/libicuuc.so 0x41e65670
D/dalvikvm(28077): No JNI_OnLoad found in /data/app-lib/com.example.test.nativelibs-2/libicuuc.so 0x41e65670, skipping init
D/dalvikvm(28077): Trying to load lib /data/app-lib/com.example.test.nativelibs-2/libicui18n.so 0x41e65670
D/dalvikvm(28077): Added shared lib /data/app-lib/com.example.test.nativelibs-2/libicui18n.so 0x41e65670
D/dalvikvm(28077): No JNI_OnLoad found in /data/app-lib/com.example.test.nativelibs-2/libicui18n.so 0x41e65670, skipping init
D/dalvikvm(28077): Trying to load lib /data/app-lib/com.example.test.nativelibs-2/libmain.so 0x41e65670

Thanks

Answer 1

I think the safest/simplest way would be to rename the libs that you supply yourself, which should only require minor adjustments to the upstream source projects. (If you'd only have one single library you could get away with just renaming the built .so, but when you have two, you need the first one renamed from the start to make the other one refer to it with the right soname.)

One would probably expect that System.loadLibrary would look in your app's private directory before looking in /system/lib , but the issue may be that your process already has loaded these libraries from before, and the bionic linker won't load a library again if the process already has loaded a library with the same name.

If the old libraries already are loaded, this could also lead to another issue, with your code still calling into the old version of the library, or conversely, the system frameworks calling into the new (possibly incompatible) library. This, because these libraries are loaded into the global namespace, and there can only be one definition of a symbol within the global namespace. (One solution to this would be to use symbol versioning, but bionic doesn't support that.) If you run into this, you can either hope that it favors the new version of the library, and that it is compatible with the system libraries that were expecting the old one. Or prefix all non-static symbols in the library to make them unique.