API Level:定义、API版本与targetSdk

作者: IT Sectr 发布日期: 2026-02-08 阅读时间: 12 分钟

Android API Level 是一个整数标识符,唯一对应 Android 平台的特定版本。每个操作系统版本都有唯一的编号:Android 14 = API 34,Android 15 = API 35。开发者在 build.gradle 中管理三个参数 — minSdkVersion、targetSdkVersion 和 compileSdkVersion — 以控制兼容性和对新功能的访问。根据 Android Developers,选择正确的 API Level 对于安全性和受众覆盖率至关重要。

要点

  • API Level — Android API 版本的整数标识符,从 API 1(Android 1.0)到 API 36(Android 16)
  • minSdkVersion — 安装应用的最低 Android 版本,决定受众覆盖率
  • targetSdkVersion — 应用测试所针对的版本;包含该版本的行为变更
  • compileSdkVersion — 编译所用的 SDK 版本;必须 >= targetSdk,提供对新 API 的访问
  • Google Play 要求 targetSdkVersion 不早于当前 API Level 1 年

什么是 Android API Level?

Android API Level 是分配给每个 Android Framework API 公开版本的整数标识符。第一个版本 Android 1.0 的 API Level 为 1,Android 1.5 为 API Level 3,Android 2.2 为 API Level 8,Android 4.0 为 API Level 14,Android 8.0 为 API Level 26,Android 12 为 API Level 31,Android 14 为 API Level 34,Android 15 为 API Level 35,Android 16(2025年)为 API Level 36。每个新的 API Level 可以添加新的类、方法、常量、权限,并更改现有的行为。

API Level 并非随着每个发布版本严格递增 1。例如,Android 4.4W(Wear)具有 API 20,而 Android 5.0 为 API 21。差距与内部迭代和 Wear OS 设备有关。对于开发者来说,重要的不是知道版本名称(KitKat、Lollipop、Tiramisu),而是其 API Level — 这正是代码中用于兼容性检查的内容。

API Level 的主要目的是向后兼容性。针对 API 34 编译的应用可以在 API 34 及更低版本的设备上运行(如果不经检查就使用新 API)。Android Runtime(ART)在系统级别检查 API 调用,并根据应用的 targetSdkVersion 应用行为变更。

Android 如何处理 API Level

安装应用时,PackageManager 会检查设备的 API Level 是否 >= AndroidManifest.xml 中的 minSdkVersion。如果条件不满足 — 安装将被阻止,并显示消息 "App not installed"。在运行期间,Android Runtime 会监控需要更高 API Level 的 API 调用,如果当前版本中不存在该方法,则生成 NoSuchMethodError 或 UnsatisfiedLinkError。

组件在 API Level 处理中的作用
PackageManager安装时检查 minSdkVersion
Android Runtime (ART)运行时执行 API 兼容性检查
Google Play Store根据设备 API Level 过滤应用
SDK Manager下载在所需 API Level 下编译的平台
lint静态分析器,警告使用高于 minSdk 的 API

minSdk、targetSdk、compileSdk:区别与各自参数的作用

build.gradle 文件(Module: app)中,开发者指定三个 API Level 参数:minSdkVersion、targetSdkVersion 和 compileSdkVersion。混淆它们是初级 Android 开发者最常见的错误之一。每个参数负责兼容性的不同方面,它们的值必须保持一致。

minSdkVersion

minSdkVersion 是应用可以安装和运行的最低 API Level。API Level 低于 minSdk 的设备在 Google Play 中看不到应用,也无法安装。该值根据目标受众选择:minSdk 21(Android 5.0)覆盖 97% 的设备,minSdk 26(Android 8.0)约覆盖 85%,minSdk 31(Android 12)约覆盖 55%(数据来自 Android Studio Distribution Dashboard,2026 年)。minSdk 越低,覆盖范围越大,但需要更多的向后兼容代码。

targetSdkVersion

targetSdkVersion 是应用测试所针对的 API Level。Android 使用 targetSdk 来应用行为变更:如果应用指定 targetSdk 33,系统会启用 API 33 中引入的所有行为变更。如果 targetSdk 为 31,系统不会应用 API 32-33 的变更,从而保持与旧行为的兼容性。这是最重要的安全参数:Google Play 要求 targetSdk 不早于当前 API Level 1 年。

compileSdkVersion

compileSdkVersion 是代码编译所针对的 Android SDK 版本。它确定编译时可用的 API。compileSdk 必须 >= targetSdk,并且理想情况下应等于最新的稳定 API Level。提高 compileSdk 不会影响运行时行为 — 只会影响编译器的 API 可用性。提高 compileSdk 后,需要检查代码中的弃用 API 和新的权限要求。

kotlin
// build.gradle.kts — API Level 配置示例
plugins {
    id("com.android.application") version "8.7.0"
    id("org.jetbrains.kotlin.android") version "2.1.0"
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36  // Android 16

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26      // Android 8.0
        targetSdk = 36    // Android 16
        versionCode = 1
        versionName = "1.0.0"
    }

    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }

    kotlinOptions {
        jvmTarget = "17"
    }
}

dependencies {
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
    implementation("androidx.activity:activity-ktx:1.9.3")
}

build.gradle.kts 示例中,compileSdk = 36(撰写时为最新版本),targetSdk = 36,minSdk = 26(Android 8.0)。compileSdk 36 提供对所有 Android 16 API 的访问。targetSdk 36 启用所有 Android 16 行为变更。minSdk 26 覆盖约 85% 的设备。AndroidX Activity KTX 和 AppCompat 为 Fragment 和主题提供向后兼容性。

AndroidManifest.xml

minSdk 和 targetSdk 参数也可以在 AndroidManifest.xml 中指定,但现代项目使用 build.gradle — Gradle 的值会覆盖清单文件。在清单中,对于不使用 Gradle 构建配置的库和模块,指定 可能很有用。

行为变更:targetSdk 如何影响应用行为

行为变更 是对 Android 系统工作方式的修改,仅适用于 targetSdk >= 特定 API Level 的应用。每个新的 Android 发布版本都会引入行为变更,如果现有应用不更新,这些变更可能会破坏它们。这是 Android 的一个关键安全机制:旧应用继续像以前一样工作,新应用则遵守当前规则。

各版本的主要行为变更

Android 10(API 29)- Scoped Storage:targetSdk 29+ 的应用无法直接访问共享文件系统,只能通过 MediaStore、SAF 或自有存储访问。Android 11(API 30)- Package Visibility:包过滤器,应用只能看到与其交互的已安装包。Android 12(API 31)- Foreground Service Notification:所有前台服务必须在启动后 10 秒内显示通知。Android 13(API 33)- POST_NOTIFICATIONS:推送通知的运行时权限。Android 14(API 34)- Foreground Service Types:在清单中强制声明前台服务类型。

kotlin
// 处理 Android 13(API 33)行为变更:POST_NOTIFICATIONS
import android.Manifest
import android.content.pm.PackageManager
import android.os.Build
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class NotificationHelper {

    fun requestNotificationPermission(activity: MainActivity) {
        // POST_NOTIFICATIONS 权限仅适用于 API 33+
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) {
            return  // 低于 API 33 不需要此权限
        }

        when {
            ContextCompat.checkSelfPermission(
                activity,
                Manifest.permission.POST_NOTIFICATIONS
            ) == PackageManager.PERMISSION_GRANTED -> {
                // 权限已授予,可以发送通知
                showNotification(activity)
            }

            activity.shouldShowRequestPermissionRationale(
                Manifest.permission.POST_NOTIFICATIONS
            ) -> {
                // 显示为何需要该权限的说明
                activity.showRationale()
            }

            else -> {
                // 请求权限
                activity.requestPermissionLauncher.launch(
                    Manifest.permission.POST_NOTIFICATIONS
                )
            }
        }
    }

    private fun showNotification(context: Context) {
        // 创建并显示通知
        val notification = android.app.Notification.Builder(context, "default_channel")
            .setSmallIcon(android.R.drawable.ic_dialog_info)
            .setContentTitle("通知")
            .setContentText("新消息")
            .build()
        val manager = context.getSystemService(Context.NOTIFICATION_SERVICE)
            as android.app.NotificationManager
        manager.notify(1, notification)
    }
}

// 在 Activity 中注册 requestPermissionLauncher
class MainActivity : ComponentActivity() {
    val requestPermissionLauncher = registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // 权限已授予
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

在 Kotlin 中处理 POST_NOTIFICATIONS 的示例:检查 Build.VERSION.SDK_INT >= TIRAMISU,通过 ActivityResultContracts.RequestPermission 请求运行时权限,在回调中处理结果。没有此权限,targetSdk 33+ 的应用无法显示推送通知。低于 API 33 不需要权限 — 检查代码可防止调用不可用的 API。

Scoped Storage(Android 10+)

Scoped Storage 是最重要的行为变更之一。从 API 29(targetSdk 29+)开始,应用无法直接访问 Pictures、Downloads、Music 和 Documents 目录。取而代之的是,使用 MediaStore 处理媒体文件,SAF(Storage Access Framework)处理任意文件,getExternalFilesDir() 处理应用自有存储。具有 MANAGE_EXTERNAL_STORAGE 权限的应用是例外,这需要 Google Play 的批准。

Google Play 对 API Level 和 targetSdk 的要求

Google Play 对发布应用设定了强制性的 targetSdkVersion 要求。自 2024 年 8 月起,Google Play 要求 targetSdkVersion >= API 33(Android 13)。每年门槛都会提高:新应用和更新必须指定不早于当前主 API Level 1 年的 targetSdk。违反要求将导致发布被阻止,应用从商店中移除。

Google Play 为何收紧要求

主要原因是安全性。每个新的 Android API Level 都会引入行为变更,以关闭攻击向量:Scoped Storage(API 29)防止文件被盗,POST_NOTIFICATIONS(API 33)保护免受垃圾通知打扰,Foreground Service Types(API 34)限制隐藏的后台服务。targetSdk 低的应用无法获得这些保护,成为对用户的威胁。Google Play 不能允许过时的应用在現代设备上运行。

检查与要求的符合性

Google Play Console 在上传 APK/AAB 时检查 targetSdkVersion。如果 targetSdk 低于要求 — 控制台会阻止发布,并显示消息:"Your app currently targets API level X and must target at least API level Y"。开发者必须更新 build.gradle,重新编译应用,测试行为变更,然后重新上传。建议所有新发布使用 AAB 格式(自 2021 年 8 月起强制要求)。

日期最低 targetSdkAndroid 版本
2022 年 8 月31Android 12
2023 年 8 月33Android 13
2024 年 8 月33Android 13
2025 年 8 月34Android 14
2026 年 8 月(计划)35Android 15

在代码中检查 API Level:Build.VERSION.SDK_INT

Build.VERSION.SDK_INT 是一个静态整数常量,包含应用运行设备的 API Level。它是运行时检查 Android 版本的主要工具。Build.VERSION_CODES 包含每个 API Level 的命名常量:VERSION_CODES.TIRAMISU(33)、VERSION_CODES.UPSIDE_DOWN_CAKE(34)、VERSION_CODES.VANILLA_ICE_CREAM(35)。通过 if (SDK_INT >= VERSION_CODES.TIRAMISU) 进行比较是标准模式。

kotlin
// Android 代码中检查 API Level 的示例
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.graphics.drawable.AdaptiveIconDrawable

class ApiLevelHelper {

    // 1. 基本 API Level 检查
    fun isAtLeastTiramisu(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU  // 33
    }

    // 2. 带检查的自适应 API 调用
    fun getAdaptiveIcon(drawable: android.graphics.drawable.Drawable):
            android.graphics.drawable.Drawable? {
        // AdaptiveIconDrawable 仅适用于 API 26(Android 8)
        if (VERSION.SDK_INT >= VERSION_CODES.O) {
            return AdaptiveIconDrawable(drawable, null)
        }
        return drawable  // 针对旧设备的 fallback
    }

    // 3. 检查 POST_NOTIFICATIONS 权限(仅限 API 33+)
    fun canRequestNotificationPermission(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU
    }

    // 4. 根据 API Level 选择图片提供器
    fun getImagePickerProvider(): String {
        return when {
            VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
                // API 34+ 使用 PhotoPicker
                "photo_picker"
            }
            VERSION.SDK_INT >= VERSION_CODES.KITKAT -> {
                // API 19+ 使用 Intent ACTION_OPEN_DOCUMENT
                "open_document"
            }
            else -> {
                // Legacy:ACTION_GET_CONTENT(所有版本)
                "get_content"
            }
        }
    }

    // 5. 通过 @TargetApi 进行 Java 风格的检查(用于向后兼容性)
    @Suppress("DEPRECATION")
    fun checkLegacyStorage(): Boolean {
        // Scoped Storage 的行为取决于 targetSdk,而非 SDK_INT
        return VERSION.SDK_INT < VERSION_CODES.Q  // Android 10
    }

    // 6. 用于分析的构建信息
    fun getDeviceApiInfo(): Map<String, Any> {
        return mapOf(
            "sdk_int" to VERSION.SDK_INT,
            "release" to VERSION.RELEASE,
            "codename" to VERSION.CODENAME,
            "incremental" to VERSION.INCREMENTAL,
            "preview_sdk" to VERSION.PREVIEW_SDK_INT
        )
    }
}

// 测试
fun main() {
    val helper = ApiLevelHelper()
    println("API Level: ${VERSION.SDK_INT}")
    println("Is Tiramisu+: ${helper.isAtLeastTiramisu()}")
}

ApiLevelHelper 类演示了所有主要的 API Level 检查模式:isAtLeastTiramisu 使用 SDK_INT >= VERSION_CODES,getAdaptiveIcon 使用旧的版本的 fallback,getImagePickerProvider 使用 when 多分支,getDeviceApiInfo 用于分析。关键规则是:不要在不检查 SDK_INT 的情况下调用新 API,否则应用将在旧设备上因 NoSuchMethodError 而崩溃。

ANT(Android New API)与 lint

Android Studio 包含静态分析器 lint,它会警告使用高于 minSdkVersion 的 API。如果调用方法时不检查 SDK_INT,lint 会将其标记为错误:"Call requires API level 34 (current min is 26)"。解决方案:在方法上添加 @RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE),或对 SDK_INT 进行 if 检查。@TargetApi 是已弃用的注释,建议使用 @RequiresApi。

API Level 与 Android 版本对应表

API Level 表是开发者的参考工具。了解设备的 API Level,可以确定 Android 版本和可用功能。该表列出了从 API Level 1(2008 年)到 API Level 36(2025 年)的所有主要 Android 版本。代码名称(Cupcake、Donut、Tiramisu、VanillaIceCream)在 Google 内部和 VERSION_CODES 中使用。

API LevelAndroid 版本代码名称年份
11.02008
31.5Cupcake2009
82.2Froyo2010
144.0Ice Cream Sandwich2011
194.4KitKat2013
215.0Lollipop2014
236.0Marshmallow2015
268.0Oreo2017
289Pie2018
2910Quince Tart (10)2019
3011Red Velvet Cake2020
3112Snow Cone2021
3313Tiramisu2022
3414Upside Down Cake2023
3515Vanilla Ice Cream2024
3616Baklava2025

表:行为变更的阈值 API Level

下表显示在提高 targetSdk 时引入破坏向后兼容性行为变更的关键 API Level:

API Level行为变更对应用的影响
29Scoped Storage无法直接访问 Pictures/Downloads/Music
30Package VisibilityqueryIntentActivities() 仅能看到相互作用的包
31Foreground Service Notification10 秒内强制显示通知
33POST_NOTIFICATIONS通知的运行时权限
34Foreground Service Types在清单中声明前台服务类型
35Privacy Sandbox广告标识符限制

常见问题解答

Android 中的 API Level 是什么?

Android API Level 是 Android API 版本的整数标识符。每个版本都有唯一的编号:Android 13 = API 33、Android 14 = API 34、Android 15 = API 35、Android 16 = API 36。开发者在 build.gradle 中指定 minSdkVersion、targetSdkVersion 和 compileSdkVersion 来管理兼容性。API Level 决定可用的类、方法和行为变更。

minSdk 与 targetSdk 和 compileSdk 有何区别?

minSdkVersion — 安装应用的最低 Android 版本。targetSdkVersion — 应用测试所针对的版本,包含行为变更。compileSdkVersion — 编译代码的 SDK 版本。minSdk 最低,targetSdk 最好是最新版本,compileSdk 必须至少为 targetSdk。三者都在 build.gradle 中指定。

如果我将 targetSdk 设置为低于设备 Android 版本会怎样?

如果 targetSdkVersion 低于设备的 API Level,Android 会禁用 targetSdk 之后引入的行为变更。例如,在 Android 14(API 34)上使用 targetSdk = 28,Scoped Storage、POST_NOTIFICATIONS、Foreground Service Types 将不会生效。Google Play 要求 targetSdkVersion 不早于当前 API Level 1 年,以确保用户安全。

如何查看设备的 API Level?

设备的 API Level 可通过常量 Build.VERSION.SDK_INT 获取(例如,Android 14 为 34)。比较时使用 Build.VERSION_CODES 中的命名常量:if (SDK_INT >= VERSION_CODES.TIRAMISU)。Build.VERSION.RELEASE 返回版本字符串("14")。SDK_INT 值在类加载时缓存,可从任何线程访问。

为什么 Google Play 每年要求新的 targetSdk?

Google Play 每年提高 targetSdkVersion 要求,以实施安全行为变更。每个新的 API Level 都会引入 Scoped Storage、POST_NOTIFICATIONS、Privacy Sandbox 和其他保护措施。targetSdk 低的应用绕过这些保护,给用户带来风险。该要求确保商店中的所有应用都按照当前规则进行了测试。

总结

  • API Level — Android API 版本(1-36)的整数标识符,用于管理应用兼容性
  • minSdkVersion 设置安装的最低 API Level,targetSdkVersion — 带有行为变更的版本,compileSdkVersion — 用于编译的版本
  • 行为变更(Scoped Storage、POST_NOTIFICATIONS、Foreground Service Types)仅在 targetSdk >= 相应 API Level 时适用
  • Google Play 要求 targetSdk 不早于 1 年,否则会阻止应用发布
  • Build.VERSION.SDK_INT — 设备 API Level 的运行时检查,用于配合 fallback 安全调用新 API
  • lint 在 Android Studio 中警告使用高于 minSdk 的 API,并建议对方法使用 @RequiresApi
  • API 34+ 的行为变更 包括强制性的前台服务类型,API 35+ — Privacy Sandbox 与广告标识符限制

我们将开发一款交钥匙移动应用程序

IT Sectr自2017年以来为初创企业和企业打造iOS和Android应用程序。我们将为您提供咨询并提出最佳解决方案。

讨论项目

另请阅读