什么是Android API Level？一文看懂 – wiki基地

作者： /

什么是Android API Level？一文看懂

在探索Android开发的广阔世界时，您会频繁地遇到一个核心概念——API Level。无论是查阅官方文档、配置开发环境，还是解决兼容性问题，API Level都如影随形。那么，究竟什么是Android API Level？它为何如此重要？本文将为您剥茧抽丝，深入解析Android API Level的方方面节，助您一文看懂。

一、Android API Level的定义：版本与接口的映射

简单来说，Android API Level 是一个整数值，它唯一标识了特定版本的 Android 平台所提供的框架 API（应用程序接口）修订版本。

您可以将其理解为 Android 操作系统的“接口版本号”。每当 Google 发布一个重要的 Android 平台新版本（例如 Android 12, Android 13, Android 14 等），通常也会伴随推出一个新的 API Level。这个新的 API Level 代表了该版本操作系统向开发者公开的、可用于构建应用程序的全部接口集合。

这套接口集合包括：

  1. 核心类和包： 例如 android.os (操作系统服务), android.util (实用工具), android.view (UI视图), android.widget (UI组件), android.content (内容管理), android.graphics (图形绘制), android.media (媒体播放/录制) 等等。
  2. XML清单文件元素： 比如在 AndroidManifest.xml 中声明应用组件、权限、硬件需求等所需的标签和属性。
  3. 资源文件格式和约定： 例如如何组织和访问布局、字符串、图片等资源。
  4. 平台行为和特性： 系统如何处理应用的生命周期、权限、后台任务、网络连接等等。

每一个新的 API Level 都会在前一个 API Level 的基础上进行修改、增加或删除。通常的变化包括：

  • 新增功能和 API： 为了支持新的硬件（如新传感器、折叠屏）、新的软件特性（如改进的通知系统、新的权限模型）、更好的性能或更安全的机制，会引入全新的 API。
  • 改进现有 API： 对已有的 API 进行功能增强、性能优化或行为调整。
  • 废弃或移除 API： 由于设计缺陷、安全问题、性能瓶颈或被更优的方案取代，某些旧的 API 可能会被标记为废弃（Deprecated），强烈建议开发者不再使用；在极少数情况下，非常老的或有严重问题的 API 可能会被直接移除，导致依赖这些 API 的旧应用在新平台上崩溃。

因此，API Level 不仅仅是一个数字，它代表了特定 Android 版本能够提供给应用程序使用的“能力集合”或“契约”。开发者编写应用时，就需要根据目标用户的设备所运行的 Android 版本（即对应的 API Level），来决定可以使用哪些 API。

二、API Level 的重要性：为什么开发者和用户都需要关注它？

API Level 在 Android 生态系统中扮演着至关重要的角色，其重要性体现在以下几个方面：

  1. 应用兼容性： 这是最直接、最核心的原因。一个应用程序必须运行在一个提供了其所需全部 API 的 Android 平台上。API Level 提供了一种量化的方式来判断一个应用是否兼容某个设备上运行的 Android 版本。
  2. 访问新功能： 每一个新的 API Level 都带来了最新的系统功能和优化。开发者要想在应用中使用这些新特性（例如，特定版本的通知样式、新的图形渲染能力、改进的电池管理 API、最新的安全模型等），就必须针对提供这些 API 的更高 API Level 进行开发和测试。
  3. 安全性和性能： 新的 API Level 通常包含针对安全漏洞的修复以及性能上的提升。Google 会不断引入更严格的权限模型、更优化的后台任务处理机制、更精细的电量管理策略等，这些都反映在新的 API 中。为了利用这些安全和性能优势，应用需要与较新的 API Level 对齐。
  4. 开发者工具链要求： Android 开发工具（如 Android Studio）在编译和构建应用时，需要知道开发者打算使用哪个 API Level 的 SDK（Software Development Kit）来开发。同时，Android Gradle Plugin 等构建工具也依赖于 API Level 的信息来正确地处理代码和资源。
  5. Google Play 发布要求： 为了确保 Android 生态系统的健康发展和用户的安全，Google Play 对于上传的应用有 API Level 的最低要求。开发者必须将其应用的 targetSdkVersion（稍后详细解释）设置为等于或高于某个特定的 API Level，否则无法在 Google Play 上架或更新。这个要求会随着时间的推移而提高。

对于普通用户而言，虽然不直接接触 API Level 这个概念，但它影响着他们设备的可用性和应用的使用体验：

  • 系统更新： 设备制造商发布的 Android 系统更新，本质上就是将设备的 Android 平台升级到更高的版本，对应着更高的 API Level。这使用户能够体验到最新的系统功能、获得安全更新，并能够安装或更新那些需要更高 API Level 的应用程序。
  • 应用兼容性： 如果用户设备运行的是一个非常老的 Android 版本（低的 API Level），他们可能无法安装或更新那些要求较高 API Level 的应用程序，因为这些应用依赖于设备上不存在的 API。
  • 应用行为： 由于 targetSdkVersion 的存在，同一个应用在运行不同 Android 版本的设备上，其行为可能会有所差异，以适配不同平台版本的特性和限制。

三、理解与 API Level 相关的三个关键构建配置参数

在 Android 应用开发中，有三个与 API Level 密切相关的参数，它们定义在应用的 build.gradle（或 build.gradle.kts）模块级文件中，对应用的构建、运行和兼容性起着决定性作用：

  1. compileSdkVersion (编译 SDK 版本)

    • 定义： 指定用于编译您的应用程序的 Android API Level。
    • 作用： 告诉构建工具（特别是编译器和 Lint 工具），在编译代码时使用哪个版本的 Android SDK 库。这决定了您可以直接调用哪些 API，以及编译器可以检查哪些与 API 使用相关的错误。
    • 影响：
      • 您可以访问在指定 compileSdkVersion 及以下 API Levels 中引入的所有公共 API。
      • 编译器会根据 compileSdkVersion 来检查您的代码。例如，如果您尝试调用一个在 compileSdkVersion 所对应平台版本中才引入的 API，而您的 minSdkVersion 低于这个版本，编译器可能会给出警告，提示您需要在运行时进行版本检查。
      • Lint 工具会根据 compileSdkVersion 和 minSdkVersion 进行更深入的兼容性检查。
    • 最佳实践： 强烈建议始终使用最新的稳定版 Android SDK 作为您的 compileSdkVersion。 这样做的好处是您可以访问最新的 API，利用最新的构建工具特性，并获得最新的 Lint 检查，从而帮助您编写更健壮、更现代的代码。将 compileSdkVersion 设置为最新版本并 不会 改变您应用在旧设备上的运行时行为（这由 targetSdkVersion 和运行时检查控制）。

  2. minSdkVersion (最低 SDK 版本)

    • 定义： 指定您的应用程序可以运行的最低 Android API Level。
    • 作用： 在运行时层面限制应用的安装和运行。Android 系统会检查应用的 minSdkVersion，如果设备的 API Level 低于这个值，系统将不允许安装该应用（在 Google Play 或通过包安装器）。如果应用已经在设备上，但在尝试运行时发现设备 API Level 低于 minSdkVersion，应用将无法启动。
    • 影响：
      • 直接决定了您的应用的潜在用户群体规模。minSdkVersion 越低，覆盖的设备范围越广（包括较旧的设备）；minSdkVersion 越高，覆盖的设备范围越窄（仅限于较新的设备）。
      • 影响开发工作量。如果 minSdkVersion 设置得较低，意味着您需要在代码中处理更多旧平台特有的行为、兼容性问题，并使用运行时版本检查 (if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.XYZ)) 来有条件地使用新 API。
    • 考虑因素： 选择 minSdkVersion 需要权衡用户覆盖率和开发复杂度。您可以通过查看 Android 分发平台版本仪表盘来了解不同 API Level 的设备市场份额。

  3. targetSdkVersion (目标 SDK 版本)

    • 定义： 指定您的应用程序经过测试，并且期望运行在哪个 Android API Level 上。
    • 作用： 这是最关键的一个参数，它主要影响应用在不同 Android 平台版本上的运行时行为。 当您将 targetSdkVersion 设置为某个 API Level N 时，这相当于向运行在 API Level N 或更高版本的 Android 系统“声明”，您的应用已经适配并期望按照 API Level N 的系统行为规则来运行。对于在 N 版本及之后引入的、可能影响旧应用兼容性的系统行为变更，系统会根据应用的 targetSdkVersion 来决定是否启用这些变更。
    • 影响：
      • 启用/禁用兼容性行为： Android 系统为了向前兼容，对于那些以较低 targetSdkVersion 编译的应用，可能会继续采用旧的、在较新平台版本中已被修改或移除的行为模式。而对于以较高 targetSdkVersion 编译的应用，系统会禁用这些兼容性行为，转而采用该 targetSdkVersion 所对应平台版本的最新行为。例如，从 API Level 23 (Marshmallow) 开始引入了运行时权限模型，如果一个应用的 targetSdkVersion 低于 23，即使运行在 Android 6.0 及以上设备上，系统仍会沿用旧的安装时权限模型；但如果 targetSdkVersion 设置为 23 或更高，应用就必须在运行时动态请求危险权限。类似的变更还包括后台服务限制、网络安全配置、文件访问权限（如 Scoped Storage）等等。
      • 性能和安全优势： 将 targetSdkVersion 更新到较新的 API Level，可以让您的应用享受到新平台版本带来的性能优化、电量管理改进以及更严格的安全机制。
      • Google Play 要求： Google Play 会强制要求新应用或应用更新将其 targetSdkVersion 设置为在规定日期前最新的或倒数第二新的 API Level。这是为了推动整个生态系统向新平台版本迁移，提升安全性和用户体验。
    • 最佳实践： 强烈建议始终将 targetSdkVersion 更新到尽可能高的、并且您已经充分测试通过的 API Level，理想情况下是最新稳定版。 定期更新 targetSdkVersion 是维护应用兼容性、安全性和利用新平台特性的必要步骤。这通常需要投入开发和测试资源来适配新平台引入的行为变更。

三者的关系总结：

  • compileSdkVersion >= targetSdkVersion >= minSdkVersion
  • compileSdkVersion 影响 编译时 可用 API 和 Lint 检查。
  • minSdkVersion 影响应用可运行的 最低平台版本，决定潜在用户范围。
  • targetSdkVersion 影响应用在 较新平台版本上 的 运行时行为，决定是否启用新的系统兼容性行为。

四、Android API Level 的演进与重要里程碑

自从 Android 平台诞生以来，API Level 随着每一次主要版本迭代而增加。了解一些重要的 API Level 及其引入的关键特性，有助于更好地理解 API Level 的作用和 Android 平台的发展方向。

以下是一些具有代表性的 API Level 及其大致对应的 Android 版本名称和关键特性（请注意这并非完整的列表）：

  • API Level 1 (Android 1.0): Android 平台初版，提供基本功能。
  • API Level 3 (Android 1.5 Cupcake): 引入软键盘、Widget、文件夹、Copy/Paste等。
  • API Level 4 (Android 1.6 Donut): 引入WVGA屏幕支持、手势框架、快速搜索框。
  • API Level 7 (Android 2.1 Eclair): 引入动态壁纸、多点触控事件。
  • API Level 8 (Android 2.2 Froyo): 引入 JIT 编译器、Push 消息、应用安装到 SD 卡。
  • API Level 9 (Android 2.3 Gingerbread): 改进 UI 性能、引入 NFC、陀螺仪、多摄像头支持。
  • API Level 14 (Android 4.0 Ice Cream Sandwich): 统一手机和平板 UI、引入 ActionBar、硬件加速。
  • API Level 16 (Android 4.1 Jelly Bean): 引入 Project Butter 提升流畅度、可扩展通知、Google Now。
  • API Level 18 (Android 4.3 Jelly Bean): 引入 Bluetooth Low Energy (BLE)、OpenGL ES 3.0。
  • API Level 19 (Android 4.4 KitKat): 优化内存管理、引入沉浸模式、打印框架。
  • API Level 21 (Android 5.0 Lollipop): 引入 Material Design、ART 运行时、通知中心改进、JobScheduler。
  • API Level 23 (Android 6.0 Marshmallow): 引入运行时权限、 Doze 省电模式、App Links、指纹识别 API。（这是处理权限的重要分水岭）
  • API Level 24 & 25 (Android 7.0 & 7.1 Nougat): 引入分屏模式、通知改进（Bundle通知、直接回复）、Doze on the Go、Vulkan 图形 API、Multi-window API。
  • API Level 26 & 27 (Android 8.0 & 8.1 Oreo): 引入后台限制（限制后台服务、广播接收器等）、 通知渠道、画中画模式、自适应图标、Autofill 框架。（后台限制是重要变革）
  • API Level 28 (Android 9 Pie): 引入刘海屏支持、通知改进、多摄像头 API、Image Decoder、新的电源管理功能（Adaptive Battery）。
  • API Level 29 (Android 10 Q): 强制 Scoped Storage（分区存储）、 引入深色主题、手势导航、更好的隐私控制、定位权限细化（仅在使用时允许）。（Scoped Storage 是文件访问的重大变革）
  • API Level 30 (Android 11 R): 进一步强化 Scoped Storage、软件包可见性限制、更好的会话通知、单次权限授予、无线调试。
  • API Level 31 (Android 12 S): 引入 Material You 设计、更流畅的动画、隐私仪表盘、 approximate location、蓝牙权限独立。
  • API Level 33 (Android 13 Tiramisu): 通知权限、主题图标、per-app language preferences、提升照片选择器。
  • API Level 34 (Android 14 U): 通知权限运行时要求更加严格、非可解除通知限制、数据安全声明改进等。

从这个演进过程中可以看出，API Level 的提升不仅带来了新的功能，更重要的是，它反映了 Android 平台在 安全性、隐私保护、性能优化、用户体验一致性 等方面的持续改进和演进。开发者紧随这些变化，并及时更新应用的 targetSdkVersion，是确保应用在未来 Android 版本上能够良好运行并提供最佳体验的关键。

五、如何在开发中处理不同的 API Level？

由于 Android 设备的碎片化，您的应用很可能需要在运行不同 Android 版本的设备上运行。这意味着您的应用必须兼容从 minSdkVersion 到用户设备当前 API Level 之间的所有版本。开发者主要通过以下方式来处理不同 API Level 的兼容性：

  1. 设置正确的 minSdkVersion： 根据目标用户群体和开发成本权衡，选择一个合理的最低支持版本。
  2. 设置正确的 targetSdkVersion： 尽量将其设置为最新或次新版本，并认真测试和适配新平台带来的行为变更。

  3. 使用运行时版本检查： 对于在较高 API Level 中才引入的新功能或新 API，必须在代码中通过 Build.VERSION.SDK_INT 和 Build.VERSION_CODES 进行运行时判断。

    java
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { // 对应 API Level 23 (Marshmallow)
    // 在 Android 6.0 (API 23) 或更高版本上才可用的代码，例如请求运行时权限
    requestPermissions(...);
    } else {
    // 在低于 Android 6.0 的版本上执行的代码
    }

  4. 利用 Android Jetpack (AndroidX) 库： AndroidX 是 Android 支持库的演进版本，提供了许多向后兼容的组件和 API。例如，通过使用 AppCompatActivity、Material Components、Fragment、Lifecycle、ViewModel、WorkManager 等 Jetpack 库，开发者可以在较低 API Level 上使用许多原本只在高 API Level 中才有的功能或模式，或者以统一的方式处理不同 API Level 的行为差异。

  5. 适配不同的系统行为变更： 当提高 targetSdkVersion 时，需要仔细阅读对应 API Level 的行为变更文档，并修改代码以适配新的限制或规则（例如，后台执行限制、文件访问方式、权限请求流程等）。这通常是更新 targetSdkVersion 过程中最耗时但也最重要的部分。
  6. 充分测试： 在不同 API Level 的物理设备或模拟器上测试应用，特别是测试 minSdkVersion 和 targetSdkVersion 对应的设备，确保应用在不同环境下都能正常工作。

六、总结：API Level 是 Android 开发的基石

Android API Level 是理解 Android 平台版本和其提供的开发接口的核心概念。它是一个整数，将特定的 Android 平台版本与一套完整的框架 API 关联起来。

对于开发者而言，理解并正确配置 compileSdkVersion、minSdkVersion 和 targetSdkVersion 至关重要。compileSdkVersion 决定了您可以编译时使用哪些 API，minSdkVersion 决定了应用可以运行的最低设备版本，而 targetSdkVersion 则影响着应用在较新设备上的运行时行为和系统兼容性。

随着 Android 平台的不断发展，API Level 也持续迭代，带来新的功能、改进、以及对安全和隐私更严格的要求。开发者需要紧跟 API Level 的更新，及时调整开发策略，利用运行时检查和支持库来兼顾兼容性和新特性，并定期更新 targetSdkVersion 以满足 Google Play 的要求，确保应用能够适配未来的 Android 版本，为用户提供安全、高性能、功能丰富的体验。

无论是新手还是经验丰富的 Android 开发者，对 API Level 的深入理解和恰当处理都是构建高质量 Android 应用的基石。希望通过本文的详细介绍，您已经对 Android API Level 有了一个全面清晰的认识。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部