我们在编写JNI代码时有一个可选的文件Application.mk ，这个文件你可以不创建，但是有时候是有必要写一个这样的文件的。
Application.mk文件用于描述应用程序本身的一些属性信息，如应用程序依赖哪些库，应用程序的根目录，应用程序运行在哪些类型指令集的CPU下，还有一些编译选项，
在此文件中定义的东西会应用于整个应用程序包括android.mk也会用到这里面的选项。
如果你不写此文件，会默认编出所有android.mk中写的libs / modules APP_ABI会默认指定为armeabi
下面我们主要介绍APP_ABI的用途。
首先市面上的android智能设备很多也很杂，各种类型各个厂家的芯片，但都是基于某种指令集来开发出来的，这里的ABI（Application Binary Interface）实际就是指应用程序基于哪种指令集来进行编译，官方文档说其实是以下几点不同：
- the CPU instruction set that the machine code should use
- the endianness of memory stores and loads at runtime
- the format of executable binaries (shared libraries, programs, etc...)
and what type of content is allowed/supported in them.
- various conventions used to pass data between your code and
the system (e.g. how registers and/or the stack are used when functions
are called, alignment constraints, etc...)
- alignment and size constraints for enum types, structure fields and
arrays.
- the list of function symbols available to your machine code at runtime,
generally from a very specific selected set of libraries.
我们能用到的ABI 也就四种 armeabi armeabi-v7a x86 和mips 前两者最常用到。
在编译的时候你可以指定其中的一种或者几种，如果指定了几种，这时候打包到APK后这个APK被称为“胖二进制”，也就是它包含了几种ABI类型的lib
当APK被安装到设备上的时候，android系统有这样一个机制：
系统支持哪些ABI类型它自己是知道的，它们会将最适合机器性能发挥的ABI类型标记位'primary' 把剩下的也支持的标记为‘secondary’
例如
CPU 工艺为 ARMv5TE-based 的CPU只有'primary' 为armeabi 没有'secondary'
而类型为ARMv7-based的CPU 'primary' 为armeabi-v7a 'secondary'为armeabi
应用程序安装的时候系统首先检查lib/<primary-abi>/libxx.so 如果有的话就将此处的lib随应用程序copy到/data/app/下面这个大家应该知道第三方应用的安装目录
如果没有的话，而机器有secondary ，就检查lib/<secondary-abi>/libxx.so
所以这就是为什么我们不用写application.mk 而应用程序能在amrv7 的机器上面跑得好好的，但是这有可能没有发挥到amrv7的最有效的性能。
所以如果是我写应用程序我会指定两个或更多(当然这可能造成APK体积增大，这个要自己取舍)
另外推荐一个工具查看android系统的硬件信息 z-devicetest ,可以看到CPU型号等具体信息。