android JNI (2) - load .so file with JNI

在android JNI (1) 中，生成了一个libhello.so, 将libhello.so 使用adb push到模拟器的/system/lib中，修改文件权限为可读，之后运行Java上层应用。当运行到system.loadlibrary("hello")时，系统屏幕出现弹出窗口，并且结束了虚拟机的运行。使用adb logcat获取log, 错误部分的log为：

 

D/dalvikvm(  597): LOADING path /system/lib/libFnord.so 0x4006c4f8
I/dalvikvm(  597): Unable to dlopen(/system/lib/libFnord.so): Cannot find library

同时虚拟机还在java层抛出UnsatisfiedLinkError异常。

起初以为是libhello.so 位置放错了，或者libhello.so没有读的权限。但是确认后排除了这两种可能。

 

而后使用android strace来trace系统调用，strace 需要自行安装。具体使用方式在Java代码调用system.loadlibrary前使应用sleep, 或者用一个button click来触发加载。运行java应用，使用adb shell ps查询此应用的pid. 再将此pid attach到strace中， 使用 adb shell strace -p pid. 点击button, 触发system.loadlibrary加载Native动态库，可以得到strace 信息：

stat64("/system/lib/libhello.so", {st_mode=S_IFREG|0666, st_size=816132, ...}) = 0
open("/system/lib/libhello.so", O_RDONLY|O_LARGEFILE) = 31
lseek(31, 0, SEEK_SET)                  = 0
read(31, "/177ELF/1/1/1/0/0/0/0/0/0/0/0/0/3/0(/0/1/0/0/0/234/267"..., 4096) = 4096
lseek(31, -8, SEEK_END)                 = 816124
read(31, "/1/0/0/0/0/0/0/0", 8)         = 8
mmap2(0x80400000, 815104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x80400000
mmap2(0x80400000, 806756, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 31, 0) = 0x80400000
mprotect(0x80400000, 806912, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mmap2(0x804c5000, 4684, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 31, 0xc5) = 0x804c5000
close(31)                               = 0
munmap(0x80400000, 815104)              = 0
writev(5, [{"/4", 1}, {"dalvikvm/0", 9}, {"Unable to dlopen(/system/lib/lib"..., 64}], 3) = 74
由此也可以看到libhello.so已经被系统被成功打开，而且数据也被成功读取。

 

Cannot find library是使用dlerror输出的的错误信息，通过分析dlerror代码，发现不只是文件找不到会导致Cannot find library 错误, 在加载过程中其他任何的错误都会输出同样的问题。

 

在Android Developers 邮件列表的一个帖子http://groups.google.com/group/android-developers/browse_thread/thread/636d11723aae3117/bd9f19e197e82a24?lnk=gst&q=unresolved+symbols+%26+jni#bd9f19e197e82a24，发现了一个突破口。

 

libhello.so的Unresolved symbols可能会导致加载器加载失败，由此说来，这似乎是android JNI加载器在加载多各互相依赖的动态库的bug。 使用Toolchain的objdump工具

arm-eabi-objdump -T libhello.so | grep -e UND. 发现果然在libhello.so有不少未定义的符号。这些符号存在于其他的动态库中，比如c标准库libc.so中。因此， 将工程的Android.mk添加一个变量定义:

LOCAL_STATIC_LIBRARIES:=libc

将libc静态的链接到libhello.so中。 值得注意的是， 使用android build系统的链接器链接会出现部分符号不链接的情况，也就是说，虽然采用静态的连接libc, libhello.so仍然有少量的符号为UNDefined属性的，而这些符号确实在libc.a中存在，这部分符号依然需要在运行时由libc.so中加载运行。原因未知，可能这是链接器的bug吧。 幸运的是，少量的这类符号没有使加载器报告 Cannot find library的错误。libhello.so被成功加载运行。

 

在这里，我只能够描述这些现象。具体原因目前不清楚，还需要进一步调查。