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

最新推荐文章于 2024-09-06 20:19:29 发布

原创最新推荐文章于 2024-09-06 20:19:29 发布 · 8k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#android #jni #file #library #java #button

android 专栏收录该内容

4 篇文章

订阅专栏

在尝试使用JNI加载libhello.so时遇到错误，系统提示无法找到库。通过strace工具跟踪系统调用发现库已被成功打开并读取。问题出在未解析的符号上，这些符号存在于libc.so中。通过在Android.mk中添加LOCAL_STATIC_LIBRARIES:=libc，静态链接libc解决了部分问题，尽管仍有少量符号未链接。最终，libhello.so得以成功加载运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在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被成功加载运行。

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