Android虽然基于Linux系统，但Android本身做了大量的修改。其中对于系统C库更是自己重新实现——Bionic库。在源码目录结构中bionic可以找到相关内容。话题好像偏离有点远，但System.loadLibrary最终还是调用到bionic库中的函数dlopen。这个dlopen搜索依赖so的路径与Linux本身有着不一样的实现，并且在4.2.2版本及以下有着无法隐式加载app目录下依赖so的缺陷，直到4.3才被修复。
关于System.loadLibrary和System.load两个在java中加载so的方法，已经有人进行个大致的分析（Java中System.loadLibrary() 的执行过程 文章中的分析内容是4.2.2版本，仍然不支持隐式加载app目录下依赖so），可以先看看这篇文章里关于以上两个java函数的实现，了解大部分的流程。然后，这里就要开始从dlopen开始分析，对于依赖so加载的问题。
具体分析
首先来看这样一个例子，有两个so，liba.so、libb.so。其中，liba.so引用了libb.so导出的符号，并且是直接引用符号，也就是
需要加载器在运行时的动态隐式链接。在加载liba.so的时候，Java层里，我们会调用System.loadLibrary()，或者System.load()来
指定so的路径，然后最终会调用到native代码中，使用dlopen加载liba.so，就会根据liba.so的Dynamic section中列出类型为
DT_NEEDED的依赖共享库so，并且会递归地一个一个地加载依赖so。在LInux下，加载这些依赖so的路径会是 1. 环境变量LD_LIBRARY指明的路径。2. /etc/ld.so.cache中的函数库列表；3/lib目录，然后/usr/lib。但在4.2.2版本的Android的Bionic实现中，加载的目录只有LD_LIBRARY_PATH变量所指示的路径以及被hardcode进代码的/system/lib，/vendor/lib这两个路径。而事实上LD_LIBRARY_PATH是不建议修改的，而且默认值在Android中也是/system/lib，/vendor/lib这两个路径，因此事实上，被依赖的so加载路径只有/system/lib，/vendor/lib这两个！
不过这种问题在4.3开始得到改正。在4.3版本的代码里，nativeLoad这个方法接受多一个参数ldLibraryPath，这是通过PathClassLoader获取App的native lib路径，然后传给nativeLoad的。nativeLoad在获取这个参数之后，就会调用bionic的方法来显式更新内部的ldPath路径，这样每次加载的时候，就可以先搜索本地App的native lib路径，就能够正确加载依赖的so。
首先我们来看看4.3版本的实现：
private String doLoad(String name, ClassLoader loader) {
// Android apps are forked from the zygote, so they can't have a custom LD_LIBRARY_PATH,
// which means that by default an app's shared library directory isn't on LD_LIBRARY_PATH.
// The PathClassLoader set up by frameworks/base knows the appropriate path, so we can load
// libraries with no dependencies just fine, but an app that has multiple libraries that
// depend on each other needed to load them in most-dependent-first order.
// We added API to Android's dynamic linker so we can update the library path used for
// the currently-running process. We pull the desired path out of the ClassLoader here
// and pass it to nativeLoad so that it can call the private dynamic linker API.
// We didn't just change frameworks/base to update the LD_LIBRARY_PATH once at the
// beginning because multiple apks can run in the same process and third party code can
// use its own BaseDexClassLoader.
// We didn't just add a dlopen_with_custom_LD_LIBRARY_PATH call because we wanted any
// dlopen(3) calls made from a .so's JNI_OnLoad to work too.
// So, find out what the native library search path is for the ClassLoader in question...
String ldLibraryPath = null;
if (loader != null && loader instanceof BaseDexClassLoader) {
ldLibraryPath = ((BaseDexClassLoader) loader).getLdLibraryPath();
}
// nativeLoad should be synchronized so there's only one LD_LIBRARY_PATH in use regardless
// of how many ClassLoaders are in the system, but dalvik doesn't support synchronized
// internal natives.
synchronized (this) {
return nativeLoad(name, loader, ldLibraryPath);
}
}
static void Dalvik_java_lang_Runtime_nativeLoad(const u4* args, JValue* pResult)
{
//......
StringObject* ldLibraryPathObj = (StringObject*) args[2];
if (ldLibraryPathObj != NULL) {
char* ldLibraryPath = dvmCreateCstrFromString(ldLibraryPathObj);
void* sym = dlsym(RTLD_DEFAULT, "android_update_LD_LIBRARY_PATH");
if (sym != NULL) {
typedef void (*Fn)(const char*);
Fn android_update_LD_LIBRARY_PATH = reinterpret_cast<Fn>(sym);
(*android_update_LD_LIBRARY_PATH)(ldLibraryPath);
} else {
ALOGE("android_update_LD_LIBRARY_PATH not found; .so dependencies will not work!");
}
free(ldLibraryPath);
}
//......
}
可以看到nativeLoad方法会通过显式获取bionic库中的android_update_LD_LIBRARY_PATH方法，然后这个路径最终会更新bionic库的全局变量gLdPaths，这个变量在加载依赖so的时候会产生作用。
static int open_library_on_path(const char* name, const char* const paths[]) {
char buf[512];
for (size_t i = 0; paths[i] != NULL; ++i) {
int n = __libc_format_buffer(buf, sizeof(buf), "%s/%s", paths[i], name);
if (n < 0 || n >= static_cast<int>(sizeof(buf))) {
PRINT("Warning: ignoring very long library path: %s/%s", paths[i], name);
continue;
}
int fd = TEMP_FAILURE_RETRY(open(buf, O_RDONLY | O_CLOEXEC));
if (fd != -1) {
return fd;
}
}
return -1;
}
static int open_library(const char* name) {
TRACE("[ opening %s ]", name);
// If the name contains a slash, we should attempt to open it directly and not search the paths.
if (strchr(name, '/') != NULL) {
int fd = TEMP_FAILURE_RETRY(open(name, O_RDONLY | O_CLOEXEC));
if (fd != -1) {
return fd;
}
// ...but nvidia binary blobs (at least) rely on this behavior, so fall through for now.
}
// Otherwise we try LD_LIBRARY_PATH first, and fall back to the built-in well known paths.
int fd = open_library_on_path(name, gLdPaths);
if (fd == -1) {
fd = open_library_on_path(name, gSoPaths);
}
return fd;
}在4.3以下的版本里，gLdPaths的初始化是在linker的初始化里通过读取LD_LIBRARY_PATH来决定的，并不是像4.3这样可以每次动态更新。具体实现如下：
/* skip past the environment */
while(vecs[0] != 0) {
if(!strncmp((char*) vecs[0], "DEBUG=", 6)) {
debug_verbosity = atoi(((char*) vecs[0]) + 6);
} else if(!strncmp((char*) vecs[0], "LD_LIBRARY_PATH=", 16)) {
ldpath_env = (char*) vecs[0] + 16;
}
vecs++;
}
//......
/* Use LD_LIBRARY_PATH if we aren't setuid/setgid */
if (ldpath_env && getuid() == geteuid() && getgid() == getegid())
parse_library_path(ldpath_env, ":");以上这段代码是在__linker_init函数里的代码片段，parse_library_path函数的作用就是设置加载依赖so的路径。另外，关于至于如何解析so里的dynamic section以及如何加载，并且初始化so等这里不属于本次讨论范畴，就不再赘述了。
解决办法：
由于加载依赖so的路径在4.3版本以前会存在问题（即调用System.loadLibrary("a");会失败），所以我们只能够在显式加载每个依赖最低的库，这样最后加载依赖最高的so就会成功。根据上面的例子，我们可以先显式加载libb.so，然后再加载liba.so。代码如下：
System.loadLibrary("b");
System.loadLibrary("a");