█ 问题重现:
● 启动app,app调用相关so文件,出现奔溃:
● 界面:
● 后台奔溃报告:
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[dex file "couldn't find "libSDL.so"
● 出现的问题:在部分机型上(如三星Glax S8),app直接停止运行。
█ 问题原因:
● 找不到so文件,当然很明显,在我的工程里面是有这个文件:
█ 解决方法:
● libs文件夹中除armeabi外的所有文件夹删除掉
○ 一直以来都是这样的
● 找到新的so文件替换,可能有些新的手机有新的cpu结构了,旧的可能不支持,兼容性不好
○ 网上直接下载打包好的现成so文件,试过,不能用
○ 在https://www.libsdl.org/download-2.0.php#source网站上下载,自己重新编译,需要在linux上通过makefile去交叉编译,太麻烦,周期长,说不定就要花费个一两周时间,打包后的so文件,说不定也不能用。
● try catch方法
○ 这个试过不行
● 判断存在该库,才去执行对应功能
○ 导致部分手机,没有该功能
● 将apk文件,后缀名修改为zip,打开观察
○ 那么问题就出在这里了,在对apk进行加固后,导致在apk的lib中生成x86的cpu架构文件夹,在该文件夹中少了对应的so文件
○ 那么为什么部分手机又不会出现该问题呢?如果机型不是x86自然不会出现该问题,如果机型是X86,系统是android5以前系统也不会出现该问题,因为系统对其进行拷贝。
● so文件在APK安装时会自动复制到data/data/包名 路径下。Android 5以前的系统会将armeabi-v7a、armeabi、x86等文件夹下的so文件合并到该路径下,而Android5以后的系统则只会拷贝对应机型的so文件,如果没有该文件,则直接拷贝armeabi中的so文件。
○ 那么解决方法就很简单了,要么,将所有的so文件再拷贝一份到x86文件夹中,这样android5系统就可以找到so文件,但是这样无形中导致apk的大小变大!!
○ 要么,使用其他的加固软件或者不进行加固:
○ 那么是加固软件的问题吗?要不重新加固一次?重新加固一次就正常了,那么问题就是加固工具的问题,导致apk奔溃了
● 旧版本 以前没有出现过该问题,当然也有可能没有遇到相应的安装用户。
█ 最终答案:
● 重新进行加固一次,那么问题就是,以后加固后的软件,需要打开再看下,加固文件会不会加错地方!尤其不要在lib文件中,自动保存在某某cpu机型的文件夹中。
█ 相关资料收集:
1.关于Android的.so文件你所需要知道的
一、Android系统上,每一个CPU架构对应一个ABI:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64。) 二、如果项目中使用到了NDK,它将会生成.so文件。很多情况下,你可能并没有意识到项目中依赖的函数库或者引擎库里面已经嵌入了.so文件,并依赖于不同的ABI 1.Native Libs Monitor这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件,以及.so文件来源于哪些函数库或者框架。 2.当然,我们也可以自己对app反编译来获取这些信息,不过相对麻烦一些。 |
2.android .so文件详解以及兼容性
Android 设备的CPU类型(通常称为”ABIs”) armeabiv-v7a: 第7代及以上的 ARM 处理器。2011年15月以后的生产的大部分Android设备都使用它. arm64-v8a: 第8代、64位ARM处理器,很少设备,三星 Galaxy S6是其中之一。 armeabi: 第5代、第6代的ARM处理器,早期的手机用的比较多。 x86: 平板、模拟器用得比较多。 x86_64: 64位的平板。 |
3.Android 5.0以上手机出现找不到so文件
Android中的so文件都是在Android APP安装的的时候复制到data/data/包名 下边的。Android 5以前的Android系统会先后查看armeabi-v7a和armeabi文件夹下的so文件,取其并集放置到APP目录下,而Android5以后的系统会先检查armeabi-v7a文件夹,如果有so文件,就只会把armeabi-v7a目录下的so文件拷贝懂啊APP目录下,如果armeabi-v7a文件夹下没有so文件,则会拷贝armeabi中的so文件。 |
4. Android打包productFlavors 用法
为了决定最后适配的abi版本,我下载了排行前几名的app,然后打开之后发现,他们基本上只适配了一个armeabi,少数会再加上v7a。我了解到的情况是armeabi性能较差,但是兼容性最好,v7a对于浮点计算的cpu来说性能更好,不兼容不支持浮点运算的cpu。我想到的是目前的手机cpu绝大多数应该是支持浮点运算的,而且安卓从2.2开始就支持v7a,所以v7a的兼容性应该也不是问题。 无论如何,abiFilters还是应该添加的。(指定要ndk需要兼容的架构(这样其他依赖包里mips,x86,armeabi,arm-v8之类的so会被过滤掉)) Android gradle的功能非常强大,用这篇文章简单介绍一下gradle中productFlavors的用法。productFlavors顾名而思义,就是用于定义产品的特性,这是每个产品不同的地方。 |
转载请注明出处:
http://blog.csdn.net/ljb568838953/article/details/78064304