告别‘Device or resource busy’：手把手教你用adb remount正确读写Android系统分区
在Android开发或系统定制过程中，修改系统分区几乎是必经之路。无论是替换系统应用、修改系统配置，还是进行深度定制，都需要对/system分区进行读写操作。然而，许多开发者第一次尝试挂载系统分区为可写时，往往会遇到令人困惑的"Device or resource busy"错误。这个看似简单的操作背后，隐藏着Android系统权限管理和挂载机制的复杂性。
本文将带你深入理解Android系统分区的挂载原理，剖析常见错误的根源，并提供一套经过实战验证的可靠操作流程。无论你是Android应用开发者想要深入系统层，还是ROM定制爱好者尝试修改系统文件，亦或是安全研究人员进行逆向分析，掌握这些技巧都能让你事半功倍。
1. 理解Android系统分区与挂载机制
Android基于Linux内核，继承了Linux的文件系统和挂载机制。系统启动时，init进程会根据fstab文件中的配置挂载各个分区。其中，/system分区通常被挂载为只读(ro)，这是出于系统安全和稳定性的考虑。
1.1 系统分区的特殊性
/system分区包含Android系统的核心组件：
- 系统应用(如SystemUI、Settings等)
- 框架库文件
- 系统二进制工具
- 预装应用和库
- 系统配置文件
由于这些文件在系统运行期间可能被多个进程使用，直接修改可能导致系统不稳定甚至崩溃。因此，Android设计为默认以只读方式挂载/system分区。
1.2 常见的挂载方式对比
在Android环境下，主要有两种方式可以重新挂载系统分区：
| 方法 | 命令示例 | 需要条件 | 适用场景 |
|---|---|---|---|
| adb remount | adb remount | 需要root权限，设备必须支持adb remount | 快速临时挂载，适合开发调试 |
| mount命令 | mount -o remount,rw /system | 需要root权限，需要知道设备节点 | 更灵活，适合各种定制场景 |
2. 解决"Device or resource busy"错误的实战指南
这个错误通常意味着系统分区正在被使用，无法重新挂载。下面是一套经过验证的解决流程。
2.1 准备工作
首先确保你的环境配置正确：
- 启用设备的USB调试模式
- 安装最新版ADB工具
- 使用高质量USB数据线连接设备
- 设备已解锁并获取root权限
2.2 分步解决方案
第一步：检查当前挂载状态
adb shell mount | grep /system典型输出类似：
/dev/block/bootdevice/by-name/system on /system type ext4 (ro,seclabel,relatime,data=ordered)第二步：尝试标准remount方法
adb root adb remount如果成功，你会看到remount succeeded的提示。
第三步：处理"Device or resource busy"错误
当标准方法失败时，可以尝试以下进阶方案：
调整参数顺序：
adb shell "mount -o remount,rw /system"与
adb shell "mount -o rw,remount /system"在某些设备上，参数顺序会影响结果。
指定完整设备路径：
adb shell "mount -o remount,rw /dev/block/bootdevice/by-name/system /system"卸载相关进程：
adb shell "stop" adb shell "start"这会重启Android框架，释放对/system分区的占用。
2.3 验证挂载结果
无论使用哪种方法，最后都应验证挂载是否成功：
adb shell mount | grep /system成功挂载为可写时，输出中应包含rw标志。
3. 深入理解remount的工作原理
要彻底解决这类问题，需要理解背后的机制。remount操作实际上是在不卸载文件系统的情况下改变其挂载参数。
3.1 Linux mount机制在Android上的实现
Android对标准Linux mount做了些修改和限制：
- 引入了SELinux安全上下文
- 默认启用dm-verity验证
- 对系统分区有特殊保护
3.2 参数顺序为何会影响结果
在mount命令中，-o后面的选项顺序有时很重要，因为：
- 内核处理挂载选项时可能有特定顺序要求
- 某些选项会互相影响
- Android的补丁可能修改了标准行为
例如，在某些内核版本中，必须先指定remount再指定rw，否则内核可能无法正确处理请求。
4. 高级技巧与注意事项
4.1 临时禁用SELinux
在某些严格限制的设备上，可能需要临时放宽SELinux策略：
adb shell "setenforce 0"完成操作后，建议恢复：
adb shell "setenforce 1"4.2 处理dm-verity保护
如果设备启用了dm-verity，即使成功remount，修改也可能在重启后被恢复。这时需要：
- 刷入禁用dm-verity的内核
- 或者修改vbmeta分区
4.3 自动化脚本示例
以下是一个健壮的remount脚本，包含了错误处理和回退机制：
#!/bin/bash function remount_system() { echo "尝试标准adb remount..." adb remount if [ $? -eq 0 ]; then echo "标准remount成功" return 0 fi echo "尝试mount命令方式..." adb shell "mount -o remount,rw /system" >/dev/null 2>&1 if [ $? -eq 0 ]; then echo "mount命令方式成功" return 0 fi echo "尝试指定设备节点..." device_path=$(adb shell "mount | grep ' /system ' | awk '{print \$1}'") if [ -n "$device_path" ]; then adb shell "mount -o remount,rw $device_path /system" if [ $? -eq 0 ]; then echo "通过设备节点remount成功" return 0 fi fi echo "所有方法尝试失败" return 1 } remount_system4.4 常见问题排查
Q: 为什么即使显示rw，我仍然无法修改某些文件？A: 这可能是因为：
- 文件系统权限限制
- SELinux策略阻止
- 文件被标记为不可变(chattr +i)
Q: remount后修改的文件在重启后消失了？A: 这可能是因为：
- 系统使用了overlayfs
- dm-verity恢复了原始文件
- 设备有A/B分区且切换了slot
5. 安全与稳定性考量
虽然remount系统分区功能强大，但也存在风险：
5.1 操作风险提示
修改系统分区可能导致设备无法启动，建议在操作前备份重要数据，并确保了解恢复方法。
5.2 最佳实践建议
- 尽量使用临时修改：修改后立即恢复只读状态
adb shell "mount -o remount,ro /system" - 避免直接修改：考虑使用Magisk模块等非破坏性方法
- 记录所有更改：便于出现问题时的排查和恢复
5.3 替代方案评估
根据你的具体需求，可能有更好的替代方案：
| 需求 | 推荐方案 | 优点 | 缺点 |
|---|---|---|---|
| 修改系统配置 | Magisk模块 | 可逆，不影响OTA | 需要解锁bootloader |
| 替换系统应用 | 系统化安装 | 无需修改/system | 可能占用用户空间 |
| 调试系统组件 | 使用adb overlay | 无需root | 功能有限 |
在实际项目中，我发现最稳妥的做法是先用模拟器测试所有系统修改，确认无误后再在真机上操作。特别是在处理厂商定制ROM时，不同厂商可能对系统分区有额外的保护措施。
