外观
Android 系统基线升级和定制版本怎样适配？
标准回答
系统基线升级不是改完 compileSdk、能编译就结束。我会先梳理应用依赖的公开 API、系统接口、权限、后台行为、资源配置和定制补丁，再对照目标版本的行为变化建立影响清单。
这里要分开三个概念：compileSdk 决定编译时可用的 API；targetSdk 会参与某些兼容行为的选择；设备实际系统版本决定运行环境。有些变化影响所有应用，有些只在目标版本提高后启用。排查时可固定 APK 比较不同系统，再固定系统比较 targetSdk 或兼容性开关，避免把多个变量同时改掉后无法归因。
对定制项目，我会把公共逻辑和机型能力适配分开，记录每个定制补丁的需求、依赖和上游变化。合并冲突解决后，还要确认原有语义是否仍成立：上游可能已调整生命周期、权限检查或线程模型，代码合上并不代表行为正确。
验证覆盖首次安装和升级安装、存量数据迁移、多用户、权限撤销、前后台切换、进程重启及关键 Agent 工具。发布时保留功能开关和兼容的数据读取方案，出现问题能停止新增任务或回退功能；已经迁移的数据和已发生的设备动作要单独处理，不能只靠回退 APK。
关键机制
- 先列依赖与变化，再建立系统版本、目标版本、机型和授权状态的验证矩阵。
- 区分源码合并成功、接口兼容和业务语义正确。
- 检查升级路径与存量任务；功能回退和数据回退分别设计。
通俗例子
旧系统后台能启动的流程在新系统失败：先确认启动发生时应用是否可见、目标版本、服务类型和系统限制，再选择合适的任务机制；不能直接把所有后台工作改为前台服务。
追问与回答
怎样控制多个定制版本的维护成本？
我会把差异整理成能力表与配置，把确实不同的系统调用放到适配接口后面，公共业务尽量使用同一实现。每个定制补丁保留原因、适用基线和验证用例；上游能力已经满足需求时及时移除旧补丁。这样升级时能逐项确认，而不是在业务代码中查找大量散落的机型判断。
新版本只有部分设备失败，先查什么？
我会按系统版本、机型、应用版本、权限状态和升级路径分组，找出失败共同条件，再对比同一操作的成功与失败日志。先确认是能力缺失、授权差异、时序变化还是数据迁移问题，再缩小复现矩阵。必要时先关闭受影响设备上的新功能，保留核心能力。
易混淆点
SDK_INT 分支只能解决部分差异；厂商能力、授权配置和服务协议也可能不同。兼容性开关用于定位与验证，不应当作长期绕过规则的发布方案。
参考资料
内容来源
- Android 技术札记 · 原条目
system-baseline