大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
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 的这个组件,剩下的事情就是需要把补全或者升级就好了