Android API Level 是一个整数标识符,唯一对应 Android 平台的特定版本。每个操作系统版本都有唯一的编号:Android 14 = API 34,Android 15 = API 35。开发者在 build.gradle 中管理三个参数 — minSdkVersion、targetSdkVersion 和 compileSdkVersion — 以控制兼容性和对新功能的访问。根据 Android Developers,选择正确的 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 应用行为变更。
安装应用时,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 |
在 build.gradle 文件(Module: app)中,开发者指定三个 API Level 参数:minSdkVersion、targetSdkVersion 和 compileSdkVersion。混淆它们是初级 Android 开发者最常见的错误之一。每个参数负责兼容性的不同方面,它们的值必须保持一致。
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 是应用测试所针对的 API Level。Android 使用 targetSdk 来应用行为变更:如果应用指定 targetSdk 33,系统会启用 API 33 中引入的所有行为变更。如果 targetSdk 为 31,系统不会应用 API 32-33 的变更,从而保持与旧行为的兼容性。这是最重要的安全参数:Google Play 要求 targetSdk 不早于当前 API Level 1 年。
compileSdkVersion 是代码编译所针对的 Android SDK 版本。它确定编译时可用的 API。compileSdk 必须 >= targetSdk,并且理想情况下应等于最新的稳定 API Level。提高 compileSdk 不会影响运行时行为 — 只会影响编译器的 API 可用性。提高 compileSdk 后,需要检查代码中的弃用 API 和新的权限要求。
// 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 和主题提供向后兼容性。
minSdk 和 targetSdk 参数也可以在 AndroidManifest.xml 中指定,但现代项目使用 build.gradle — Gradle 的值会覆盖清单文件。在清单中,对于不使用 Gradle 构建配置的库和模块,指定
行为变更 是对 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:在清单中强制声明前台服务类型。
// 处理 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 是最重要的行为变更之一。从 API 29(targetSdk 29+)开始,应用无法直接访问 Pictures、Downloads、Music 和 Documents 目录。取而代之的是,使用 MediaStore 处理媒体文件,SAF(Storage Access Framework)处理任意文件,getExternalFilesDir() 处理应用自有存储。具有 MANAGE_EXTERNAL_STORAGE 权限的应用是例外,这需要 Google Play 的批准。
Google Play 对发布应用设定了强制性的 targetSdkVersion 要求。自 2024 年 8 月起,Google Play 要求 targetSdkVersion >= API 33(Android 13)。每年门槛都会提高:新应用和更新必须指定不早于当前主 API Level 1 年的 targetSdk。违反要求将导致发布被阻止,应用从商店中移除。
主要原因是安全性。每个新的 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 月起强制要求)。
| 日期 | 最低 targetSdk | Android 版本 |
|---|---|---|
| 2022 年 8 月 | 31 | Android 12 |
| 2023 年 8 月 | 33 | Android 13 |
| 2024 年 8 月 | 33 | Android 13 |
| 2025 年 8 月 | 34 | Android 14 |
| 2026 年 8 月(计划) | 35 | Android 15 |
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) 进行比较是标准模式。
// 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 而崩溃。
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 表是开发者的参考工具。了解设备的 API Level,可以确定 Android 版本和可用功能。该表列出了从 API Level 1(2008 年)到 API Level 36(2025 年)的所有主要 Android 版本。代码名称(Cupcake、Donut、Tiramisu、VanillaIceCream)在 Google 内部和 VERSION_CODES 中使用。
| API Level | Android 版本 | 代码名称 | 年份 |
|---|---|---|---|
| 1 | 1.0 | — | 2008 |
| 3 | 1.5 | Cupcake | 2009 |
| 8 | 2.2 | Froyo | 2010 |
| 14 | 4.0 | Ice Cream Sandwich | 2011 |
| 19 | 4.4 | KitKat | 2013 |
| 21 | 5.0 | Lollipop | 2014 |
| 23 | 6.0 | Marshmallow | 2015 |
| 26 | 8.0 | Oreo | 2017 |
| 28 | 9 | Pie | 2018 |
| 29 | 10 | Quince Tart (10) | 2019 |
| 30 | 11 | Red Velvet Cake | 2020 |
| 31 | 12 | Snow Cone | 2021 |
| 33 | 13 | Tiramisu | 2022 |
| 34 | 14 | Upside Down Cake | 2023 |
| 35 | 15 | Vanilla Ice Cream | 2024 |
| 36 | 16 | Baklava | 2025 |
下表显示在提高 targetSdk 时引入破坏向后兼容性行为变更的关键 API Level:
| API Level | 行为变更 | 对应用的影响 |
|---|---|---|
| 29 | Scoped Storage | 无法直接访问 Pictures/Downloads/Music |
| 30 | Package Visibility | queryIntentActivities() 仅能看到相互作用的包 |
| 31 | Foreground Service Notification | 10 秒内强制显示通知 |
| 33 | POST_NOTIFICATIONS | 通知的运行时权限 |
| 34 | Foreground Service Types | 在清单中声明前台服务类型 |
| 35 | Privacy Sandbox | 广告标识符限制 |
常见问题解答
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 决定可用的类、方法和行为变更。
minSdkVersion — 安装应用的最低 Android 版本。targetSdkVersion — 应用测试所针对的版本,包含行为变更。compileSdkVersion — 编译代码的 SDK 版本。minSdk 最低,targetSdk 最好是最新版本,compileSdk 必须至少为 targetSdk。三者都在 build.gradle 中指定。
如果 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 可通过常量 Build.VERSION.SDK_INT 获取(例如,Android 14 为 34)。比较时使用 Build.VERSION_CODES 中的命名常量:if (SDK_INT >= VERSION_CODES.TIRAMISU)。Build.VERSION.RELEASE 返回版本字符串("14")。SDK_INT 值在类加载时缓存,可从任何线程访问。
Google Play 每年提高 targetSdkVersion 要求,以实施安全行为变更。每个新的 API Level 都会引入 Scoped Storage、POST_NOTIFICATIONS、Privacy Sandbox 和其他保护措施。targetSdk 低的应用绕过这些保护,给用户带来风险。该要求确保商店中的所有应用都按照当前规则进行了测试。
总结
我们将开发一款交钥匙移动应用程序
IT Sectr自2017年以来为初创企业和企业打造iOS和Android应用程序。我们将为您提供咨询并提出最佳解决方案。