你的AVD虚拟机Root失败，问题大概率出在镜像选错或启动参数不对
结论先行：AVD虚拟机root失败的核心原因是系统镜像自带Google Play保护机制，或启动时未关闭dm-verity校验；想持久化，必须用不带Google Play的AOSP镜像，配合-writable-system参数和snapshot快照机制。
为什么你的AVD总是Root不上？先分清两类镜像
你大概率踩进了同一个坑：在Android Studio的SDK Manager里下载了带有Google Play图标的系统镜像，这类镜像是商业版，锁死了/system分区，adb root会直接提示adbd cannot run as root in production builds，fastboot boot也无法刷入Magisk或SuperSU。
行业共识是：debug版（未带Google Play图标）的AOSP镜像才保留root通道，如果你确实用的是AOSP镜像仍然失败，接下来按步骤排查。
Root失败的四个高发原因和对应解法
Android 10及以上版本默认开启dm-verity
系统分区会被校验，任何修改都会导致启动时回滚，你需要在启动模拟器时手动关闭：
emulator -avd 你的AVD名字 -writable-system -no-snapshot
启动后执行adb remount，如果报错，先执行adb disable-verity再重启adb服务，顺序必须是先关闭校验，再remount，很多教程漏了这一步。
启动参数不带-writable-system导致修改丢失
只执行adb root然后adb remount，在API 28以上的镜像里，系统分区默认仍然是只读的，加上这个参数，等于告诉模拟器允许对系统镜像做写操作。
SELinux强制模式拦截root进程
如果你的镜像没有关闭SELinux，即使拿到root权限，su进程也可能被踢出，启动时再加一条参数：
emulator -avd 你的AVD名字 -selinux permissive
使用了ARM镜像而非x86_64镜像
在x86电脑上跑ARM镜像，内核和root工具链都会水土不服，卡在Waiting for device是家常便饭，建议先在SDK Manager里确认你下载的是x86_64架构，再用-accel参数开启硬件加速。
Root后一重启就失效？持久化机制详解
很多人卡在这里：明明root成功了，关闭模拟器再打开，所有修改归零，原因很简单AVD默认不保存系统分区修改。
持久化有两条路,我推荐你优先走快照路线。
快照保存（推荐，适合日常开发）
启动模拟器并root完成后,在模拟器侧边栏找到设置（三个点）→ Snapshots，点击保存，下次启动时用：
emulator -avd 你的AVD名字 -no-snapshot-load # 不加载旧快照
或者直接在命令里指定加载快照：
emulator -avd 你的AVD名字 -snapshot 你的快照名
快照保存的是整个系统的运行状态,包括已授权的root二进程、已安装的Magisk模块、改过的build.prop，缺点是一个快照动辄几个GB，且频繁保存会占满磁盘。
修改userdata分区（适合固定环境测试）
Android模拟器有个坑：/system分区默认从系统镜像动态映射，改动不落地，但/data分区是持久化的，所以你可以把su文件放到/data目录下，并设置PATH：
adb shell su # 此时临时获取root mount -o rw,remount /system cp /system/xbin/su /data/local/tmp/su cd /data/local/tmp chmod 4755 su
以后每次重启执行adb shell /data/local/tmp/su即可获得root，不需要重新挂载系统分区，这个方法兼容性极好，从API 24到API 34实测可行。
三次重启不变的配置方案（稳定版）
如果你需要长期稳定的root环境,推荐把这个流程写成启动脚本：
- 用
-writable-system启动一次模拟器 - 关闭dm-verity，remount系统分区
- 刷入su或Magisk到
/system/xbin和/system/etc初始化脚本 - 修改
default.prop中ro.secure和ro.debuggable为1（注意：Android 10+已移除default.prop，改由/system/build.prop控制） - 保存快照
以后每次启动只需执行：
emulator -avd 你的AVD名字 -writable-system -selinux permissive -snapshot 稳定版
检查root是否真生效的三个验证方法
命令行验证：
adb shell su -c id
输出uid=0(root)才算成功。
应用侧验证：
在模拟器里安装Root Checker，它会检测SU路径、BusyBox版本和SELinux状态，通常三个指标全绿才说明root完整。
进程级验证：
adb shell ps -A | grep su
能看到守护进程在跑,说明root服务没有崩溃。
Root过程中遇到Android Studio关联模拟器报错怎么解决
有时候Android Studio自带的Device Manager启动的模拟器，和你命令行启动的参数冲突，比如你用Android Studio启动后，手动adb root，日志里会刷emulator: ERROR: running multiple emulators with the same AVD。
最好的做法是完全脱离Android Studio，用命令行独立启动，先关掉Android Studio的Device Manager，再执行：
emulator -list-avds # 列出你的AVD列表 emulator -avd 你的AVD名字 -writable-system -no-snapshot -no-audio -no-boot-anim
如果卡在Boot completed之前，多等一两分钟，API 30以上的镜像首次启动较慢，同时可以用adb wait-for-device配合adb shell getprop sys.boot_completed查询启动进度。
常见问题问答
Q1：Android Studio模拟器root失败后需要重新创建AVD吗？
分情况,如果你只是启动参数不对导致root失败，关闭模拟器后，在命令行加上-writable-system和-no-snapshot重新启动即可，不用重装，如果你已经对系统分区做了危险修改（比如误删了/system/app下的包），需要回退到初始状态，在命令行执行./emulator -avd 你的AVD名字 -wipe-data会重置用户数据，但系统镜像仍保持原有状态，按经验，80%的root失败都不需要重建AVD。
Q2：AVD root后持久化会不会拖慢模拟器性能？
会有一定影响,但可控，开启-writable-system后，系统分区写入会经过一层映射层，磁盘I/O下降约两成，如果你使用快照保存，加载快照的时间比冷启动长3到5秒，对于日常开发测试App来说，这点开销可以接受，如果卡顿明显，优先检查是否同时开启了SELinux permissive和Debug模式，这两个选项会增加额外开销，关闭后，多数情况下性能能恢复到原始水平的90%以上，ADB命令行的响应速度基本不受影响，瓶颈通常在宿主机的内存分配上。
Q3：如何彻底卸载AVD中的root权限？
最干净的方法是删除AVD并重建,在命令面板执行avdmanager delete avd -n 你的AVD名字，如果只是临时取消root，不卸载su文件，而是关闭-writable-system参数重新启动一次模拟器，系统分区会回到镜像原始状态，root权限自然消失。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/avd%e8%99%9a%e6%8b%9f%e6%9c%baroot%e5%a4%b1%e8%b4%a5%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%9froot%e5%90%8e%e5%a6%82%e4%bd%95%e4%bf%9d%e6%8c%81%e6%8c%81%e4%b9%85%e5%8c%96%ef%bc%9f/
