文章目錄

• 一、問題描述
• 二、問題排查
• 三、解決方案

一、問題描述

---

NDK 開發 , 在調用 JNI 對應 Java 類時 , 靜態代碼塊中 System.loadLibrary 語句調用時 , 報如下錯誤 ;

static {System.loadLibrary("openssl");} 2020-12-01 10:35:48.993 20837-20837/? E/AndroidRuntime: FATAL EXCEPTION: mainProcess: kim.hsl.dex, PID: 20837java.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 架構的動態庫 ;

在主應用中 , 選擇了 C++ 支持 , 系統自動生成的配置如下 :

plugins {id 'com.android.application'id 'kotlin-android' }android {compileSdkVersion 29buildToolsVersion "30.0.2"defaultConfig {applicationId "kim.hsl.myapplication"minSdkVersion 18targetSdkVersion 29versionCode 1versionName "1.0"testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"externalNativeBuild {cmake {cppFlags ""}}}buildTypes {release {minifyEnabled falseproguardFiles 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_8targetCompatibility 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' }

上述 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 動態庫 :

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

一般的高端機型都是 arm64-v8a 架構的 , 幾年前的機型可能是 armeabi-v7a 架構的 ;

arm64-v8a 架構的手機 可以兼容使用 armeabi-v7a 架構的動態庫 ;

不過要注意一點 , 前提是沒有配置 arm64-v8a 架構 , 如果配置了 arm64-v8a 架構 , 但是沒有對應 so 庫 , 那就會出現上述錯誤 ;

三、解決方案

---

解決方案 : 全部配置 armeabi-v7a 架構 , 這樣在所有的手機中只存在 armeabi-v7a 架構 的動態庫 , 系統查找時 , 就不會查找

android / defaultConfig / externalNativeBuild / cmake / abiFilters 配置 abiFilters 'armeabi-v7a' 即可 ;

plugins {id 'com.android.application'id 'kotlin-android' }android {compileSdkVersion 29buildToolsVersion "30.0.2"defaultConfig {applicationId "kim.hsl.myapplication"minSdkVersion 18targetSdkVersion 29versionCode 1versionName "1.0"testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"externalNativeBuild {cmake {cppFlags ""abiFilters 'armeabi-v7a'}}}buildTypes {release {minifyEnabled falseproguardFiles 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_8targetCompatibility 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' }

主應用中生成的 動態庫 , 只剩成了 armeabi-v7a 架構的動態庫 ;

依賴庫中還是生成的 armeabi-v7a 架構的動態庫 ;

問題解決 ;

如果非要配置 arm64-v8a 架構 , 但是一旦配置上 , 所有的在 NDK 中使用到的依賴庫 如 OpenSSL , FFMPEG , RTMP , FAAC , OpenCV 等 , 都必須一式兩份 , 一份 armeabi-v7a 架構的靜態/動態 依賴庫 , 一份 arm64-v8a 架構的 靜態 / 動態 依賴庫 ; ( 很麻煩 , APK 編譯后也很大 , 不推薦 )

總結

以上是生活随笔為你收集整理的【错误记录】NDK 报错 java.lang.UnsatisfiedLinkError 的一种处理方案 ( 主应用与依赖库 Module 的 CPU 架构配置不匹配导致 )的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。