为何Android NDK独立工具链不支持API 19的arm64，而CMake工具链却支持？

You mentioned you previously built an arm64-v8a library targeting API 19 using NDK r16b's android.toolchain.cmake with this command:

${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" \ 
  ..

Great question—let's break down why Conan's standalone toolchain refuses this setup, and why your original NDK command seemed to work even though this combination doesn't make sense for real Android devices.

The Root Cause: arm64-v8a Didn't Exist on API 19 #

First and foremost: Android 4.4 (API level 19) never supported the arm64-v8a architecture. The first Android version to run on 64-bit ARM chips was Android 6.0 (API level 21). There were zero official API 19 devices with arm64-v8a hardware—every KitKat device was 32-bit (either armeabi or armeabi-v7a).

Why Your Original NDK r16B Command "Worked" (It Was a Loophole) #

Your initial build using NDK r16b's legacy android.toolchain.cmake might have compiled without errors, but that was due to a leniency in the old NDK toolchain files:

• The legacy toolchain didn't strictly enforce the minimum API level per ABI. It let you set android-19 for arm64-v8a, but under the hood, it was still using headers and libraries from API 21 (the actual minimum required for arm64).
• The resulting binary would never run on an API 19 device (since none existed with arm64 hardware), so this was more of a cosmetic setup than a functional one.

Conan's Standalone Toolchain Enforces Real-World Compatibility #

Conan's approach to generating standalone Android toolchains is designed to follow Google's official NDK rules strictly:

• When you try to create a standalone toolchain for arm64-v8a and API 19, Conan checks the NDK's official compatibility matrix. Since arm64-v8a requires a minimum of API 21, it rejects the request immediately.
• This is intentional—it stops you from building binaries that claim to support an impossible combination, which would just lead to confusing crashes or compatibility issues down the line.

Your Options Moving Forward #

• If you need to support API 19 devices: Switch to a 32-bit ABI like armeabi-v7a (which is fully supported back to API 16).
• If you need arm64-v8a support: Raise your minimum API level to 21. This is the only valid way to build arm64 binaries that will run on real devices.
• If you're set on keeping the API 19 flag for some reason (even though it's meaningless for arm64): You could try overriding Conan's toolchain checks, but this is strongly discouraged. The resulting binary won't work on any API 19 device, and you'll likely run into unexpected build or runtime issues.

内容的提问来源于stack exchange，提问作者guorongfei