8

I used to build arm64-v8a lib of api level 19 use android.toolchain.cmake comes with Android NDK r16b like this.

${CMAKE} \
        -DCMAKE_TOOLCHAIN_FILE=${TOOLCHAIN_FILE}                    \
        -DANDROID_NDK=$ANDROID_NDK_HOME                             \
        -DANDROID_ABI="arm64-v8a"                                   \
        -DANDROID_NATIVE_API_LEVEL="android-19"                     \
        -DANDROID_STL="c++_shared"                                  \
        -DANDROID_CPP_FEATURES="rtti exceptions"                    \
        ..

Now i want to pack my lib use conan which cross compile android lib use standalone toolchain. Its seems to be impossible to make standalone toolchain with --arch arm64 and --api 19, since the following command

./make_standalone_toolchain.py --arch=arm64 --api=19 --stl=libc++ --install-dir=./test

will fail with error message:

19 is less than minimum platform for arm64 (21)

is there any way to fix this?

guorongfei
  • 309
  • 2
  • 10
  • What is wrong with api 21? Have you got an arm64 device with KitKat? – Alex Cohn Apr 08 '18 at 03:45
  • Thank you for help. No, i do not got arm64 device with KitKat. I have to support both armv7a KitKat device and arm64 LOLLIPOP device, and i want to set the `minSdkVersion` to 19. – guorongfei Apr 08 '18 at 04:55
  • So you need two standalone toolchains. It should be fine to set the armv7a one with api=19 and the arm64 one with api=21. – Alex Cohn Apr 08 '18 at 06:46

1 Answers1

9

Because there's no such thing as API 19 ARM64. 64-bit support was added in android-21.

CMake supports this because our toolchain file was modeled off of a popular option that was commonly used at the time and that's what it did. ndk-build does it because you build multiple ABIs in a single invocation. In both cases, the build automatically pulls the API level up to 21 for 64-bit targets.

Standalone toolchains are for exactly one architecture, so they give an error if you specify an API level that is not supported by that architecture since it was likely a mistake.

Dan Albert
  • 10,079
  • 2
  • 36
  • 79