29、Android 14/15新特性：SEpolicy升级约束、staged install机制、compatibility matrix
各位做系统升级的同行，今天我们来聊聊Android 14和15里几个让我印象深刻的改动。说实话，每次大版本升级，最头疼的就是兼容性问题。Google这几年一直在收紧规则，到了14/15这一代，有些做法已经和以前完全不一样了。
我个人习惯把这三个特性放在一起讲，因为它们都指向同一个目标——让系统升级更安全、更可控。咱们一个一个来看。
一、SEpolicy升级约束：不再是“想改就改”
先说说SEpolicy。做过系统升级的都知道，SEpolicy是Android安全的核心。以前我们升级时，如果SEpolicy规则变了，可能会影响第三方应用的运行。比如某个app原来能访问的设备节点，升级后突然被deny了。
Android 14/15引入了更严格的升级约束。说白了，就是Google要求：升级后的SEpolicy必须向后兼容。你不能随意删除或修改已有的allow规则，只能新增。
核心变化：
- 不允许删除已有的allow规则
- 不允许降低已有规则的权限级别
- 新增规则必须明确标注版本号
我在项目中遇到过这样一个坑：有一次我们升级系统，把某个设备的访问权限从“允许所有域”改成了“只允许系统域”。结果第三方应用全部崩溃，因为它们的进程域被deny了。这在Android 14之前还能通过，但14之后，这种改动会被OTA校验直接拒绝。
注意：如果你在Android 14/15上做OTA升级，SEpolicy的变更必须通过sepolicy-analyze工具的检查。否则升级包都生成不了。
为什么会这样？Google的思路很清晰：系统升级不应该让用户的应用突然不能用。你想想看，用户手机自动升级后，某个常用app打不开了，这体验多糟糕。
二、Staged Install机制：升级不再是“一锤子买卖”
接下来聊聊staged install。这个机制在Android 14里正式成为强制要求。以前我们做OTA升级，通常是下载完就立即安装，重启后生效。但staged install改变了这个流程。
它的核心思想是：把安装过程分成多个阶段，每个阶段都可以回滚。
具体来说，staged install把升级分为三个阶段：
- 准备阶段：下载升级包，校验签名，解压文件
- 暂存阶段：把新系统文件写入到备用分区（slot B），但不切换
- 激活阶段：重启后，bootloader切换到新分区
这样做的好处很明显。如果准备阶段失败了，系统还在旧分区上运行，用户完全无感。如果暂存阶段出问题，比如写入校验失败，系统可以自动回滚到旧版本。
我的建议：在实现staged install时，一定要处理好“暂存阶段”的断电保护。我曾经遇到过升级到一半电池耗尽的情况，幸好staged install机制自动回滚了，否则手机就变砖了。
Android 15进一步优化了这个机制。现在支持增量暂存，也就是说，如果升级包很大，可以分多次下载和暂存。这对大版本升级特别有用，比如从Android 14升到15，升级包可能有2-3GB，分阶段下载能降低网络压力。
三、Compatibility Matrix：升级的“通行证”
最后说说compatibility matrix。这个名词听起来很唬人，其实就是一个XML文件，定义了系统各个组件之间的兼容性要求。
在Android 14/15中，compatibility matrix的作用被大大强化了。它不再只是一个文档，而是OTA升级时的强制校验依据。
举个例子，你的系统里有一个HAL服务，它要求内核版本至少是5.10。这个要求就写在compatibility matrix里。当你要升级系统时，OTA工具会检查目标系统的内核版本是否满足要求。如果不满足，升级会被直接拒绝。
Compatibility Matrix的核心字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| targetFrameworkVersion | 目标框架版本 | 14 |
| kernelVersion | 要求的内核版本 | 5.10 |
| halVersion | HAL接口版本 | 2.0 |
| sepolicyVersion | SEpolicy版本 | 1.0 |
我记得有一次，客户想把一个Android 13的设备直接OTA到15。结果compatibility matrix检查发现，他们的内核还是4.19的，而15要求最低5.10。没办法，只能先升级内核，再升级系统。
这里有个容易忽略的点：compatibility matrix是双向校验的。不仅系统要满足vendor的要求，vendor也要满足系统的要求。比如系统要求某个HAL必须支持某个功能，vendor如果没实现，升级也会失败。
四、三者之间的关系
这三个特性不是孤立的。它们共同构成了Android 14/15的升级安全体系：
- SEpolicy约束保证安全策略不倒退
- Staged install保证升级过程可回滚
- Compatibility matrix保证组件间兼容性
说白了，Google在告诉你：升级可以，但必须保证用户的数据安全、应用兼容和系统稳定。任何一个环节出问题，升级就得停下来。
下面这张图展示了它们之间的协作关系：
五、实际开发中的注意事项
讲了这么多理论，说点实际的。如果你正在做Android 14/15的OTA开发，这几个点一定要记住：
避坑指南：
- 我曾经因为SEpolicy里少写了一个版本标签，导致OTA包生成失败。排查了半天才发现是
sepolicy-analyze工具报的错。 - Staged install的暂存分区大小要预留足够。我建议至少留出系统分区大小的1.5倍空间。
- Compatibility matrix里的版本号一定要和实际代码一致。别问我怎么知道的，都是泪。
另外，测试的时候一定要覆盖这些场景：
- 升级过程中断电
- 升级包损坏
- SEpolicy规则冲突
- 组件版本不匹配
嗯，今天就聊到这里。这些特性虽然增加了开发工作量，但确实让系统升级变得更安全了。作为开发者，我们既要理解这些机制的原理，也要在实际项目中做好适配。
公众号:蓝海资料掘金营，微信deep3321