关于Android L 64位系统兼容32位应用的实现的简单分析。
Android L 的zygote进程的实现不同于之前的版本，除了有zygote进程之外还有zygote64进程。 在init.zygote32_64.rc中有明确指出：
service zygote /system/bin/app_process32 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote
...
service zygote_secondary /system/bin/app_process64 -Xzygote /system/bin --zygote --socket-name=zygote_secondary
...
其中app_process32 和app_process64 就是zygote进程的可执行程序，启动后会改名成zygote。
顾名思义，zygote32即app_process32是一个运行在32位的进程，它所连接的库也都是32位的。而zygote64就是运行在64位的进程，它所连接的库都是64位的。
在不考虑有32/64兼容库的情况下，一个进程如果要正确运行，就必须从可执行程序入口开始到所有使用的库都保持32/64位的一致性。
因为zygote进程是所有第三方应用程序的父进程，所以可以认为，如果应用程序是32位的，那没他的父进程也肯定是32位，换句话说，如果需要启动某个32位的应用，那么肯定是通过32位的zygote进程fork出来的。
这个一点可以在ActivityManagerService上得到验证。
ActivityManagerService中startProcessLocked 方法实现启动应用，主要通过Process中的startViaZygote方法，这个方法最终是向相应的zygote进程发出fork的请求 zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), argsForZygote);
其中openZygoteSocketIfNeeded(abi)会根据abi的类型，选择不同的zygote的socket监听的端口，在之前的init文件中可以看到
zygote32位监听的端口就是–socket-name=zygote
另外一个就是–socket-name=zygote_secondary
因此可以证实，之前的猜测，即32应用进由32位zygote进程fork出来，64位应用进程由64zygote进程fork出来。
那么之前说的abi参数就是决定应用是32还是64位的关键所在，跟踪这个参数，发现这个参数在ApplicationInfo的primaryCpuAbi中决定，
这个值由PackageManagerService在做scanPackageLI的时候决定，具体这个值的得出有一个公式化的过程，主要就是判断这个apk有没有使用native的库，如果使用了，那就看使用了的是32位的还是64位的，另外还要看系统支持的是32位还是64位的。
在64位设备上，如果app的 lib 目录下 存在armeabi，则以32位兼容方式运行。如果存在arm64-v8a 则已64位运行。如果没有任何 so，则 primaryCpuAbi 为空，按照系统的默认配置决定，也就是64位运行。
根据这些因素就可以决定这个apk是应该是32位的还是64位的。
以上就是Android L 64位系统兼容32位应用的基本实现过程。
另外记录一点，在源码环境下如果要PREBUILT第三方的so，如果是32位的需要专门标注 LOCAL_MULTILIB := 32
以此告诉编译系统so位32位，防止编译到64位下去。
更多内容可关注http://blog.csdn.net/dffd001和https://www.jianshu.com/u/2306ba8f1c59后续文章更新。
来源 http://stackoverflow.com/questions/27712921/how-to-use-32bit-native-libraries-on-64-bit-android-l-platform
本文转自 http://blog.csdn.net/louyong0571/article/details/44223481