此属性对 NDK 构建没有任何影响。NDK 的 API 可用性受 minSdkVersion 约束。这是因为 C++ 符号应在库加载时被即时解析,而不是延迟到首次调用时解析(像在 Java 中一样)。如果在 minSdkVersion 中使用任何不可用的符号,将会导致库在不具备新 API 的操作系统版本上加载失败,无论这些 API 是否被调用都是如此。
虽然应用开发者通常知道其应用的 targetSdkVersion,但对于无法知晓其用户会选择哪个 targetSdkVersion 的库开发者来说,此 API 非常有用。
在运行时,您可以通过调用 android_get_application_target_sdk_version() 来获取应用所使用的 targetSdkVersion。此 API 可在 API 级别 24 及更高级别中找到。此函数包含以下签名:
/** * Returns the `targetSdkVersion` of the caller, or `__ANDROID_API_FUTURE__` if * there is no known target SDK version (for code not running in the context of * an app). * * The returned values correspond to the named constants in `<android/api-level.h>`, * and is equivalent to the AndroidManifest.xml `targetSdkVersion`. * * See also android_get_device_api_level(). * * Available since API level 24. */intandroid_get_application_target_sdk_version()__INTRODUCED_IN(24);
其他行为变更可能取决于设备 API 级别。您可以通过调用 android_get_device_api_level() 来获取运行应用的设备的 API 级别。此函数包含以下签名:
/** * Returns the API level of the device we're actually running on, or -1 on failure. * The returned values correspond to the named constants in `<android/api-level.h>`, * and is equivalent to the Java `Build.VERSION.SDK_INT` API. * * See also android_get_application_target_sdk_version(). */intandroid_get_device_api_level();
获取设备 API 级别可让 NDK 代码动态了解平台中的行为变化。由于次要 API 级别与行为变更无关,并且我们目前没有在次要 API 级别中添加新 NDK 功能的计划,因此无法通过 NDK 调用直接获取完整的设备 API 级别。
您可以利用 dlopen()/dlsym() 或弱 API 引用来调用比 minSdkVersion 指定的更新的 API。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-20。"],[],[],null,["# Android SDK version properties\n\nAndroid applications can set a number of SDK version properties in their\n`build.gradle` file. The [Android `build.gradle`](/studio/build#module-level) documentation explains what\nthose properties mean for the application in general. This document explains how\nthose properties affect NDK builds.\n\ncompileSdkVersion\n-----------------\n\nThis property has no effect on NDK builds. API availability for the NDK is\ninstead governed by `minSdkVersion`. This is because C++ symbols are eagerly\nresolved at library load time rather than lazily resolved when first called (as\nthey are in Java). Using any symbols that are not available in the\n`minSdkVersion` will cause the library to fail to load on OS versions that do\nnot have the newer API, regardless of whether or not those APIs will be called.\n\nFor a new app, choose the newest version available. For an existing app, update\nthis to the latest version when convenient.\n\ntargetSdkVersion\n----------------\n\nSimilar to Java, the `targetSdkVersion` of your app can change the runtime\nbehavior of native code. Behavior changes in the system are, when feasible, only\napplied to apps with a `targetSdkVersion` greater than or equal to the OS\nversion that introduced the change.\n\nFor a new app, choose the newest version available. For an existing app, update\nthis to the latest version when convenient (after updating `compileSdkVersion`).\n\nWhile application developers generally know their app's `targetSdkVersion`, this\nAPI is useful for library developers that cannot know which `targetSdkVersion`\ntheir users will choose.\n\nAt runtime, you can get the `targetSdkVersion` used by an application by calling\n`android_get_application_target_sdk_version()`. This API is available in API\nlevel 24 and later. This function has the following signature: \n\n /**\n * Returns the `targetSdkVersion` of the caller, or `__ANDROID_API_FUTURE__` if\n * there is no known target SDK version (for code not running in the context of\n * an app).\n *\n * The returned values correspond to the named constants in `\u003candroid/api-level.h\u003e`,\n * and is equivalent to the AndroidManifest.xml `targetSdkVersion`.\n *\n * See also android_get_device_api_level().\n *\n * Available since API level 24.\n */\n int android_get_application_target_sdk_version() __INTRODUCED_IN(24);\n\nOther behavior changes might depend on the device API level. You can get the API\nlevel of the device your application is running on by calling\n`android_get_device_api_level()`. This function has the following signature: \n\n /**\n * Returns the API level of the device we're actually running on, or -1 on failure.\n * The returned values correspond to the named constants in `\u003candroid/api-level.h\u003e`,\n * and is equivalent to the Java `Build.VERSION.SDK_INT` API.\n *\n * See also android_get_application_target_sdk_version().\n */\n int android_get_device_api_level();\n\nGetting device API levels allows NDK code to be dynamically aware of behavior\nchanges in the platform. Since minor API levels aren't tied to behavior changes,\nand we have no current plans to add new NDK functionality in minor API levels,\nthere is no way to get the full device API level directly from an NDK call.\n\nYou can make use of either `dlopen()`/`dlsym()` or weak API references to call\nnewer APIs than what your `minSdkVersion` specifies.\n\nmaxSdkVersion\n-------------\n\nThis property has no effect on NDK builds.\n\nminSdkVersion\n-------------\n\nThe `minSdkVersion` set in your `build.gradle` file determines which APIs are\navailable at build time (see [compileSdkVersion](#compilesdkversion) to understand why this differs\nfrom Java builds), and determines the minimum version of the OS that your code\nwill be compatible with.\n\nThe `minSdkVersion` is used by the NDK to determine what features may be used\nwhen compiling your code. For example, this property determines which [FORTIFY](https://android-developers.googleblog.com/2017/04/fortify-in-android.html)\nfeatures are used in libc, and may also enable performance or size improvements\n(such as [GNU hashes](https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#gnu-hashes-availible-in-api-level-23) or [RELR](https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#relative-relocations-relr)) for your binaries that are not compatible with\nolder versions of Android. Even if you do not use any new APIs, this property\nstill governs the minimum supported OS version of your code.\n| **Warning:** Your app *might* work on older devices even if your native libraries are built with a newer `minSdkVersion`. **Do not rely on this behavior.** It is not guaranteed to work, and may not on other NDK versions, OS versions, or individual devices.\n\nFor a new app, see the user distribution data in Android Studio's New Project\nWizard or on [apilevels.com](https://apilevels.com). Choose your balance between\npotential market share and maintenance costs. The lower your `minSdkVersion`,\nthe more time you'll spend working around old bugs and adding fallback behaviors\nfor features that weren't implemented yet.\n\nFor an existing app, raise your `minSdkVersion` whenever old API levels are no\nlonger worth the maintenance costs, or lower it if your users demand it and it's\nworth the new maintenance costs. The Play console has metrics specific to your\napp's user distribution.\n| **Note:** The NDK has its own `minSdkVersion` defined in `\u003cNDK\u003e/meta/platforms.json`. This is the lowest API level supported by the NDK. Do not set your app's `minSdkVersion` lower than this. Play may allow your app to be installed on older devices, but your NDK code may not work.\n\nThe `minSdkVersion` of your application is made available to the preprocessor\nvia the `__ANDROID_MIN_SDK_VERSION__` macro (the legacy `__ANDROID_API__` is\nidentical, but prefer the former because its meaning is clearer). This macro is\ndefined automatically by Clang, so no header needs to be included to use it. For\nNDK builds, this macro is always defined."]]