Reputation: 303
I have an android project with several dependencies. Two of them (let's call them dependency A and B) have native libraries (.so files).
Dependency A has the following architectures: arm64-v8a, armeabi, armeabi-v7a, x86 and x86_64. Dependency B has the following architectures: armeabi, x86
Thus when my app runs on an armeabi-v7a device (for instance), and dependency B calls a native method, it cannot find the relevant library to get it from (as it is not present in armeabi-v7a folder and does not fall back automatically to armeabi where the library is).
Is there any way to work around this? For instance, can I add some configuration to my build.gradle file in order for arm64-v8a, armeabi-v7a, and x86_64 folders not to be integrated to my final apk?
I have tried packagingOptions / exclude, but with no results : the folders in questions are still there.
Upvotes: 28
Views: 14998
Reputation: 122
The modern way (as of AGP ~8.0.0) to exclude jni libs from the final APK is:
build.gradle.kts
android {
packaging {
jniLibs {
// Exclude all x86 lib variants
excludes += "/lib/x86/*.so"
// Exclude a specific lib of all architectures
excludes += "/lib/**/libYouDontWant.so"
}
}
}
Note that this is only for jni libs! Any other globs for resources should use packaging.resources.excludes
:
android {
packaging {
resources {
excludes += "/**/*.kotlin_builtins" // (example)
}
}
}
Upvotes: 1
Reputation: 546
Try a clean build, I didn't and it was still picking up the files from the previous build. I ended up deleting my app/build/ folder just to be sure.
android {
packagingOptions {
exclude 'lib/armeabi-v7a/libSomeLibYouDontWant.so'
}
}
Worked for me on an app that was previously crashing.
An alternative would be to use
android{
defaultConfig{
ndk{
abiFilters "armeabi", "x86"
}
}
}
There are some similar questions which might be helpful
How to use 32-bit native libraries on 64-bit Android device
Upvotes: 41