Android 分析Native库的加载过程及x86系统运行arm库的原理
本文主要讲述Android 加载动态链接库的过程，为了分析工作中遇到的一个问题 x86的系统是如何运行arm的动态链接库的。
参考博客：
https://pqpo.me/2017/05/31/system-loadlibrary/ 深入理解 System.loadLibrary
https://www.jianshu.com/p/bf8b4a90f825 Android Native库的加载及动态链接
https://blog.csdn.net/groundhappy/article/details/80493358 android的native_bridge
基于android7.0代码，涉及文件：
libcore\ojluni\src\main\java\java\lang\System.java
libcore\ojluni\src\main\java\java\lang\Runtime.java
libcore\dalvik\src\main\java\dalvik\system\PathClassLoader.java
libcore\dalvik\src\main\java\dalvik\system\DexClassLoader.java
libcore\ojluni\src\main\native\Runtime.c
art\runtime\openjdkjvm\OpenjdkJvm.cc
art\runtime\java_vm_ext.cc
system\core\libnativeloader\native_loader.cpp
bionic\linker\dlfcn.cpp
bionic\linker\linker.cpp
android是基于linux系统的，在开始前像看下Linux系统下是如何加载动态链接库有助于理解Android的动态库加载流程。
Linux环境下加载动态库主要包括如下函数，位于头文件dlfcn.h中：同样android的函数也位于dlfcn.h头文件中。
void *dlopen(const char *filename, int flag); //打开动态链接库
char *dlerror(void); //获取错误信息
void *dlsym(void *handle, const char *symbol); //获取方法指针
int dlclose(void *handle); //关闭动态链接库
用一个简单的C++代码，作为动态链接库包含计算相关的函数：(懒 使用的参考文章中demo)
extern "C"
int add(int a, int b) {
return a + b;
}
extern "C"
int mul(int a, int b) {
return a*b;
}
extern “C” 表示告诉编译器以C的方式编译，不要修改函数名，否则C++会修改函数名。
然后通过下述命令编译成动态链接库：
g++ -fPIC -shared caculate.cpp -o libcaculate.so
这样会在同级目录下生成一个动态库文件：libcaculate.so
然后编写加载动态库并使用的代码：
[main_call.cpp]
#include 主要就用到了上面的4个函数过程如下
1、打开动态库，拿到一个动态库句柄
2、通过句柄和方法名获取方法指针地址
3、将方法地址强制类型转换成方法指针
4、调用动态库中的方法
5、通过句柄关闭动态库。
中间会使用dlerror检测是否有错误。
有必要解释一下的是方法指针地址到方法指针的转换，为了方便这里定义了一个方法指针的别名：
typedef int (*CACULATE_FUNC)(int, int);
指明该方法接受两个int类型参数返回一个int值。
拿到地址之后强制类型转换成方法指针用于调用：
CACULATE_FUNC addFunc = reinterpret_cast(symAdd);
最后只要编译运行即可：
g++ -std=c++11 -ldl main_call.cpp -o main
.main
因为代码中使用了c++11标准新加的特性，所以编译的时候带上-std=c++11，另外使用了头文件dlfcn.h需要带上-ldl，编译生成的main文件即是二进制可执行文件，需要将动态库放在同级目录下执行。
上面就是Linux环境下创建动态库，加载并使用动态库的全部过程。
由于Android基于Linux系统，所有Android系统底层也是通过这种方式加载并使用动态库的。
Android 链接器Linker之前的工作
流程图来自参考的另一篇博客
下面从System.loadLibrary() 开始分析
public static void loadLibrary(String libname) {
//VMStack.getCallingClassLoader() 返回应用类加载器这里是：PathClassLoader
Runtime.getRuntime().loadLibrary0(VMStack.getCallingClassLoader(), libname);
}下面看* loadLibrary0()*
synchronized void loadLibrary0(ClassLoader loader, String libname) {
if (libname.indexOf((int)File.separatorChar) != -1) {
throw new UnsatisfiedLinkError(
"Directory separator should not appear in library name: " + libname);
}
String libraryName = libname;
if (loader != null) {
//findLibrary()返回的是库的全路径名，loader是PathClassLoader 最终会
//调用父类的findLibrary()方法。
String filename = loader.findLibrary(libraryName);
//这里可以通过Logger 来打印log 因为这时候 util.log是无法执行到这里
Logger logger = Logger.getLogger("lly");
logger.info("filename == "+filename);
logger.info("mapLibraryName == "+System.mapLibraryName(libraryName));
if (filename == null) {
// It's not necessarily true that the ClassLoader used
// System.mapLibraryName, but the default setup does, and it's
// misleading to say we didn't find "libMyLibrary.so" when we
// actually searched for "liblibMyLibrary.so.so".
throw new UnsatisfiedLinkError(loader + " couldn't find \"" +
System.mapLibraryName(libraryName) + "\"");
}
//装载动态库
String error = doLoad(filename, loader);
if (error != null) {
throw new UnsatisfiedLinkError(error);
}
return;
}
......
}
参数loader为Android的应用类加载器，它是PathClassLoader 类型的对象，继承自BaseDexClassLoader对象
public String findLibrary(String name) {
return pathList.findLibrary(name);
}最终会调用DexPathList 的findLibrary()方法
public String findLibrary(String libraryName) {
//生成平台相关的库名称这里会返回libxxx.so
String fileName = System.mapLibraryName(libraryName);
for (Element element : nativeLibraryPathElements) {
//查找动态库返回的全路径名
String path = element.findNativeLibrary(fileName);
if (path != null) {
return path;
}
}
return null;
}
回到loadLibrary0()，有了动态库的全路径名就可以装载库了，下面看doLoad()。
private String doLoad(String name, ClassLoader loader) {
String librarySearchPath = null;
if (loader != null && loader instanceof BaseDexClassLoader) {
BaseDexClassLoader dexClassLoader = (BaseDexClassLoader) loader;
librarySearchPath = dexClassLoader.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, librarySearchPath);
}
}nativeLoad最终调用Runtime.c中的Runtime_nativeLoad(),接着调用OpenjdkJvm.cc 中的 JVM_NativeLoad() ,最终会调用到 Java_vm_ext.cc 中的LoadNativeLibrary() so加载的过程主要在这个函数中完成，参照上面的Linux加载so的流程，我们分析下这个方法：
bool JavaVMExt::LoadNativeLibrary(JNIEnv* env,
const std::string& path,
jobject class_loader,
jstring library_path,
std::string* error_msg){
//1、打开动态链接库
void* handle = android::OpenNativeLibrary(env,
runtime_->GetTargetSdkVersion(),
path_str,
class_loader,
library_path);
//这里是x86为兼容arm库文件采用的方案 使用houdini技术，在运行时动态转化指令集，从而实现对arm库的支持。
bool needs_native_bridge = false;
if (handle == nullptr) {
if (android::NativeBridgeIsSupported(path_str)) {
handle = android::NativeBridgeLoadLibrary(path_str, RTLD_NOW);
needs_native_bridge = true;
}
}
if (handle == nullptr) {
//检查错误信息
*error_msg = dlerror();
VLOG(jni) << "dlopen(\"" << path << "\", RTLD_NOW) failed: " << *error_msg;
return false;
}
if (env->ExceptionCheck() == JNI_TRUE) {
LOG(ERROR) << "Unexpected exception:";
env->ExceptionDescribe();
env->ExceptionClear();
}
// Create a new entry.
// TODO: move the locking (and more of this logic) into Libraries.
bool created_library = false;
{
// Create SharedLibrary ahead of taking the libraries lock to maintain lock ordering.
std::unique_ptr<SharedLibrary> new_library(
new SharedLibrary(env, self, path, handle, class_loader, class_loader_allocator));
MutexLock mu(self, *Locks::jni_libraries_lock_);
library = libraries_->Get(path);
if (library == nullptr) { // We won race to get libraries_lock.
library = new_library.release();
libraries_->Put(path, library);
created_library = true;
}
}
if (!created_library) {
LOG(INFO) << "WOW: we lost a race to add shared library: "
<< "\"" << path << "\" ClassLoader=" << class_loader;
return library->CheckOnLoadResult();
}
VLOG(jni) << "[Added shared library \"" << path << "\" for ClassLoader " << class_loader << "]";
bool was_successful = false;
void* sym;
if (needs_native_bridge) {
library->SetNeedsNativeBridge();
}
//2、获取方法地址
sym = library->FindSymbol("JNI_OnLoad", nullptr);
if (sym == nullptr) {
VLOG(jni) << "[No JNI_OnLoad found in \"" << path << "\"]";
was_successful = true;
} else {
// Call JNI_OnLoad. We have to override the current class
// loader, which will always be "null" since the stuff at the
// top of the stack is around Runtime.loadLibrary(). (See
// the comments in the JNI FindClass function.)
ScopedLocalRef<jobject> old_class_loader(env, env->NewLocalRef(self->GetClassLoaderOverride()));
self->SetClassLoaderOverride(class_loader);
VLOG(jni) << "[Calling JNI_OnLoad in \"" << path << "\"]";
typedef int (*JNI_OnLoadFn)(JavaVM*, void*);
//3、强制类型转换成函数指针
JNI_OnLoadFn jni_on_load = reinterpret_cast<JNI_OnLoadFn>(sym);
//4、调用函数
int version = (*jni_on_load)(this, nullptr);
......
library->SetResult(was_successful);
return was_successful;
}arm的so可以运行在x86的系统上原因就是因为这个分支：
if (handle == nullptr) {
if (android::NativeBridgeIsSupported(path_str)) {
handle = android::NativeBridgeLoadLibrary(path_str, RTLD_NOW);
needs_native_bridge = true;
}
}当调用OpenNativeLibrary()打开so时会去读取so文件的信息，x86的头文件和arm的头文件信息是不一样的，所有在用x86的的手机上运行arm的so文件时handle为空，这时候会根据so文件的绝对路径来判断是否支持houdini，如果支持的话会用NativeBridgeLoadLibrary()
重新打开so文件，进行下一步操作。测试已知支持arm so文件的路径有：
/data/app/包名/lib/arm/libxxx.so
/system/priv-app/应用名称/lib/arm/libxxx.so
到这里其实我的问题已经解决了，关于为什么会去这些路径下找，由于Native Bridge不开源，是以so的方式提供的，没有办法跟进去，望知道的分享一下。
下面看下Android 链接器Linker的装载过程
其中会在load_library 读取ELF文件头以及一些段信息
static bool load_library(android_namespace_t* ns,
LoadTask* task,
LoadTaskList* load_tasks,
int rtld_flags,
const std::string& realpath){
......
if (!task->read(realpath.c_str(), file_stat.st_size)) {
soinfo_free(si);
task->set_soinfo(nullptr);
return false;
}
.......
return true;
}
看下Read方法
bool ElfReader::Read(const char* name, int fd, off64_t file_offset, off64_t file_size) {
CHECK(!did_read_);
CHECK(!did_load_);
name_ = name;
fd_ = fd;
file_offset_ = file_offset;
file_size_ = file_size;
if (ReadElfHeader() &&
VerifyElfHeader() &&
ReadProgramHeaders() &&
ReadSectionHeaders() &&
ReadDynamicSection()) {
did_read_ = true;
}
__libc_format_log(ANDROID_LOG_DEBUG, "lly", "did_read_ == %d",did_read_);
return did_read_;
}ReadElfHeader() : 读取ELF文件头信息
VerifyElfHeader() : 校验ELF(文件类型等)
ReadProgramHeaders() : 根据ELF文件头信息获取程序头表
ReadSectionHeaders() : 根据ELF文件头信息获取段头表
ReadDynamicSection() : 获取Dynamic Section的信息
常见的 has unexpected e_machine: 40 就是在 VerifyElfHeader()方法中提示的。
最后看下Native库的动态链接过程：
