首页 > 代码库 > AAR 生成方法

AAR 生成方法

使用第三方库出现找不到so库UnsatisfiedLinkError错误的原因以及解决方案
字数1563 阅读913 评论2 喜欢2

在开发项目的时候我们免不了使用一些第三方的库来进行快速开发,有些第三方库只是简单的一个jar包,但是有些使用了jni开发,因此会包含so库文件,这个时候如果不消息我们就会遇到一个错误:java.lang.UnsatisfiedLinkError;

最近经常遇到有开发者在问使用环信sdk的时候出现这个错误;这里分享下问题原因以及解决方案;
首先这边引用环信工程师总结的出现这个问题的一些原因(稍作排版修改):
导致产生UnsatisfiedLinkError的几个原因

原文地址:UnsatisfiedLinkError错误分析
相关信息

hyphenatechatsdk提供的指令集类型仅提供armeabi、arm64-v8a、x86三种;

这里需要解释一下相关信息:
armeabi和armeabi-v7a是相近似的指令集,v7a是增强型指令集,运行速度,效率均有所提高,他们都是32位指令,并且兼容;arm64-v8a对应arm64位指令集;
arm64位策略和intel IA32不一样:intel64位指令是兼容intel32位指令,intel32位指令编译的程序可以直接在intel64位机器上运行;但是arm不是,arm64位和arm32位是彼此独立的指令系统,不兼容;arm这样设计的原因是因为运行在嵌入式上,设计指标更趋向于效率,和耗电考量;实际上arm64位芯片上同时包含着arm64指令处理器和arm32位指令处理器,只不过两个处理器彼此独立;

影响链接的限制条件
armeabi的so实际上可以运行在arm64位机器上,只不过Google增加了限制条件:

    Android4.x只要能找到so,就可以运行,so可以在armeabi、armeabi-v7a、arm64-v8a,so位置可以很随意;

    Android5.x开始,检查更加严格,会只有和芯片型号对应目录的so会安装到手机中;

        举个例子:
        开发环境下目录结构如下
        libs/armeabi:libhyphenate.so libhyphenate_av.so
        libs/armeabi-v7a:libmediadata.so
        手机对应的指令集是armeabi-v7a,然后安装到手机的只有libmediadata.so;

    Android6.x下,检查更加严格,有一条规则,之前测试有遇到,现在不太确认;
    libs/armeabi/: libhyphenate.so libhyphenate_av.so
    libs/arm64-v8a(没有此目录)
    在arm64位机器上也可以运行,但是作为开发者通常会依赖其他开发包,比如baiduMap,也会用其他so,不能让所有开发者都删掉libs/arm64-v8a的目录;不过开发者可以尝试下删除arm64-v8a,只留armeabi,这样安装包会很小,在各个平台上也能运行;
    Google考量点是执行速率,更流畅的用户体验,作为开发者,服务提供者,我们希望apk尽可能小,对执行速度要求不高;

    armeabi和armeabi-v7a可以互换,现在市面上的手机很少有armeabi的,基本上是armeabi-v7a或arm64位的高端机器。

    查看手机芯片型号:cat /proc/cpuinfo, 仔细看一下打印信息,能够看明白手机指令集,是32位还是64位。

    x86目录,通常对应虚拟机,很多开发者喜欢在genymotion上开发调试,这个就对应86,x86和前面说的intel IA32是一回事,所以只提供32位的,也能在x86-64位机器上运行;

    我们的so还依赖于libsqlite.so,不过由于这个包从来没有变化,使用的是系统默认提供的/system/lib,在Android 6.x及以下的平台可以运行,Android7.x执行更严格的安全检查,禁止使用系统目录的内容,所以如果希望在Android7.x以上版本,需要把系统目录的libsqlite.so拷贝出来,也放在自己app对应指令目录下,由于目前Android7.x市面上没有机型,所以目前不在考虑范围;

    mips指令集的手机很少见,听说联想有出过,没见过;

    libs/armeabi/libhyphenate.so和libs.without.audio/armeabi/libhyphenate.so是不同,libs/armeabi/libhyphenate.so会依赖于libs/armeabi/libhyphenate_av.so,如果找不到会报java.lang.UnsatisfiedLinkError;

    还有一个比较容易忽略的一点,现在我们的的项目一般都是引入好多个第三方库,第六点也提到了使用baiduMap这点,就是当一个项目引入多个库,不同的库有不同的so文件夹,当其中一个支持的比较少,但是另一个比较全时,也会出现这样的错误,解决方法就是不支持的so文件夹删除

        举例:
        环信支持的指令集arm64-v8a、armeabi、x86
        百度地图支持的指令集arm64-v8a、armeabi、armeabi-v7a、x86、x86_64、mips、mips64
        如果想在所有设备上都能运行,需要把armeabi-v7a、x86_64、mips、mips64这些删除;
        根据前边所说可以保留armeabi-v7a文件夹,然后复制armeabi里的so文件到armeabi-v7a就行了

所以如果大家再遇到这样的问题,可以先根据以上信息排查下,如有问题欢迎指正


 

那么问题来了,到底是什么原因呢?

通过分析crash日志,我发现一个问题:

    nativeLibraryDirectories=[/data/app/xxx-1/lib/arm64, /data/app/xxx-1/base.apk!/lib/arm64-v8a, /vendor/lib64, /system/lib64]

我外部的lib里并没有那么多文件夹啊!!!!

这个就是crash的原因所在了。

当AAR内部的so文件类型比外部多时,会导致外部的so文件找不到。

所以果断的剔除了AAR中不需要的so文件夹“arm64”,“arm64-v8a”,“x86”。

再次编译,OK,齐活了。88,希望能帮助到你们。

文/13itch(简书作者)
原文链接:http://www.jianshu.com/p/7e37b76ae39a
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

dependencies {  

    compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])  

    testCompile ‘junit:junit:4.12‘  

    compile ‘com.android.support:appcompat-v7:23.4.0‘  

    compile(name: ‘mylib‘, ext: ‘aar‘)  

} 

注意:在defaultConfig中不要定义applicationId,因为aar是库,无applicationId


2.如何在工程中导入aar?
(1)将编译好的aar文件放到libs下,类似jar的做法。譬如,libs/mylib.aar。
(2)在工程的build.gradle中添加:






在CODE上查看代码片派生到我的代码片




    repositories{  

        flatDir {  

            dirs ‘libs‘  

        }  

    }  

 


 

AAR 生成方法