1. TargetSDK 是什么？为什么需要升级？
如果你做过 Android 应用维护，一定遇到过这种场景：
新手机跑你的 App，弹出一堆权限对话框，或者文件突然读不到了。用户骂兼容性差，开发群里问了一圈，最后发现是 targetSdkVersion 没升级。
说白了，targetSdkVersion 就是你对系统喊的一句话：“Android 某某版本的行为变更，我已经适配过了，你直接启用吧。”
这个属性声明在 AndroidManifest.xml 里，它不决定你的 App 能用哪些新 API，也不决定最低支持到哪个版本，但它决定了——当系统行为发生变化时，你的 App 会不会被“特殊照顾”。
核心一句话： targetSdkVersion 是“行为变更的开关”。升了，新规则对你生效；不升，系统用兼容模式保你老代码不出事，但代价是失去新平台的安全与体验。
1.1 三个版本属性，别再搞混了
很多新人把 compileSdkVersion、minSdkVersion、targetSdkVersion 混着用。我见过不少团队，直接把三个值写成一样，问就是“省事”。
其实它们各有各的职责：
| 属性 | 作用 | 举个例子 |
|---|---|---|
compileSdkVersion |
编译时能用的 API 范围 | 设成 34，你就可以调 Android 14 的新接口 |
minSdkVersion |
最低支持到哪个系统版本 | 设成 23，Android 6.0 以下的用户装不了 |
targetSdkVersion |
告诉系统：我针对哪个版本做过适配 | 设成 33，Android 13 的通知权限变更就会对你生效 |
你想想看：compileSdk 只管编译时能不能通过，minSdk 只管能不能安装，只有 targetSdk 直接影响运行时的系统行为。这三者不是一回事，也不能互相替代。
我个人的习惯： compileSdk 始终用最新稳定版，方便用新 API 做条件判断；minSdk 根据产品用户分布定；targetSdk 紧跟 Google Play 政策，每年至少升一个大版本。
1.2 为什么必须升级？四个字：生存合规
你可能会觉得：“我的 App 跑得好好的，升它干嘛？”
原因很现实——不升，你根本发不了版本。
- Google Play 强制要求： 从 2019 年起，新应用 targetSdkVersion 必须 ≥ 28；2020 年起，更新应用也必须 ≥ 29。现在更是要求 ≥ 31 甚至更高。不达标，上传直接被拒。
- 国内厂商也在跟进： 华为、小米、OPPO、vivo 等主流商店，近两年陆续要求 targetSdkVersion ≥ 30。我去年接过一个渠道反馈，就因为 target 是 28，直接被驳回。
- 隐私与安全： 每个新版本 Android 都在收紧权限。比如 Android 11 的权限自动重置、Android 13 的通知权限、Android 14 的屏幕内容限制。不升级，用户数据暴露风险高，而且系统会一直弹“此应用为旧版设计”的提示。
- 新功能支持： 比如 Material You 动态颜色、预测性返回手势、更好用的后台省电策略，这些都需要 targetSdkVersion ≥ 对应版本才能完整体验。
注意： 有些团队以为“不升级就没风险”，其实恰恰相反。从 Android 10 开始，系统对 targetSdkVersion < 29 的应用会显示“兼容模式警告”，甚至限制后台弹窗、文件读取等能力。用户体验会越来越差。
1.3 升级到底难在哪？
我在项目中确实遇到过不少坑，总结下来主要三个痛点：
- 行为变更多且细： 每个版本都有 20-30 条行为变更，有些是全局的，有些只对 targetSdkVersion 达标的应用生效。你得逐条对照官方文档过一遍。
- 第三方库不兼容： 比如你用了某个老版本的图片加载库，它可能用了已废弃的文件路径 API，target 一升直接崩溃。我曾经因为一个日志库的 target 没跟上，导致 Android 11 上写日志就闪退，查了两个晚上。
- 回归测试工作量大： 权限弹窗变了、文件访问路径变了、通知渠道变了……人工回归一轮至少两天。如果是大版本跨级升级（比如从 28 直接升到 33），测到想哭。
但再难也得干。不升是慢性死亡，升了是阵痛，痛完就爽了。
1.4 升级前后的变化对比
拿存储权限举个例子，你感受一下差距：
| 场景 | targetSdkVersion < 29 | targetSdkVersion ≥ 29 |
|---|---|---|
| 读取公共目录图片 | 直接读路径就行 | 必须用 MediaStore API |
| 写文件到 Downloads | 直接写路径 | 必须用 SAF 或 MediaStore |
| 访问外部存储 | 申请 READ_EXTERNAL_STORAGE 即可 | 基本用不到全存储权限，除非是文件管理器类应用 |
不升的话，你的 App 还能用老路径，但 Android 10+ 用户会收到“此应用可能与你当前设备不兼容”的警告。你想想，用户看到这个提示，还会放心用吗？
我的经验： 不要试图用“targetSdkVersion 不升 + 兼容模式”来逃避适配。系统迟早会收紧，而且每次大版本更新，兼容模式下的限制只会更多。早升早安心。
1.5 升级的通用路径
每升一次 targetSdkVersion，我都会走一个固定流程，分享给你参考：
- 第一步：查官方行为变更文档。 从当前 target 版本到目标版本，逐版看“针对 targetSdkVersion 的应用”部分。
- 第二步：跑一遍兼容性测试。 用目标版本的模拟器或真机，跑全功能用例，重点测权限、文件、通知、后台任务。
- 第三步：修复与替换。 废弃 API 换成新 API，权限逻辑按新模型重写，第三方库更新到兼容版本。
- 第四步：灰度验证。 先发一版内测，收集崩溃和异常，确认没问题再全量。
避坑指南： 我曾经跳过第一步直接改 target，结果 Android 12 上闹钟功能全废——因为精确闹钟权限没申请。后来学乖了，每升一级都把官方文档打印出来逐条打勾。
下面的图总结了 targetSdkVersion 升级的核心逻辑，方便你整体把握：
1.6 升级前，先问自己三个问题
每次启动升级前，我习惯先过一遍这三个问题，能省掉不少试错时间：
- 当前 targetSdkVersion 是多少？ 如果还在 28 以下，建议先跳到 29，再逐级往上，不要一次跨太多。
- 目标版本有哪些强制行为变更？ 重点看权限、文件、后台、通知这四大块，它们几乎每次都改。
- 测试覆盖够不够？ 特别是权限弹窗和文件读写相关的场景，必须真机+模拟器双覆盖。
我曾经犯过的错： 有次把 targetSdkVersion 从 28 直接升到 31，结果 Android 12 上的通知渠道全部失效——因为没适配通知权限的运行时申请。那次回滚加紧急修复，折腾了整整三天。所以，别偷懒，逐级适配。
好了，这一章的核心就是：targetSdkVersion 不是摆设，它是系统行为变更的开关，也是应用在 Android 生态里的“合规身份证”。 不升级，你可能会被商店拒之门外，也可能让用户暴露在隐私风险中。升级虽然有点疼，但这是每个 Android 开发者必须面对的功课。