【错误记录】NDK 报错 java.lang.UnsatisfiedLinkError 的一种处理方案 ( 主应用与依赖库 Module 的 CPU 架构配置不匹配导致 )(一)

简介: 【错误记录】NDK 报错 java.lang.UnsatisfiedLinkError 的一种处理方案 ( 主应用与依赖库 Module 的 CPU 架构配置不匹配导致 )(一)

文章目录

一、问题描述

二、问题排查

三、解决方案





一、问题描述


NDK 开发 , 在调用 JNI 对应 Java 类时 , 静态代码块中 System.loadLibrary 语句调用时 , 报如下错误 ;


 

static {
        System.loadLibrary("openssl");
    }


2020-12-01 10:35:48.993 20837-20837/? E/AndroidRuntime: FATAL EXCEPTION: main

 

Process: kim.hsl.dex, PID: 20837
    java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/kim.hsl.dex-WPNFatgeDiPkh3jHexDmDg==/base.apk"],nativeLibraryDirectories=[/data/app/kim.hsl.dex-WPNFatgeDiPkh3jHexDmDg==/lib/arm64, /data/app/kim.hsl.dex-WPNFatgeDiPkh3jHexDmDg==/base.apk!/lib/arm64-v8a, /system/lib64, /hw_product/lib64, /system/product/lib64]]] couldn't find "libopenssl.so"
        at java.lang.Runtime.loadLibrary0(Runtime.java:1067)
        at java.lang.Runtime.loadLibrary0(Runtime.java:1007)
        at java.lang.System.loadLibrary(System.java:1668)
        at kim.hsl.multipledex.OpenSSL.<clinit>(OpenSSL.java:13)
        at kim.hsl.multipledex.OpenSSL.getBytes(OpenSSL.java:30)
        at kim.hsl.multipledex.ProxyApplication.attachBaseContext(ProxyApplication.java:124)
        at android.app.Application.attach(Application.java:358)
        at android.app.Instrumentation.newApplication(Instrumentation.java:1168)
        at android.app.LoadedApk.makeApplication(LoadedApk.java:1382)
        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7341)
        at android.app.ActivityThread.access$2400(ActivityThread.java:251)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2280)
        at android.os.Handler.dispatchMessage(Handler.java:110)
        at android.os.Looper.loop(Looper.java:219)
        at android.app.ActivityThread.main(ActivityThread.java:8375)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1055)





二、问题排查


出现上述错误 , 就是 打包的 so 动态库没有找到 , 有很多问题都会导致该错误 , 如 build.gradle 中没有配置对应的 CPU 架构 , NDK 中调用的外部动态或静态依赖库的 CPU 架构不匹配 ;


这里我遇到的问题是 主应用 与 依赖库的 CPU 架构不匹配导致 ;


创建项目时选择如下选项 , 自动生成的 build.gradle 中默认生成 arm64-v8a, armeabi-v7a, x86, x86_64 四种 CPU 架构的动态库 , 这就比较坑 , 一般开发时只编译 armeabi-v7a 这一种 CPU 架构的动态库 ;

image.png



在主应用中 , 选择了 C++ 支持 , 系统自动生成的配置如下 :


plugins {
    id 'com.android.application'
    id 'kotlin-android'
}
android {
    compileSdkVersion 29
    buildToolsVersion "30.0.2"
    defaultConfig {
        applicationId "kim.hsl.myapplication"
        minSdkVersion 18
        targetSdkVersion 29
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        externalNativeBuild {
            cmake {
                cppFlags ""
            }
        }
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    externalNativeBuild {
        cmake {
            path "src/main/cpp/CMakeLists.txt"
            version "3.10.2"
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
}
dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation 'androidx.core:core-ktx:1.3.2'
    implementation 'androidx.appcompat:appcompat:1.2.0'
    implementation 'com.google.android.material:material:1.2.1'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}



56


上述 android / defaultConfig / externalNativeBuild / cmake / abiFilters 配置中没有配置 CPU 架构 , 没有配置 abiFilters CPU 架构选项 , 因此默认生成 arm64-v8a, armeabi-v7a, x86, x86_64 四种 CPU 架构的动态库 ;


下图是主应用生成的 so 动态库 :




可以明显看到 主应用的依赖库生成了 四种 CPU 架构的动态库 , 我们使用的 libopenssl.so 动态库只有 armeabi-v7a 架构的 , 当在 arm64-v8a 架构的手机中调用 OpenSSL 所在的类时 , 在 static 静态代码块中的 System.loadLibrary 调用时就会报错 ;


该应用生成了 arm64-v8a 架构的动态库 , 但是生成的不全 , 导致上述问题 , 解决方案是干脆不生成 arm64-v8a 架构的动态库 , 只生成 armeabi-v7a 架构动态库 , arm64-v8a 架构的手机会向下兼容 armeabi-v7a 架构动态库 , 因此只编译生成 armeabi-v7a 架构动态库即可 ;



在另一个主应用的 Android Library 中 , 其也使用了 NDK , 并且使用了外部依赖库 OpenSSL 静态库 , 在 Ubuntu 中只交叉编译了 armeabi-v7a 架构的静态库 , 因此不能生成 arm64-v8a 的动态库 ;


下图是依赖库生成的 so 动态库 :


image.png


目前的主流手机都是 arm64-v8a 或 armeabi-v7a 手机 , x86 和 x86_64 手机很少 , 一般不进行匹配 ;


一般的高端机型都是 arm64-v8a 架构的 , 几年前的机型可能是 armeabi-v7a 架构的 ;


arm64-v8a 架构的手机 可以兼容使用 armeabi-v7a 架构的动态库 ;


不过要注意一点 , 前提是没有配置 arm64-v8a 架构 , 如果配置了 arm64-v8a 架构 , 但是没有对应 so 库 , 那就会出现上述错误 ;

image.png

目录
打赏
0
0
0
0
39
分享
相关文章
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
47 5
【YashanDB知识库】如何排查YMP报错:”OCI版本为空或OCI的架构和本地系统的架构不符“
【YashanDB知识库】如何排查YMP报错:”OCI版本为空或OCI的架构和本地系统的架构不符“
【YashanDB知识库】如何排查YMP报错:”OCI版本为空或OCI的架构和本地系统的架构不符“
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
Playwright多语言生态:跨Python/Java/.NET的统一采集方案
随着数据采集需求的增加,传统爬虫工具如Selenium、Jsoup等因语言割裂、JS渲染困难及代理兼容性差等问题,难以满足现代网站抓取需求。微软推出的Playwright框架,凭借多语言支持(Python/Java/.NET/Node.js)、统一API接口和优异的JS兼容性,解决了跨语言协作、动态页面解析和身份伪装等痛点。其性能优于Selenium与Puppeteer,在学术数据库(如Scopus)抓取中表现出色。行业应用广泛,涵盖高校科研、大型数据公司及AI初创团队,助力构建高效稳定的爬虫系统。
Playwright多语言生态:跨Python/Java/.NET的统一采集方案
【上云基础系列 02-01】通过SLB+1台ECS+ESS弹性伸缩,搭建一个精简版的上云标准弹性架构(含方案及教程)
通常,构建一个弹性架构(即使是一个最基础的入门版),至少需要2台ECS。但是,很多小微企业刚开始上云的时候,为了节省成本不愿意购买更多的服务器。通过 “ALB+ESS弹性伸缩+1台ECS+RDS”方案,在保障低成本的同时,也不牺牲业务架构的弹性设计,更避免了很多人因为节省成本选择了单体架构后频繁改造架构的困局。 方案中的几个设计非常值得小微企业借鉴:(1)通过ALB/RDS的按量付费,节省了初期流量不大时的费用;(2)通过ESS弹性伸缩,不需要提前购买服务器资源,但是当业务增长或减少时却保持了资源弹性自动扩缩容。
|
2月前
【YashanDB 知识库】如何排查 YMP 报错:”OCI 版本为空或 OCI 的架构和本地系统的架构不符“
在迁移预检查的版本检查阶段报错“OCI 版本为空”,原因是 OCI 架构与本地系统不符或依赖库缺失。排查发现 `libdrv_oracle.so` 缺少 `libnsl.so.1` 库,尽管 OCI 客户端路径已正确加入 `LD_LIBRARY_PATH`。解决方法包括下载安装相应动态库版本,或通过软链接指向更高版本库(如 `libnsl.so.2`)。总结:确保动态库路径正确配置,并使用 `ldd` 查看依赖库,必要时创建软链接以解决问题。
Java线程池的实现架构
线程池是一种用于管理多线程的池化技术,通过复用线程减少创建和销毁线程的开销。Java中的线程池架构包括`Executor`、`ExecutorService`、`ScheduledExecutorService`等接口,以及`ThreadPoolExecutor`和`ScheduledThreadPoolExecutor`两个核心实现类。`Executors`工厂类提供了便捷的线程池创建方法。线程池不仅简化了多线程编程,还能避免线程过多导致的资源消耗和切换开销。本文从使用示例入手,剖析了线程池的实现原理及其内部架构,重点分析调度线程池的实现机制。
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
下一篇
oss创建bucket