Android-X86集成houdini所做的修改
Android-X86其实是基于Android的源码编译出来的一个X86版本，可以运行在X86系列处理器上。对于应用程序来说，如果全是使用Java语言编写的话，不会有什么问题。就算用到了JNI函数，如果编译出来了一个X86的动态库，并且包含在apk文件中，也不会有问题。要命就要命在有许多应用程序内部，只有ARM指令集的动态库，就不能在Android-X86平台下运行了，并且这类应用还不在少数。为了解决这类兼容性问题，Intel提供了一个叫做Houdini的库，可以在运行时动态转指令集，将ARM指令集翻译成X86指令集再运行，并且这全是在程序在运行的过程中动态翻译的，对应用程序来说完全透明。而且Google自己从5.0开始，也在其AOSP代码中加入了NativeBridge的中间层，帮助类似Houdini之类的应用更好的集成进Android系统中，代码改动量非常的小（具体可以参考《用于Android ART虚拟机JNI调用的NativeBridge介绍》这篇博客）。
但是，通过阅读android-x86-5.1_rc1的源码，以及查看打开NativeBridge下载下来的二进制文件（关于如何打开Android-X86的NativeBridge，可以参考《如何打开Android X86对houdini的支持》这篇博客），还是可以发现和普通的AOSP代码有一部分不一样，本文将对其做一个简单的罗列。
1）ro.dalvik.vm.native.bridge系统属性
这是一个在default.prop文件中定义的系统配置项，如果没有设置这个配置项，或者这个配置项被设置成了0，则Android系统将禁用NativeBridge，也就是禁用了Houdini。但是，如果将其设置成一个可以找到的动态库的名字，且这个动态库满足NativeBridge的规范，则Android系统将会使用这个动态库，初始化NativeBridge。这个完全是Android自己的行为，所有代码已经在AOSP中了。
对于Android-X86来说，这个配置项被设置成了libnb.so。
2）persist.sys.nativebridge系统属性
在Android-X86的“Settings->Apps compatibility”中，打开“Enable native bridge”选项，其实就会将系统属性persist.sys.nativebridge设置为1。
为什么要这样呢？我们可以简单看一下libnb.so里面的行为：
通过反汇编的代码，可以大致看出来，libnb.so中会读取persist.sys.nativebridge这个系统属性。如果为0的话，则输出内容是“Native bridge is disabled”的日志，然后直接退出；而如果是1的话，才会继续跳转到正常的路径去执行。而且，可以看出这是Houdini自己的行为，和AOSP无关。
3）ro.product.cpu.abilist系统属性（包括ro.product.cpu.abilist32系统属性）
这两个配置项定义在Android-X86系统中的build.prop配置文件中，它们都被设置成了下面的值：
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi这个属性到底有什么用呢？其实它就对应的是Framework层的android.os.Build类内部的SUPPORTED_ABIS和SUPPORTED_32_BIT_ABIS（可以猜到属性ro.product.cpu.abilist64对应的是Build内的SUPPORTED_64_BIT_ABIS，但是Android-X86目前只是32位的，所以不需要改这项）。
也就是说这个属性值是一组列表，表示了当前系统支持哪些平台。而且，属性值的顺序也是有讲究的，第一个一定是x86，因为这个列表的第一个值表示本系统最兼容的那个平台，如果满足那第二个也可以，如果还是不行，第三个也凑合，如果全都不满足，则会报错。
系统中有许多地方用到了这个属性。最简单的，对于应用程序安装来说，如果其只包含了一个ARM指令集的JNI动态库，那么如果安装在一个只支持X86指令集的平台上是没有任何意义的，因为肯定运行不起来，这时候PackageManagerService会阻止你安装这个应用。但如果安装了Houdini，情况就不同了，可以通过动态转指令集的方法运行，这时就要通过修改这个属性值来告诉系统，我其实还是可以支持ARM的。
4）ro.dalvik.vm.isa.arm系统属性
这个配置项定义在Android-X86系统中的build.prop配置文件中，它被设置成了下面的值：
ro.dalvik.vm.isa.arm=x86这个系统配置项只在PackageManagerService中（代码位于frameworks\base\services\core\java\com\android\server\pm\PackageManagerService.java文件中）：
private static String getDexCodeInstructionSet(String sharedLibraryIsa) {
String dexCodeIsa = SystemProperties.get("ro.dalvik.vm.isa." + sharedLibraryIsa);
return (dexCodeIsa.isEmpty() ? sharedLibraryIsa : dexCodeIsa);
}
private static String[] getDexCodeInstructionSets(String[] instructionSets) {
ArraySet dexCodeInstructionSets = new ArraySet(instructionSets.length);
for (String instructionSet : instructionSets) {
dexCodeInstructionSets.add(getDexCodeInstructionSet(instructionSet));
}
return dexCodeInstructionSets.toArray(new String[dexCodeInstructionSets.size()]);
}
public static String[] getAllDexCodeInstructionSets() {
String[] supportedInstructionSets = new String[Build.SUPPORTED_ABIS.length];
for (int i = 0; i < supportedInstructionSets.length; i++) {
String abi = Build.SUPPORTED_ABIS[i];
supportedInstructionSets[i] = VMRuntime.getInstructionSet(abi);
}
return getDexCodeInstructionSets(supportedInstructionSets);
}
这其实也是对支持指令集的一个修正。对于Android 5.0以上的系统来说，在安装的时候需要通过dex2oat试图将apk文件中的dex文件编译成包含本地指令集执行代码的oat文件，从而可以加快程序的执行。由于要编译成本地指令集，那当然是平台和程序本身支持几个就要编译几个。对于普通情况来说是没有问题的，但是对于像Houdini这种情况就不同了。Houdini只是用来对X86指令集的JNI动态库转成ARM指令集的，而dex还是应该用X86指令集来编译。因此，通过阅读getDexCodeInstructionCode的代码可以知道，对于arm指令集来说，参数传入的是“arm”字符串，因此要读取系统属性ro.dalvik.vm.isa.arm的值，而它被设置成了x86，因此这个函数会返回X86。所以这个选项的目的是告诉PackageManagerService，如果碰到ARM指令集，就将其修正成X86指令集，即：
ro.dalvik.vm.isa.= 这样的话，对于支持ARM指令集的平台来说，任然会用X86指令集编译dex文件，但会用Houdini执行ARM指令集的JNI动态库。
5）NativeBridge
这部分基本算是对原有AOSP代码最大的改动了，Houdini实现的NativeBridge的版本号升级成了2，且提供出来的函数多了两个。由于AOSP原生加入了NativeBridge的中间层，很好的把这部分逻辑抽象了出来，所以基本只需要更改NativeBridge部分的代码就好了，对ART虚拟机本身做的更改非常小。这个可以通过NativeBridgeCallbacks的定义看出来（代码位于system\core\include\nativebridge\native_bridge.h文件中）：
struct NativeBridgeCallbacks {
// Version number of the interface.
uint32_t version;
bool (*initialize)(const NativeBridgeRuntimeCallbacks* runtime_cbs, const char* private_dir,
const char* instruction_set);
void* (*loadLibrary)(const char* libpath, int flag);
void* (*getTrampoline)(void* handle, const char* name, const char* shorty, uint32_t len);
bool (*isSupported)(const char* libpath);
const struct NativeBridgeRuntimeValues* (*getAppEnv)(const char* instruction_set);
bool (*isCompatibleWith)(uint32_t bridge_version);
NativeBridgeSignalHandlerFn (*getSignalHandler)(int signal);
};可以看出，libnb.so提供的回调函数变成了7个，而不是在AOSP中定义的5个，多出了两个。
再来看看libnb.so反编译后的结果：
可以看出，其版本变成了2。多出来的两个函数，一个叫做isCompatibleWith，一个叫做getSignalHandler。
我们先来看看isCompatibleWith有什么用：
static constexpr uint32_t kLibNativeBridgeVersion = 2;
......
static bool VersionCheck(const NativeBridgeCallbacks* cb) {
if (cb == nullptr || cb->version == 0) {
return false;
}
if (cb->version >= 2) {
if (!callbacks->isCompatibleWith(kLibNativeBridgeVersion)) {
return false;
}
}
return true;
}很简单，其实就是判断兼容性的一个函数，kLibNativeBridgeVersion表示的是Anroid系统NativeBridge的版本号，而cb->version表示的是提供转码功能的那个Houdini动态库的版本号。它们各自有各自的版本，因此需要isCompatibleWith函数来判断一下是否兼容。
对于getSignalHandler函数来说，用在这里（代码位于system\core\libnativebridge\native_bridge.cc文件中）：
NativeBridgeSignalHandlerFn NativeBridgeGetSignalHandler(int signal) {
if (NativeBridgeInitialized() && callbacks->version >= 2) {
return callbacks->getSignalHandler(signal);
}
return nullptr;
}只对版本号大于2才有效，试图从libnb.so中获得一个信号处理函数。调用这个函数的地方在这里（代码位于art\runtime\native_bridge_art_interface.cc文件中）：
void InitializeNativeBridge(JNIEnv* env, const char* instruction_set) {
if (android::InitializeNativeBridge(env, instruction_set)) {
if (android::NativeBridgeGetVersion() >= 2U) {
#ifdef _NSIG
for (int signal = 0; signal < _NSIG; ++signal) {
android::NativeBridgeSignalHandlerFn fn = android::NativeBridgeGetSignalHandler(signal);
if (fn != nullptr) {
SetSpecialSignalHandlerFn(signal, fn);
}
}
#endif
}
}
}在初始化NativeBridge之后会调用这个函数，它会从0开始到_NSIG（65），一个个从libnb.so中获得对应该信号的处理函数，并将其设置到进程中去。