以上提到的CPU_ABI的可能取值如下,它的值取决于你编译的目标平台。
比如在Android Studio中,so文件放在了libs目录下。则需要在build.gradle中添加设置,来指轮旅渣定实际存放目录。
我们在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是什么类型,会加载什么路径,以免我们的底层老司机在帮忙测试问题的时候造成不必要的麻烦。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)