这篇文章主要记录我自己给一加 Ace 6T Root 的完整过程，方便以后回顾。
不同系统版本、不同 OTA、不同槽位的情况可能不同，请不要无脑照抄分区和镜像。
解锁 Bootloader 会清除手机数据。刷错 boot / init_boot / vbmeta 等关键分区可能导致无法启动。
我的设备环境
这次操作的设备：
1 | 设备：OnePlus Ace 6T |
最终结果：
1 | Bootloader：已解锁 |
一、准备 ADB 和 Fastboot
我先在电脑上下载了 Android Platform Tools。
目录：
1 | C:\Users\Administrator\Desktop\boot\adb\platform-tools |
里面包括：
1 | adb.exe |
然后将整个 platform-tools 路径添加到 Windows 的 Path 环境变量。
配置完成后验证：
1 | adb version |
得到：
1 | Android Debug Bridge version 1.0.41 |
继续：
1 | fastboot --version |
得到：
1 | fastboot version 37.0.1-15733141 |
说明 ADB 和 Fastboot 命令都已经可以全局使用。
二、确认 ADB 连接
手机打开：
1 | 开发者选项 |
连接电脑后执行：
1 | adb devices |
成功识别：
1 | List of devices attached |
公开发博客时，建议把真实设备序列号打码。
三、进入一加深度测试
我之前已经提交了一加 Ace 6T 的深度测试申请，并成功获得资格。
深度测试 App 中最开始显示：
1 | 设备状态：未解锁 |
获得资格后点击：
1 | 开始深度测试 |
手机自动进入 Bootloader / Fastboot。
此时屏幕显示：
1 | FastBoot Mode |
其中最关键的是：
1 | DEVICE STATE - locked |
说明虽然已经获得深度测试资格，但是 Bootloader 此时仍然没有真正解锁。
四、解决 Windows Fastboot 驱动问题
这里是我实际遇到的第一个坑。
Android 正常开机时：
1 | adb devices |
可以正常识别。
但是进入 Fastboot 后执行：
1 | fastboot devices |
什么都没有。
执行：
1 | fastboot flashing unlock |
会一直停在：
1 | < waiting for any device > |
这并不是手机的问题，而是 Windows 没有正确加载 Fastboot 驱动。
我的解决办法
打开：
1 | 设备管理器 |
发现：
1 | 其他设备 |
然后下载 Google USB Driver。
解压以后找到：
1 | android_winusb.inf |
设备管理器中：
1 | Android |
选择：
1 | Android Bootloader Interface |
安装完成以后再次执行：
1 | fastboot devices |
终于成功：
1 | [设备序列号] fastboot |
这一步非常重要：
ADB 驱动正常，并不代表 Fastboot 驱动也正常。
五、正式解锁 Bootloader
确认 Fastboot 已经可以识别手机后执行：
1 | fastboot flashing unlock |
手机出现 Bootloader 解锁警告页面。
两个选项：
1 | DO NOT UNLOCK THE BOOTLOADER |
使用音量键选择：
1 | UNLOCK THE BOOTLOADER |
然后按电源键确认。
手机开始清除用户数据并恢复出厂设置。
完成以后重新进入系统。
六、验证 BL 是否真正解锁
重新开启 USB 调试以后执行：
1 | adb shell getprop ro.boot.flash.locked |
我的结果：
1 | 0 |
其中：
1 | 0 = Bootloader 已解锁 |
再次进入 Fastboot 页面后，也能直接看到：
1 | DEVICE STATE - unlocked |
说明 Bootloader 已经真正解锁成功。
七、提取原厂启动镜像
Root 之前我没有直接下载网上别人修补好的镜像，而是使用自己当前系统对应的完整 OTA。
我的版本是：
1 | PLR110_16.0.10.500(CN01) |
所以必须使用与这个版本完全对应的 OTA。
通过 PayloadDumper 从 payload.bin 中提取：
1 | boot.img |
我的原版镜像大小：
| 镜像 | 大小 |
|---|---|
| boot.img | 98,304 KB |
| init_boot.img | 8,192 KB |
| vendor_boot.img | 98,304 KB |
| vbmeta.img | 12 KB |
我专门创建了：
1 | boot\ |
stock 中的原厂镜像以后绝对不要覆盖。
八、安装 KernelSU Next
我最终选择的是：
1 | KernelSU Next |
而不是 Magisk。
安装：
1 | KernelSU Next v3.4.0 (33294-4) |
第一次打开时显示：
1 | 未安装 |
同时识别出了：
1 | 内核： |
说明 Manager 已经能够正常读取当前设备环境。
九、使用 KernelSU Next 修补 init_boot
我把原厂：
1 | init_boot.img |
复制到了手机：
1 | /storage/emulated/0/Download/init_boot.img |
它的大小是：
1 | 8.0 MB |
进入 KernelSU Next：
1 | 未安装 |
选择：
1 | 选择文件 |
然后选择：
1 | Download/init_boot.img |
高级选项中的：
1 | 始终授予 Shell root 权限 |
我都保持关闭。
开始修补以后，KernelSU Next 输出：
1 | Bootdevice: ... |
最后：
1 | Done! |
生成：
1 | kernelsu_next_patched_20261007_004330.img |
这个文件就是修补完成的 init_boot。
注意：
KernelSU Next 页面上的“刷写成功”在这里其实只是表示镜像修补成功，并没有真正写进手机分区。
十、把修补后的镜像复制回电脑
我把：
1 | kernelsu_next_patched_20261007_004330.img |
复制回：
1 | C:\Users\Administrator\Desktop\boot\patched |
然后为了方便输入命令，把名字改成：
1 | ksunext.img |
改文件名不会修改镜像内容。
最后：
1 | C:\Users\Administrator\Desktop\boot\patched\ksunext.img |
大小：
1 | 8,388,608 bytes |
也就是：
1 | 8 MiB / 8192 KB |
与原版 init_boot.img 大小一致。
十一、确认 A/B 槽位
刷入之前重新进入 Fastboot：
1 | adb reboot bootloader |
确认设备：
1 | fastboot devices |
然后查询当前槽位：
1 | fastboot getvar current-slot |
我的结果：
1 | current-slot: b |
说明手机当前使用：
1 | Slot B |
我又尝试查询：
1 | fastboot getvar has-slot:init_boot |
结果：
1 | FAILED (remote: 'GetVar Variable Not found') |
一开始看起来像是 init_boot 没有 A/B 分区，但实际上只是这个 Bootloader 没有实现这个查询变量。
于是继续检查：
1 | fastboot getvar partition-size:init_boot_b |
结果：
1 | partition-size:init_boot_b: 0x800000 |
再检查：
1 | fastboot getvar partition-size:init_boot_a |
同样：
1 | partition-size:init_boot_a: 0x800000 |
0x800000 就是：
1 | 8 MiB |
与我的原厂 init_boot.img 完全对应。
因此最终确认：
1 | init_boot_a：存在 |
十二、正式刷入 KernelSU Next
进入修补镜像目录：
1 | cd /d C:\Users\Administrator\Desktop\boot\patched |
确认：
1 | dir ksunext.img |
输出：
1 | 8,388,608 ksunext.img |
因为我的当前槽位是：
1 | b |
所以我明确刷入：
1 | fastboot flash init_boot_b ksunext.img |
最终输出：
1 | Sending 'init_boot_b' (8192 KB) OKAY |
看到：
1 | Sending ... OKAY |
说明真正刷写成功。
然后执行：
1 | fastboot reboot |
十三、第一次启动出现 Orange State
重启以后首先看到：
1 | Orange State |
这是正常的。
它表示：
1 | Bootloader 已解锁 |
并不是 KernelSU Next 刷坏了。
等待几秒以后，手机正常进入 ColorOS。
只要 Bootloader 保持解锁，以后开机仍有可能看到这个提示。
十四、KernelSU Next Root 成功
进入系统以后重新打开 KernelSU Next。
之前显示的是：
1 | 未安装 |
现在已经变成：
1 | 工作中 |
同时显示：
1 | Hook 模式： |
这意味着：
1 | KernelSU Next Manager ✅ |
至此 Root 成功。
十五、最终状态
我这次最终得到的环境：
1 | OnePlus Ace 6T |
整个过程中我没有修改：
1 | boot.img |
也没有执行：
1 | --disable-verity |
十六、如果 KernelSU Next 导致无法启动
因为我保留了完整原厂镜像，所以可以恢复。
我的原厂：
1 | C:\Users\Administrator\Desktop\boot\stock\init_boot.img |
由于当时活动槽是 B，如果修改后的 init_boot_b 无法启动，可以重新进入 Fastboot：
1 | fastboot flash init_boot_b "C:\Users\Administrator\Desktop\boot\stock\init_boot.img" |
然后：
1 | fastboot reboot |
即可把 B 槽的 init_boot 恢复为原厂版本。
十七、几个我这次踩到的坑
1. ADB 能识别，不代表 Fastboot 也能识别
正常系统：
1 | adb devices |
Fastboot：
1 | fastboot devices |
是两套不同状态。
我就是 ADB 一开始正常，但 Fastboot 完全识别不到，最后通过 Google USB Driver 的：
1 | Android Bootloader Interface |
解决。
2. has-slot:init_boot 报错不代表没有 A/B
我的：
1 | fastboot getvar has-slot:init_boot |
返回：
1 | Variable Not found |
但是：
1 | fastboot getvar partition-size:init_boot_a |
两个都能查询到：
1 | 0x800000 |
所以 init_boot_a 和 init_boot_b 实际都是存在的。
3. 不要照抄别人的槽位
我的：
1 | current-slot: b |
所以我刷：
1 | fastboot flash init_boot_b ksunext.img |
如果以后再次操作，一定重新查询：
1 | fastboot getvar current-slot |
如果显示：
1 | current-slot: a |
就不能继续照抄我的 init_boot_b。
4. Root 后不要直接真回锁 BL
现在我的 init_boot_b 已经不是原厂镜像。
因此绝对不能因为看到 Orange State 就直接执行：
1 | fastboot flashing lock |
真正的 Bootloader 回锁和所谓“伪回锁”完全不是一个概念。
修改启动链以后贸然真回锁，可能直接导致系统无法启动。
5. OTA 后不要继续使用旧 patched 镜像
我现在的：
1 | ksunext.img |
是基于：
1 | PLR110_16.0.10.500(CN01) |
对应的原厂 init_boot.img 修补得到的。
以后如果系统 OTA 升级：
1 | 旧版 init_boot |
应该重新从新版 OTA 中提取新版 init_boot.img，再使用 KernelSU Next 重新修补。
不要把旧版本的 ksunext.img 直接刷到新系统。
后记
这次 Root 实际上没有想象中那么复杂。
真正需要搞清楚的只有几个核心概念：
1 | Bootloader 解锁 |
相比直接下载别人做好的 Root 镜像，我还是更喜欢：
1 | 自己的 OTA |
至少以后出了问题，我知道自己到底修改了什么，也知道应该从哪里恢复。
这篇文章也就是为了把这次完整过程留下来。
等以后再折腾模块、Root 隐藏、SUSFS，以及 Ace 6T 的“伪回锁”时，再继续往下记录。
评论