Flutter插件引入第三方jar包之armeabi，flutter技术解析与实战
作者：互联网
首先还是在plugin/android的目录新建一个libs文件夹，然后将jar文件放进去就好
然后在依赖里一个一个导入就好。
dependencies {
implementation files(‘libs/hyfisheyepano.jar’)
implementation files(‘libs/mid-core-sdk-4.0.7.jar’)
implementation files(‘libs/org.apache.http.legacy.jar’)
implementation files(‘libs/wup-1.0.0.E-SNAPSHOT.jar’)
implementation files(‘libs/Xg_sdk_4.0.3_20180720_1441.jar’)
implementation files(‘libs/nv_sdk_v1.0.0.jar’)
}
导入so文件
so文件包在编辑器中只需要放入指定位置，就可以被找到，在Android studio中需要放在src/main/jniLibs中，所以直接将文件包一下子复制进去。
如果有多种架构的so文件，同样也是把包整体复制进来。
运行一下
这个时候，程序是可以正常跑起来了，不涉及到插件功能的时候运行正常，一旦需要调用一下插件的方法的时候，程序会直接奔溃退出，查看控制台，提示出Can't link the lib。
这里的提示语句是sdk里使用try catch返回出来的，本意就是coundn't find "xxx.so"，无法在程序里面找到所需要的文件，按照方法导入了，怎么又无法链接到，接着往下看。
二、加载so文件
上面我们运行了一下，发现是jar包里的方法需求调用so文件，但是怎么都调用不到，这又是什么问题？
验证安装包
首先想到的是验证一下文件是否引入成功，如果文件引入成功，可以直接查看apk里查看到引入的文件。所以首先找到安装包的位置
当flutter运行于debug模式的时候，程序会先生成一个app-debug.apk的文件，储存在项目目录中build/app/outputs/flutter-apk的这个位置，当然这里同时也保存了release版的安装包。
在Android studio的菜单栏中，找到build -> Analyze Apk这个功能，打开我们的app-debug.apk。
可以发现里面包含了多种架构的jniLibs，而我们的手机是arm64-v8a，程序非常符合逻辑的就去对应的架构中去寻找需要文件，而我们的文件只有armeabi的版本，找不到文件，插件方法无法调用，程序就报错崩溃
根据开头提到的：armeabi-v7a和arm64-v8a这两种架构是可以向下兼容的，聪明的你肯定想到可以把其他架构的文件包删掉就好，只有保留有内容的。
解决方法
解决方法就一句话，在build.gradle文件中加上以下这句话：
android{
defaultConfig{
ndk {
abiFilters ‘armeabi’
}
}
}
在这里是通过 abiFilters 来指定我们需要的 ABI，也就是指定需要的CPU架构，加上上面语句后，在通过Analyze Apk的功能，可以看到：
安装包里只剩armeabi了，这样的话，基本的3中架构调用文件的时候，都会调用到这个包里的文件，程序就不会崩溃了。
这里不得不插一句，因为我在开发插件，在得知这个解决方法的时候，我将这个语句放入了
android/build.gradle，没有任何效果，而是应该写在example/android/build.gradle的这个文件里，这里才是安装包生成时候所依赖的参数和配置。这个小问题卡了近我3个小时。
三、还是跑不起来？
在指定了ABI之后，程序不会崩溃了，因为程序直接跑不起来了。
才是安装包生成时候所依赖的参数和配置。这个小问题卡了近我3个小时。
三、还是跑不起来？
在指定了ABI之后，程序不会崩溃了，因为程序直接跑不起来了。
标签：files,文件,插件,包之,implementation,jar,armeabi,libs,安装包 来源： https://blog.csdn.net/jkjk322/article/details/121904600