soandroid应用(soaptoolkit)
Android提取so文件并使用
参考
在
这篇文章中征程的apk：JniTest.apk把后缀改为JnitTest.zip，打开这个文件，在lib下面会有生成好的.so文件，copy出来。
可以发现这个.so文件叫libMyTest.so。
然后把这个so文件copy到新的项目的libs\armeabi下，使用和正常的.so文件一样。然后修改app的gradle中的android节点中加入：
然后在main\java 建立生成.so文件那个项目的包名， 把NdkJniUtils文件copy过来。当然封装成jar包更好啦。
到此完成，调用NdkJniUtils的方法即可获得.so文件中的内容。
Android 应用push ，so无法加载
作者君主要做SDK开发，对接一些厂商或运行商的普通应用或系统应用。
当对接系统应用时，由于系统应用是由于覆盖机型比较广，会碰到Android多个版本机型，有的可能出现so找不到的问题。
普通install安装apk的方式，apk会被安装在 /data/app 目录下，那么So则会被映射到/data/app/项目目录下/lib。
首次安装只能通过直接push到/system/app/下的方式来安装，而不是如普通应用般采取install的方式。
android在开机扫描应用的时候会对 相应目录进行扫描，如果发现 data/app目录下 存在和系统应用同包名的应用，并且版本号比系统应用的版本号更高则构成升级关系，校验签名等安全验证通过。此时data/app下的这个应用就是系统应用
而push到系统目录下如system/app/....，则会优先寻找system/lib（lib64）目录下的so，由于so
不会自动释放到该目录下，所以需要手动push到该路径下。
作者君还遇到过这样的问题，有时候为了减少包的大小或者其他，不会把所有ABI类型的so都放进目录，另外so的提供者团队没有提供64的so（哈哈，如果提供了，下面的问题直接就没有了，那为什么还拿出来说呢，主要是简单地了解一下系统底层的一些基本原理，感兴趣的可以看下一下~~）
机型类型是64位的，其他apk仅提供了64位的so。而某个apk由于只集成了32位so， install安装是正常的，但是把apk通过push到/system/app下，so放到/system/lib下则报如下错误：
32位机器上当然是正常的。
那么为什么会出错呢？首先是系统级应用，需要理解Android系统的原理（当然啦，也许厂商定制了一番，那则另一回事。）：
系统有几个属性，其中app.info.primaryCpuAbi这个值用来决定apk关联ABI类型。而PackageManager会对这个值有所影响。比如：通过apk包里包含的so库的架构来决定app的primaryCpuAbi的值。
另外：
如果机器里有64位的apk，且PackageManager扫描到第一正好是这个apk，PackageManager调整所有apk要加载的都是64位的so。不再去加载32位的so，那么只含32位so的apk就会跑出异常。反之，则64位的apk正常运行，32位的则出错。
作者君能力有限，如有错处，请书友们指导，作者君会第一时间修改。
一起学习 一起进步 ?( ′???` )比心
安卓手机如何打开.so文件？
安卓手机打开.so文件需要下载Native Libs Monitor这个app，这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件，以及.so文件来源于哪些函数库或者框架。我们也可以自己对app反编译来获取这些信息。
so文件是手机的一些运行库文件，在系统lib的文件夹下，置换移植其他系统的程序也需要修改更换相关so文件；没有它系统软件不能运行，哪部分损坏就影响相对功能，电话接打，通讯录，相机等等都是要依赖so文件使用的。so文件需要资深安卓大师更改，一般都是现成的搬运移植，打开它没有什么意义。安卓手机想要查看.so文件就需要下载Native Libs Monitor。
so是shared object的缩写，见名思义就是共享的对象，机器可以直接运行的二进制代码。大到操作系统，小到一个专用软件，都离不开so。so主要存在于Unix和Linux系统中。so是与平台相关的二进制机器码，Android应用支持的cpu架构取决于APK中位于lib或jniLib目录中的.so文件。
由于Android基于Linux Kernl的，也继承了Linux中所有so相关的设计。
除了系统方面的原因，Android开发者还要知道以下几点：
so机制让开发者最大化利用已有的C和C++代码，达到重用的效果，利用软件世界积累了几十年的优秀代码。
so是二进制，没有解释编译的开消，用so实现的功能比纯java实现的功能要快。
so内存分配不受Dalivik/ART的单个应用限制，减少OOM。
android应用.so文件路径
.so文件是自动生成的，必须放在libs/armeabi目录下（不然程序绝对找不到），注意，现在一般都是libs目录了吧。
Android So加载的路径选择
我们在Android应用程序会常常的加载一些So文件来完成我们的目标，那么我们的APK加载So是有哪些平时我们没有注意到的事情呢？
1. 首先我们一般开发会遇见两种APK（其实一般大部分只会遇到一种），一种为系统级APK,另外一种为普通APK。那么这个两种APK跟So加载有什么关系呢？别急，让我们先聊聊我们那些操作会产生这些类型的APK。
普通级AKP:?
pm install +?包名将会把APK安装到 /data/app 目录下，同时会把So映射到/data/app-lib/包命/ 目录下。这个就是普通的APK（pm Install -r 会替换原有的APK，当然必须是一样的签名）。
系统级APK:
push? + 绝对路径 + 包名 /system/app 目录下（必须把原有的包名删除哦！），这时APK就会在System/app下面了，这时你需要把你的APK的So 同时push到system/lib里面。因为apk里面的So并不会自动映射到system/lib下面。
一般我们在使用加载So的方法时候，会使用到System.load（pathName）和?System.loadLibrary(libName)这两种方法。这篇文章主要讲讲System.load（pathName）这个绝对路径加载的注意点。
我们通常会直接使用
context.getApplicationInfo().nativeLibraryDir +/具体名字.so? 来让系统帮我寻找加载So所需要的路径。那么这里问题就来了。
如果是系统级APK
context.getApplicationInfo().nativeLibraryDir = /system/lib/
如果是普通级APK
context.getApplicationInfo().nativeLibraryDir ?=/data/data-lib/PackageName/ 对！就是那个映射的So系统会根据这个去data/app/包名下面寻找真正的So文件。
这个需要注意的细节，主要用于在中间件，系统预置程序的研发人员与测试上面。我们在拿到芯片厂商给予调试模式的开发硬件上进行Demo和So的更换测试的时候，需要自己和测试都需要知道，自己安装的APK是什么类型，会加载什么路径，以免我们的底层老司机在帮忙测试问题的时候造成不必要的麻烦。
android项目中如何加载已有so库？
android项目中如何加载已有so库方法：
1、在项目根目录下建立文件夹libs/armeabi文件夹。
2、将so库放入libs/armeabi文件夹注意事项：
（1）如果采用静态注册的方式请注意C文件中严格按照命名规则Java_packageName_className_method()的方式命名。
（2）在Android项目中建立同上述命名规则中packageName中相同的包名,在此包名下建立同上述命名规则中className相同的类名。
（3）在className声明native方法。
（4）程序中加载so库System.loadLibrary。(data/data/xxx.xxx.xxx/lib/xx.so)或者System.loadLibrary(xx),例如：System.loadLibrary(data/data/com.dtBank.app.service/lib/libjnixcld.so)。