一、实测设备与问题表现#

原来的现象可以稳定复现：连接电脑启动成功，拔掉 USB，Shizuku 变成未运行；重新接线后，电脑上也查不到原来的 shizuku_server 进程。

这次没有通过 root、冻结系统服务或者循环重启脚本来解决。手机上另有 Dhizuku，但本次有效步骤使用的是 ADB，未调用 Dhizuku 的所有者权限。

二、先检查常规设置#

如果只是偶尔停止，建议先排查后台限制、USB 调试是否被关掉，以及 USB 模式切换。Shizuku 官方手册也列出了允许后台运行、保留开发者选项和 USB 调试、使用仅充电模式等建议。华为 EMUI 的建议还包括允许仅充电模式下的 ADB 调试；荣耀是否有同名选项，以实际系统界面为准。Shizuku 官方手册

我这台手机已经加入了电池优化白名单，USB 调试和开发者选项也处于开启状态。尝试通过 svc usb 命令切换 USB 模式时，命令没有报错，但实际 USB 配置没有改变，因此不能把这一步记作“成功改成仅充电”。

如果你的手机通过上述设置就能解决问题，可以继续使用原来的启动方式。

三、为什么没有只给启动命令加 nohup#

为了区分“首页显示异常”和“服务真的退出”，排查时另外运行了一个有限时长的记录脚本。它使用 setsid 和 nohup 脱离终端，每秒记录一次 Shizuku 进程与 ADB 状态。

原模式下拔线后，Shizuku 进程消失，这个已经脱离终端的记录脚本也同时终止。重新接线后，ADB 服务的进程编号发生了变化。

这些现象让我怀疑问题与 USB 断开时的 ADB 服务处理有关，而不只是 Shizuku 管理界面被后台清理。这属于根据现象作出的推断，没有定位到荣耀系统内部具体哪一段代码。

另外，Shizuku 13.6 的启动器本身已经使用了 fork()、setsid()，并把标准输入输出转向 /dev/null。所以，单纯再包一层 nohup，不能保证它绕过系统对相关进程的清理。Shizuku 13.6 启动器源码

四、有效操作：切换 TCP 模式，再启动 Shizuku#

下面以 Windows PowerShell 为例。请使用 Google 官方 Platform-Tools，在解压后的 platform-tools 文件夹里打开 PowerShell。

1
.\adb.exe devices -l

1
$phoneSerial = '这里替换成自己的设备序列号'
2
.\adb.exe -s $phoneSerial shell getprop ro.product.model
3
.\adb.exe -s $phoneSerial shell getprop ro.adb.secure

1
.\adb.exe -s $phoneSerial shell getprop service.adb.tcp.port
2
.\adb.exe -s $phoneSerial shell getprop persist.adb.tcp.port

1
.\adb.exe -s $phoneSerial tcpip 5555

1
restarting in TCP mode port: 5555

1
Start-Sleep -Seconds 3
2
.\adb.exe devices -l
3
.\adb.exe -s $phoneSerial shell getprop service.adb.tcp.port

1
$apkOutput = @(.\adb.exe -s $phoneSerial shell pm path moe.shizuku.privileged.api)
2
if ($LASTEXITCODE -ne 0) { throw '无法查询 Shizuku 安装路径' }
3

4
$baseApks = @($apkOutput | Where-Object {
5
 $_ -match '^package:/data/app/[A-Za-z0-9/._~+=-]+/base\.apk$'
6
})
7
if ($baseApks.Count -ne 1) { throw '未找到唯一的 Shizuku base.apk，请使用应用提供的命令' }
8

9
$apkPath = $baseApks[0].Substring('package:'.Length)
10
$starterPath = $apkPath.Substring(0, $apkPath.Length - '/base.apk'.Length) + '/lib/arm64/libshizuku.so'
11

12
.\adb.exe -s $phoneSerial shell ls -l $starterPath
13
if ($LASTEXITCODE -ne 0) { throw '未找到 ARM64 启动器，请使用应用提供的命令' }
14

15
.\adb.exe -s $phoneSerial shell $starterPath
16
if ($LASTEXITCODE -ne 0) { throw 'Shizuku 启动失败，请检查输出' }

五、怎么验证它真的没有掉#

拔线之前，记录服务进程编号：

1
.\adb.exe -s $phoneSerial shell pidof shizuku_server
2
.\adb.exe -s $phoneSerial shell pidof adbd

保持 Shizuku 页面打开，拔掉 USB，等待约 20 秒，看首页是否仍显示正在运行。然后重新接回电脑，不要手动停止或启动 Shizuku，再执行上面两条命令。

本次结果：

另一个有限时长记录脚本也在拔线期间持续记录，约 96 秒的记录窗口内，Shizuku 的 PID 一直是 21746。相比只看首页文字，这些结果进一步支持服务没有中断，也没有在接线后偷偷重新启动。

本次验证覆盖了拔线与接回过程，未进行数小时锁屏、长期待机或重启后的存活测试。 也没有验证换网络、关闭 Wi-Fi 等其他场景。遇到这些情况，请分别测试，不能直接从本次结果推导。

六、手机重启后怎么办#

本次没有设置开机脚本，也没有修改持久化 TCP 属性。按照这个方案使用时，手机重启后应重新连接电脑，检查设备和授权状态，执行 tcpip 5555，再启动 Shizuku。

Shizuku 13.6 另有 Android 13 及以上、连接受信任 WLAN 时免 root 自动启动的功能，但本次没有配置或验证，不能把它算作这套方案的效果。Shizuku 13.6 发布说明

这里获得的是 ADB 的 shell 权限，没有给手机 root，也没有让 Shizuku 获得跨重启永久运行能力。

七、网络调试端口与撤销方法#

这个方法的代价是开启 TCP 5555 上的网络 ADB。Android 14 的 ADB 实现会根据 TCP 端口配置建立网络监听；因此不要把它理解成“只有手机本机能连接”的模式。AOSP Android 14 ADB 实现

本次设备的 ro.adb.secure=1，保留了 ADB 认证。对于自己信任、已获授权的电脑，仍应妥善管理调试授权；认证存在也不代表开启调试端口就完全没有风险。

• 尽量在可信网络上使用，不要把 5555 端口映射到公网。
• 不要授权陌生电脑；只有自己的可信电脑才考虑勾选长期授权。
• 不需要网络调试时，可以恢复 USB 模式。

本次原来没有自定义 TCP 设置。要撤销这次模式切换，接回 USB，确认连接正常后执行：

1
.\adb.exe -s $phoneSerial usb
2
Start-Sleep -Seconds 3
3
.\adb.exe devices -l
4
.\adb.exe -s $phoneSerial shell getprop service.adb.tcp.port

正常会显示正在重启到 USB 模式。随后 TCP 端口属性应不再是 5555，常见值为 0。如果仍是 5555，撤销没有按预期完成，需要继续检查。

恢复 USB 模式会重启 ADB 服务，Shizuku 也可能退出。需要继续使用时，可以按原来的电脑方式重新启动，但本机原先“拔线就掉”的现象可能再次出现。

本次实际测试的是切换到 TCP 模式并验证拔线存活；上述恢复命令是 ADB 提供的标准撤销方式，尚未在本次成功配置上执行撤销测试。

八、遇到失败时先看这几项#