189 8069 5689
android ndk调用第三方的so库文件的步骤如下：
永顺网站制作公司哪家好，找创新互联建站！从网页设计、网站建设、微信开发、APP开发、响应式网站建设等网站项目制作，到程序开发，运营维护。创新互联建站于2013年成立到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联建站。
1.将SO文件直接放到libs/armeabi下，然后代码中System.loadLibrary("xxx")；再public native static int xxx_xxx_xxx()；接下来就可以直接调用xxx_xxx_xxx()方法；
2.第二种方案，创建自己的SO文件，在自己的SO文件里调用第三方SO，再在程序中调用自己的SO，这种比较复杂，需要建java类文件，生成.h文件，编写C源文件include之前生成的.h文件并实现相应方法，最后用android NDK开发包中的ndk-build脚本生成对应的.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)。
Android下查看SO库具体还依赖了哪些so库
ndk中的readelf
在ndk的toolchains 中可以找到对应的可执行程序
路径例如：
D:\AndroidSDK\ndk\17.2.4988734\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin 下 arm-linux-androideabi-readelf.exe
一般文件位置在system文件夹下，通过adb或者Android studio的Device File Explore 中可以查看到有lib跟lib64下大量的.so文件，如libmedia.so, libandroid.so, libc.so等
具体报错的信息如下：
大概的意思就是应用nativeloader打不开libhaha_utils.so这个so库了，就崩溃了！！好残忍。libhaha_utils.so这个库是用我用Android.mk编译后放在system/lib64下面的。但现在打不开了。
为啥呢？
因为/system/lib64/不在APK查找so库的合法路径啊，合法路径有啥呢？
上面log就有说明啦。下面三个路径都没有找到libhaha_utils.so库，所以就挂了。
ld_library_paths="",
default_library_paths="/system/fake-libs64:/data/app/com.example.haha-1/base.apk!/lib/arm64-v8a", permitted_paths="/data:/mnt/expand:/data/data/com.example.haha
这个apk可是系统权限的哟，就是apk的清单AndroidManifest中有下面一句
android:sharedUserId="android.uid.system"
正常来说，这种高端apk的permitted_paths是包含system/lib64的，从源码可以知道
/ frameworks / base / core / java / android / app / LoadedApk.java
看上面的注释就知道啦，如果是系统apk并且没有升级过的话，so库的搜索路径就会增加一个system/lib64。我去，google搞啥呢，为什么还要限定不能升级。
因为install -r来安装apk就相当于升级，所以刷机时apk可以用，install升级后不能用。
我纯粹是为了调试方便，所以参考google的链接
在这个源码里面用到这个txt文件
/ system / core / libnativeloader / native_loader.cpp
在LibraryNamespaces类的Initialize()会读取这个文件，将so库设置为公共so库，所谓公共so库，就是这个so库谁都能用啦。
这个方法时什么时候调用的呢？大概过下流程罗。
首先在创建一个虚拟机的时候，初始化NativeLoader，这个NativeLoader，顾名思义，就是用来装载so库的。
/ art / runtime / java_vm_ext.cc
然后进入native_loader，进行初始化
/ system / core / libnativeloader / native_loader.cpp
初始化是调用LibraryNamespaces类的Initialize完成公共so库的赋值，哈哈哈，搞定！！
总结：
1.Android N 不能直接调用系统的一些私有库了，公用的库都定义在public.libraries.txt里面。
2.系统应用刚刷机是能够调用system/lib64下的库，但通过install升级该应用时，应用打开会挂。因为升级后permitted_paths就不再包含system/lib64了。所以我们可以将apk要用到的库名称写到public.libraries.txt中去解决快速调试问题。
如下：
出问题的地方不在于通过结构体的指针访问位域，而是试图取位域的引用，这是做不到的。位域用unsignedint和unsignedchar的差别在于用unsignedint可以声明位宽大于unsignedchar的位域。例如在unsignedchar位宽为8，unsignedint位宽为32的时候，试图声明unsignedcharx:12会报错，而unsignedintx:12就没问题（当然，这个大小超过unsignedint的位宽时也会报错）。
最近App在弄Arm64的升级,但是有几个so文件找不到是哪几个组件使用的,也从网上找到了一些文章,试了一下貌似也不可以,
就自己想了一些其他办法,App想要编译成功,如果组件是以上传到仓库的方式引用的话,我们想要查找这个so文件就比较麻烦,
整个工程是搜索不到的,但是想要编译成功还必须将这些组件拉倒本地缓存中,也就是说能运行的程序所有关于他的文件是都有的,
我们只需要找到他就好了
这里我借助了SearchEverything 这个软件,搜索了一下丢失64位的so库
很清楚的看到使用的组件叫 jefified-360Camera-1.0.1 的这个组件,剩下的事情就是需要把补全或者升级就好了