省流：android 不兼容 glibc，而是写了一套独立的 c 运行时库 (bionic libc)，为移动设备和 google 自己推的东西做了大量优化。在这套工具链里，aosp 实现了一个兼容 bionic libc 的链接器，放到系统中代替 ld。

这个链接器叫 linker，二进制放在 /bin 和 /system/bin 目录下。

好像有点跑题了，我都忘了在哪看到的 linker 才写到这里的。可能是 frida 用了 Interceptor hook 的 linker

扯回来。在 Java 的应用层代码里写 System.loadLibrary 后，会经历如下调用栈

// java
System.loadLibrary
Runtime.loadLibrary0
// jni
// c
Runtime_nativeLoad
JVM_NativeLoad
// cc
art::JavaVMExt::LoadNativeLibrary // 检查是否是要 load 已有 library，不是的话调用 OpenNativeLibrary(dlopen) 获取 handle、创建 library 对象、查找 JNI_Onload 的 sym，没有的话直接 return true.
android::OpenNativeLibrary
OpenSystemLibrary ...(android_dlopen_ext/dlopen)

其中，从 nativeLoad 开始，执行流通过 jni 跳转到了 c 函数 Runtime_nativeLoad。可以查看 Runtime.c - Android Code Search ，往里跟踪的其他 c 文件

看样子最后还是用的 dlopen

详解每一轮调用：

​​​Android动态库的加载原理，真的理解了吗？一文带你游览动态库的加载流程，从 Java 到 C++，一步一步探索知识的 - 掘金