Issue
For compiling native prebuilt libraries we use NDK toolchain with these two options -DANDROID_ABI
and -DANDROID_PLATFORM
, so in case if we support android-28
, android-29
platforms and armeabi-v7a
, arm64-v8a
, x86
, x86_6
ABIs we will have to sets of produced libraries:
.
├── android-28
│ ├── arm64-v8a
│ │ └── libMy.so
│ ├── armeabi-v7a
│ │ └── libMy.so
│ ├── x86
│ │ └── libMy.so
│ └── x86_64
│ └── libMy.so
└── android-29
├── arm64-v8a
│ └── libMy.so
├── armeabi-v7a
│ └── libMy.so
├── x86
│ └── libMy.so
└── x86_64
└── libMy.so
We can easily use such obtained prebuilts in Android cmake, because it supports${ANDROID_PLATFORM}
and ${ANDROID_ABI}
variables, e.g. CMakeLists.txt
:
...
list(APPEND CMAKE_FIND_ROOT_PATH ${THIRDPARTY_PREBUILT_DIR}/${ANDROID_PLATFORM}/${ANDROID_ABI}/mylib)
...
But packaging these prebuilts into APK seems not clear for me because app/src/main/jniLibs
doesn't support platform hierarchy but only ABI:
.
└── jniLibs
├── arm64-v8a
│ └── libMy.so
├── armeabi-v7a
│ └── libMy.so
├── x86
│ └── libMy.so
└── x86_64
└── libMy.so
And also the same structure in output app-debug.apk/lib
.
So the question: Why do we have in toolchain and Android cmake options to differ platforms but packaging of native libraries (jni libraries) ignores them?
I use Android Studio 3.6.3
with Gradle 5.6.4
.
Solution
You can choose the platform as part of the build because that determines what devices your code will be compatible with. If you target 21, your code isn't guaranteed to run on anything older than Lollipop.
Apps are forward compatible though, so if you build for 21 you will run on Lollipop and everything after (with very rare exceptions, extremely rare as long as you stick to defined behaviors of public APIs). That's why you don't need to package the library for every platform, only the oldest you support.
Answered By - Dan Albert
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.