第1章 Android SDK版本演进与兼容性概述

做 Android 开发这些年，我见证过 SDK 版本从早期的 Cupcake 一路跑到现在的 U。说实话，每次大版本发布，最让人头疼的并不是新功能有多酷，而是——我的老代码还能跑吗？

这一章，我们就来聊聊 Android SDK 的版本演进，以及兼容性到底意味着什么。我个人的经验是：搞懂历史，才能预判未来。你想想看，如果不清楚每个版本改了哪些 API，回归测试就很容易变成“盲人摸象”。

1.1 Android SDK的演进历程：从Cupcake到Android 14

Android 版本号从 1.0 开始，几乎每年一个大版本。早期版本（1.5~4.4）变化剧烈，底层框架和API频繁重构。我记得在 4.0 时代，我接手过一个老项目，里面大量使用 android.view.View.setBackgroundDrawable()，在 4.1 上直接 crash——因为该方法被标记为 deprecated 并在新设备上行为变了。

后来版本趋于稳定，但 API 的增删改依然不少。下面这个表格整理了近几个主要版本的关键 API 变化，方便你快速回顾：

这里面每一个版本，都带着一批 “deprecated” 和 “behavior changes”。我建议你把这些变化整理成一张清单，每次上新版本 targetSdkVersion 之前，逐条核对。

1.2 兼容性的核心挑战：你在对抗什么？

说白了，兼容性问题本质上就是“新旧行为不一致”。主要来源有三个：

• API 移除或废弃（Deprecation）：老方法还能用，但编译器会警告，且版本越高越可能直接抛异常。比如 android.os.AsyncTask 在 API 30 被标记废弃。
• 行为变更（Behavior Changes）：同一个 API 在不同版本上表现不同。例如在 Android 10 之后，Environment.getExternalStorageDirectory() 返回的目录权限受限。
• 新平台特性强制影响：比如 Android 12 的 SplashScreen，如果你不配启动画面，系统会自己给你画一个白屏，丑到爆。我曾经因为这个被用户骂过。

你可能会问：为什么 Google 非要这么折腾？其实原因很简单：用户体验和安全性。每一次收紧权限，都伴随着一堆老应用无法正常使用。嗯，这就是我们测试工程师存在的意义——帮业务方平稳过渡。

我把兼容性挑战的关键维度画了一张图，方便你直观理解：

1.3 为什么要做好兼容性回归保障？

你可能觉得，反正用户不升级 targetSdkVersion 也能用，干嘛那么麻烦？但现实是：

• 新设备强制新系统：Google 和主流厂商在 2023 年之后，新出厂的设备最低都是 Android 12 起。你若不适配，直接崩溃率飙升。
• 应用市场合规要求：Google Play 逐年提高 targetSdkVersion 要求。低于 API 31 的应用在 2023 年 8 月后已经无法更新。
• 用户口碑：我经历过一次线上事故：用户升级到 Android 13 后，我们的应用在通知栏弹不出消息——因为没加 POST_NOTIFICATIONS 权限声明。一夜之间差评如潮。

所以回归测试不是“可选优化”，而是“生存底线”。只有建立一套基于 API 差异分析的回归机制，才能把风险降到最低。后面几节，我会详细拆解具体的检测手段和工具链。