Android系统定制：OTA升级链路全解析（Data分区目录、接口与SELinux）

做系统定制开发的同仁应该都遇到过这种需求：系统要支持OTA升级。乍一听这是个常见功能，但真要把这条链路完整打通——从数据分区的upgrade目录规划，到系统端接口的暴露，再到SELinux策略的放行——这里面的细节远比想象中多。我一接到"系统端提供Data分区upgrade目录创建-实现OTA功能接口-授权SELinux权限"这个任务清单，就知道这活儿不是简单改几行配置能交差的，它横跨分区管理、Framework服务、安全策略三个层面，任何一环掉链子，升级包要么写不进去，要么重启后根本找不到。这篇就把我实际趟过的路、填过的坑完整梳理一遍，给正在做类似定制需求的朋友一个能直接抄作业的参考。

1. 项目拆解：一条"升级链路"上的三道关卡

刚拿到需求时，我先把标题拆成了三条独立任务线。第一条是Data分区下创建upgrade目录，第二条是暴露OTA功能接口，第三条是SELinux权限授权。这三条看着孤立，实际是一条完整升级链路的前置条件。

从系统角度看，一次标准OTA升级的流程是这样的：上层应用或系统服务把升级包写入upgrade目录，写入完成后通过接口通知系统进入恢复模式（或触发update_engine），恢复模式下引导程序读取升级包内容并执行刷写，最后重启进入新系统。这条链条里，upgrade目录是升级包的"暂存仓库"，OTA接口是"发货指令"，SELinux授权是"仓库通行证"。没有仓库，包没地方放；没有指令，系统不知道啥时候开刷；没有通行证，进程连仓库门都摸不到。

这三件事里，技术含量排序是：SELinux授权最难，隐藏坑最多；接口实现最需要理解系统组件分工；目录创建看着最简单，但放在加密分区上就有不少门道。我们先从最基础的目录创建说起，但它牵扯的问题会一路延伸到后两个环节。

2. Data分区upgrade目录创建：为什么是这里，以及落地细节

2.1 目录位置选型的底层逻辑

选Data分区不是拍脑袋。Android系统里能持久读写的大分区主要有三个：system、vendor和data。system和vendor在常规方案里是只读挂载的（dm-verity校验），OTA升级包几百MB到几个GB不等，根本写不进去。cache分区理论上有读写能力，但多个厂商方案里cache分区越做越小、甚至有的设备直接没有独立cache分区，而且recovery模式下对cache的访问也会受SELinux策略限制。相比之下，data分区空间充裕、可读写、掉电不丢数据，天然适合做升级包暂存区。

具体路径上，我习惯用/data/upgrade而不是在已有目录下随便加个子目录。独立目录的好处有三：权限控制粒度干净，不用跟其他系统目录纠缠；方便后续做空间清理策略（比如升级完成后直接删目录）；日志排查时路径固定，出问题好追踪。如果是多用户设备，还要考虑这个目录在User 0的加密空间下的可见性，这个我们后面详细说。

2.2 目录创建的两种套路与取舍

实际落地时，创建目录有两个主流做法：一是通过init的rc脚本在开机早期阶段完成，二是由系统服务在运行期动态创建。

rc脚本方式比较符合"系统端提供"这个语义。在设备的init目录下新增一个升级服务脚本片段，内容长这样：

service setup_ota_dir /system/bin/setup_ota_dir.sh class late_start user system group system oneshot seclabel u:r:ota_setup:s0 on property:sys.boot_completed=1 start setup_ota_dir

对应脚本里做目录检查和权限规整：

#!/system/bin/sh OTA_DIR=/data/upgrade if [ ! -d "$OTA_DIR" ]; then mkdir -p "$OTA_DIR" fi chown system:system "$OTA_DIR" chmod 0770 "$OTA_DIR" restorecon -R "$OTA_DIR" 2>/dev/null || true

这里特别要注意restorecon。如果你直接用mkdir创建目录，SELinux上下文可能被继承为父目录的上下文，结果就是OTA相关进程拿到的是错误的安全标签，后面访问直接被拒。restorecon会把目录标签修正为file_contexts里定义的预期标签，这一步相当于是给后续SELinux授权打地基。

系统服务动态创建的方式也不少见，特别是当目录的创建时机需要晚于某些解密流程时。但这种方式有个麻烦：服务跑起来时如果目录创建失败，错误处理逻辑就得写全套，而且和init阶段的其他服务可能存在竞争条件。我个人强烈推荐rc脚本方式，把目录创建留在init阶段完成，系统服务只在启动时做一次存在性检查即可。

2.3 目录加密与恢复模式的访问难题

这是整条链路里最容易翻车的地方。如果设备启用了File-Based Encryption（FBE），data分区会为不同用户分别建立加密密钥，而升级包存放目录如果落在某个用户空间里，recovery模式下不一定能正确解锁访问。

原因不复杂：常规FBE方案中，用户数据在开机后由vold用用户密钥解密。到了recovery模式，如果recovery本身不支持该用户密钥的解密流程，那/data挂载上来看到的加密目录内容可能是乱码或完全不可见。升级包明明在目录里躺着，recovery读不到，升级自然失败。

解决的思路有两个。第一，upgrade目录尽量放在Device Encrypted（DE）存储区域而不是Credential Encrypted（CE）区域，DE区域在开机后、用户解锁前就能访问，recovery模式下也容易处理。操作上，目录的父路径层级决定了它的加密层面，所以要确保/data/upgrade不被归到某个用户CE密钥的管辖下。第二，在recovery模式下通过vold提供的--prompt流程或自定义解锁逻辑提前解开对应分区，这个改造成本更高，一般不用。

如果升级包动辄1GB以上，还有空间规划问题。有的厂商会把data分区划得很满，升级包写入时空间不足，失败得悄无声息。我在实际项目里会在OTA流程开头做一次/data/upgrade所在文件系统的剩余空间检查，低于升级包体积的1.5倍就直接拒绝升级，把问题暴露在下载阶段而不是刷写阶段。

2.4 挂在fstab层面的注意事项

最后一步是确认挂载参数。检查设备的fstab文件里data分区的挂载flag，确保包含noatime,nosuid,nodev之类的基础安全选项，同时确认没有手误加了ro。有些定制方案为了防篡改会给data分区加各种限制，如果OTA写入时分区是只读挂载，那整个升级链路从源头就断了。这类基础检查最好写进项目的checklist，别等到联调才发现。

提示：千万别在data分区挂载参数里动context=u:object_r:....这种强制打标配置，一旦固定了上下文，后续SELinux策略的调整空间会非常受限，升级目录的动态创建和文件操作会频繁撞avc denied。

3. OTA接口实现：常规路径与定制路径的取舍

3.1 接口应该长什么样

升级接口的核心职责是给上层一个"干净的、稳定的"触发入口，让应用或系统服务可以发起升级、查询状态、取消操作。Android原生已经提供了两套机制：一套是老的RecoverySystem方案，通过向/cache/recovery/command写入命令后重启进recovery；另一套是A/B分区设备的update_engine方案，通过binder接口直接与update_engine服务通信。

我在项目里遇到的情况比较典型：设备不是A/B分区，但又不愿意依赖cache分区（怕cache被清空或空间不足），所以走RecoverySystem的变体——把--update_package=@/data/upgrade/update.zip写入misc分区（bootloader message区域），再由系统重启进入recovery执行。这个方案不需要cache分区参与，对recovery的改动也更小。

3.2 接入RecoverySystem的实现细节

Framework层的调用方式如下：

public class OtaSystemApi { private static final String COMMAND_PATH = "/misc/ota/command"; public static void installPackage(Context context, File packageFile) throws IOException { // 确保升级包存在且路径合法 if (!packageFile.exists() || !packageFile.canRead()) { throw new IOException("ota package not readable"); } // 调用原生RecoverySystem，它会写misc分区并触发重启 RecoverySystem.installPackage(context, packageFile); } public static int queryOtaStatus() { // 读取属性，由recovery或服务写入 return SystemProperties.getInt("persist.sys.ota.status", -1); } }

如果使用原生的RecoverySystem.installPackage，系统会在内部完成命令写入、权限校验、重启触发等工作。但如果像我上面说的，想给上层暴露一个简洁的queryOtaStatus，就还得在recovery执行阶段把升级进度同步到一个persist属性里，recovery完成后由系统服务负责更新这个属性。这里踩过的一个坑是：persist属性在恢复出厂设置时会被清掉，如果你的业务逻辑依赖升级后属性值来做"本次升级是否成功"的判断，就要小心恢复出厂导致的丢失问题。

3.3 自定义接口服务的注册与对外暴露

对于复杂业务场景，我建议做一个独立的系统服务，注册到ServiceManager里，提供AIDL接口。业务代码集中在服务内部，上层应用只面向AIDL接口编程。这样做的好处是，后续不管是增加并发升级控制、升级包合法性校验还是升级回调通知，改动都收敛在服务内部，不会牵连系统其它组件。

public class OtaManagerService extends IOtaManager.Stub { @Override public boolean installPackage(String packagePath, boolean wipeData) { // 校验升级包存在 File pkg = new File(packagePath); if (!pkg.isFile()) return false; // 写入属性，标记升级状态 SystemProperties.set("persist.sys.ota.status", "installing"); // 触发RecoverySystem RecoverySystem.installPackage(mContext, pkg); return true; } }

注册的时候注意，系统服务需要放对位置。如果是AOSP源码环境，在SystemServer的startOtherServices里加上ServiceManager.addService("ota_manager", new OtaManagerService(context))；如果是系统App + 持久进程的方案，就要用binder机制自己管理。这个选择没有对错，取决于整个系统的服务治理风格。

3.4 升级状态回传的各种坑

状态回传是最容易被忽视的环节。升级包写入后，系统重启进入recovery，此时升级是否进行、成功还是失败，上层应用是不知道的。常规做法是recovery执行完成后写一个结果文件到/data/upgrade/result.txt或/cache/recovery/last_ota，系统重启后由常驻服务读取并上报。我实际项目里就吃过亏：recovery写文件时用的SELinux上下文和系统启动后服务读取时的上下文不一致，导致属性或文件读写被拒，最后结果没读到，上层以为升级失败。

另一个实践细节是升级状态标志物的放置位置。我建议标志位放两个地方：recovery能写、系统能读的地方放一份（比如/data/upgrade/ota_status），系统属性放一份（persist.sys.ota.status），两者配合用来区分"升级进行中"和"升级已完成"。只有属性而没有文件的话，PowerManager引起异常重启时会丢失判断依据。

4. SELinux授权：给升级链路发"通行证"的正确姿势

4.1 SELinux三大件速览

拿到SELinux授权这个任务时，第一步永远是搞清楚三件事：进程的domain是什么，要访问的目标type是什么，允许的操作class有哪些。OTA链路涉及的进程主要有recovery、setup_ota_dir脚本进程、以及系统服务；目标则是我们刚创建的/data/upgrade目录及其下的文件，以及recovery模式下需要访问的misc分区设备节点。

SELinux工作流一句话概括：进程运行在某个domain里，对某个type的对象发起某类操作，由policy规则决定是否放行。比如我们的setup_ota_dir服务运行在u:r:ota_setup:s0，访问目录/data/upgrade（type为ota_package_dir）的dirclass，需要allow ota_setup ota_package_dir:dir rw_dir_perms。

4.2 为upgrade目录和接口定义专用type

行业实践里最稳妥的做法不是让进程直接访问通用的data_filetype，而是自定义一个专用type：ota_package_dir。好处是授权边界清晰，以后哪怕recovery域被攻破，它影响的也只是OTA目录，而不是整个data分区。定义一个type要做三件事：

在file_contexts里给目录打标签：

/data/upgrade(/.*)? u:object_r:ota_package_dir:s0

在SELinux policy里声明type并绑定属性：

type ota_package_dir, file_type, data_file_type, mlstrustedobject;

然后才是授权规则。recovery域和system域对目录的访问规则长这样：

# recovery需要进入到/data/upgrade目录，读取升级包文件 allow recovery ota_package_dir:dir search; allow recovery ota_package_dir:file read open getattr; # 系统服务需要写入升级包、读取状态文件 allow system_server ota_package_dir:dir rw_dir_perms; allow system_server ota_package_dir:file create_file_perms; allow system_server ota_package_dir:file read; # 初始化进程负责在开机时创建目录 allow init ota_package_dir:dir create;

如果你走的是A/B分区方案，update_engine进程也要分到allow update_engine ota_package_dir:file read;这类权限。

4.3 property_service权限的边界

接口实现引出SELinux里最容易出问题的另一个对象：属性。OTA服务要读写的属性（如persist.sys.ota.status）也受SELinux管控。系统里system_property的set权限有一套默认约束，新增属性如果没有配套定义，service运行时就会在logcat里看到avc: denied { set } for property=persist.sys.ota.status。

做法是在property_contexts里声明属性上下文，然后给对应domain授权：

persist.sys.ota. u:object_r:ota_prop:s0

授权规则：

type ota_prop, property_type; allow system_server ota_prop:property_service set;

4.4 快速定位"谁缺权限"的调试三板斧

联调阶段遇到avc denied概率极高。我排查权限的顺序是固定的：先看dmesg，再看logcat，最后用audit2allow辅助生成。

• adb shell dmesg | grep "avc: denied"直接命中，或者adb logcat -b events | grep avc
• 标准格式：avc: denied { read } for pid=xxxx comm="update_engine" name="update.zip" dev="sda22" ino=xxxx scontext=u:r:update_engine:s0 tcontext=u:object_r:ota_package_dir:s0 tclass=file
• 从scontext和tcontext就能确定需要加规则的两个主角。例如这条日志出现后，我就知道update_engine访问升级包文件时读权限缺失，直接补allow update_engine ota_package_dir:file read;

注意调试时不要图省事直接把permissive域打开，全局宽松模式会掩盖掉所有权限问题，线上环境绝不允许这么干。可以用adb shell setenforce 0做临时粗排，但定位具体domain后立刻恢复。

5. 实操全流程：从需求到验证的一次完整走通

5.1 事前检查：五件必须确认的事

动手前我习惯先跑一遍环境检查，避免中途返工：

1. data分区挂载状态：adb shell mount | grep /data，确认不是ro。
2. SELinux当前模式：getenforce，是Enforcing还是Permissive。
3. Recovery模式对data分区的访问能力：直接进recovery后能否看到/data下的目录结构。
4. 升级包格式：是full OTA还是增量包，路径、文件名有没有硬编码。
5. misc分区是否可写：确认By-name/misc符号链接存在，且recovery能用。

5.2 目录与策略部署

第一步，代码仓库里新增file_contexts片段：

/data/upgrade(/.*)? u:object_r:ota_package_dir:s0

第二步，新增SELinux policy文件ota.te：

type ota_package_dir, file_type, data_file_type; type ota_prop, property_type; allow system_server ota_package_dir:dir create_dir_perms; allow system_server ota_package_dir:file create_file_perms; allow system_server ota_package_dir:file rw_file_perms; allow recovery ota_package_dir:dir search; allow recovery ota_package_dir:file rw_file_perms; allow system_server ota_prop:property_service set; allow recovery ota_prop:property_service set;

第三步，init rc脚本中加上setup_ota_dir服务。第四步，编译系统，烧录验证。

5.3 接口联调清单

接口联调阶段我一般按顺序验证几个点：

• 调用接口能否在/data/upgrade下生成文件（验证写权限与SELinux放行）
• 重启进入recovery后recovery能否读取升级包（验证recovery域策略）
• 升级完成后属性是否置为成功（验证属性读写）
• 恢复出厂后行为是否正常（验证状态丢失场景的兜底逻辑）

下表是我常用的一张自测验证清单，贴在工位旁边非常管用：

5.4 回归与交付

最后一步做的事情是回归验证。重点不是"能升一次"，而是"连续升级三次都稳定"。我实际跑过的一个案例里，第一次升级成功，第二次升级时发现上次升级的残留文件没清理干净，导致recovery解压时空间不足。这个坑在开发环境不容易暴露，因为开发机data分区基本没数据，线上用户设备则是杀机四伏。

所以交付前我会强制加上升级完成后的自动清理逻辑：success或者failed状态都触发清理/data/upgrade下已消费的升级包，只保留状态记录。这样第二次升级时目录是干净的，不会积累垃圾文件。

6. 我的排查笔记：那些年踩过的升级坑

6.1 升级包在Revoery下消失不见

现象：系统侧调用接口成功，升级包确认写入/data/upgrade，但重启进recovery后目录里空空如也。第一次遇到时我怀疑是目录被清，排查半天发现真相是recovery模式下data分区处于加密锁状态，目录结构能看到但文件内容访问失败，看起来就像不存在。

解决方案：确认upgrade目录不在用户CE加密空间内，recovery引导流程里加上对DE空间的解锁判断。具体做法查看设备是否配置ro.crypto.state=encrypted，若是则确保/data/upgrade归属DE目录体系。

6.2 avc denied疯狂刷屏

现象：日志里大量avc: denied { write }指向ota_package_dir，但SELinux规则看起来已经加上了。查到最后发现问题是recovery域和system_server域用了同一个目录，而我只给其中一个域授权。这是典型的"规则加了但没加对对象"的问题，不是权限不足，是权限给错了进程。

解法：把dmesg里的scontext一根根理出来，列个进程清单，逐个核对策略规则，别偷懒一张allow通用到底。经验是多域访问同一目录时，宁可写三条精确规则，也不要图省事把这两个域合并。

6.3 升级成功但status属性为unknown

现象：recovery升级成功，重启后系统服务读到的状态是unknown，上层误判升级失败。原因是我recovery写结果文件和系统服务读属性之间存在启动顺序竞争，服务起来时recovery的结果还没写到属性位置。

解法：在系统服务启动时增加等待重试逻辑，循环读取属性，超时置为failed。同时把recovery写结果的时机提前到完成刷写后的第一个可执行点，而不是等整个recovery流程走完。

6.4 升级包被安全软件"顺手清理"

现象：用户反馈升级总失败，排查发现系统自带的"存储空间清理"工具把/data/upgrade下的zip当成垃圾文件给删了。

解法：在清理工具的排除名单里加入/data/upgrade目录，或者在目录里放一个.nomedia标志文件阻止媒体扫描，双管齐下。这个坑不在SELinux也不在OTA逻辑，纯粹是团队协作信息不同步导致。

收尾的实操心得

这套链路做下来，我最深的体会是：OTA升级功能从来不是"写个接口点一下就完事"的活，从分区上开一个目录，到SELinux策略逐条放行，再到接口服务的稳定暴露，每个环节都在跟系统既有保护机制博弈。尤其SELinux这块，宁可多花时间设计好精细的type和domain划分，也不要图省事放开大范围权限，线上安全翻车一次的成本远超开发期那点时间投入。

最后分享一个小技巧：整个链路联调时，别只盯着功能成功路径，刻意制造几次异常场景——升级中断电、目录空间不足、升级包半写状态。把异常路径的log打完整，状态流转设计清晰，交付出去的系统才扛得住真实用户环境里千奇百怪的情况。做系统底层开发的，往往就是这些"用户永远碰不到、但线上偶尔炸一下"的细节，才真正决定一个定制项目的口碑。