没有无线调试的华为手机，Shizuku 照样保活！——一次踩坑探索实录
上一篇《彻底解决华为手机 Shizuku 一拔数据线就掉线问题》讲了「无线调试」这套最优解。
但很多朋友实测反馈：我的开发者选项里根本搜不到「无线调试」！
别慌，这篇文章就是为你写的。这次不用最优解，硬是在「没有无线调试」的老机型上，把 Shizuku 给保活了。全程记录我的踩坑过程，包括翻车的那一步 👇
一、先说结论（急着用的看这里）
核心思路一句话：
让 adbd（手机上的调试守护进程）从 USB「搬家」到 TCP，然后在拔线之后再启动 Shizuku。
# ① USB 连着电脑时，执行一次（每重启一次手机需要重做）：
adb tcpip 5555
# ② 拔掉数据线！先拔线！
# ③ 通过 WiFi 连接并启动 Shizuku：
adb connect 192.168.0.102:5555
adb -s 192.168.0.102:5555 shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
# ④ 验证进程存在：
adb -s 192.168.0.102:5555 shell "ps -A | grep shizuku"
为什么顺序这么重要？这是我翻车一次才搞明白的，后面细说。
二、探索起点：老办法为什么救不了我的手机
先把问题摆出来：
- Shizuku 用
adb shell sh .../start.sh启动，一切正常 ✅ - 数据线一拔——当场去世 ❌
上一篇的解法是「无线调试」，但我这次的测试机（华为老旗舰，EMUI/HarmonyOS，Android 10 底层）：
- 开发者选项翻遍了 ❌
- 设置里搜索「无线调试」——没有这个选项 ❌
原因很简单：「无线调试」是 Android 11 才引入的功能，底层还是 Android 10 的老机型，压根没有这个东西。上一篇的最优解直接失效。
那怎么办？总不能每次用 Shizuku 都插着线吧？
三、走过的弯路：MT 管理器的 shell 行不行？
我的第一反应：手机上装个带终端的工具，直接在手机本地跑 start.sh 不就完了？
于是我装了 MT 管理器（自带 shell 终端），结果——不行。
踩坑分析（这部分是原理，看懂了能少走很多弯路）：
-
MT 终端跑的是 MT 自己的应用身份（
u0_a开头的普通应用 uid）
而 Shizuku 必须以 shell（uid 2000） 或 root（uid 0） 身份运行才有特权。你在 MT 终端里跑start.sh，拉起的进程是 MT 的子进程，权限跟 MT 一样只是个普通应用，Shizuku 服务端直接拒绝工作。 -
Android 10+ 还有 W^X 限制
应用无法执行放进自己目录的自定义二进制，想给 MT 塞一个 adb 工具？没门。
📌 一句话总结这个弯路：MT 管理器的定位是「使用已运行的 Shizuku」，不是「启动 Shizuku」。
类比一下：MT 是个持有普通门禁卡的访客，而 Shizuku 需要的是保安（shell 用户）从保安室（adb 通道）里请出来。访客自己在门口喊一嗓子，是喊不出一个保安的。
四、关键思路转变：让 adbd「搬家」
回到问题本质。上一篇说过：
USB 启动的 Shizuku 进程，挂在 adbd 会话下。华为在 USB 断开时会终止相关 ADB 会话，顺手清杀 shell 用户的进程。
注意这句里的关键词：USB 断开。
那如果把 adbd 从 USB 挪到 TCP 上呢？ADB 有个官方功能：
adb tcpip 5555
执行后，adbd 会监听 TCP 5555 端口，不再依赖 USB。此时拔掉数据线：
- adbd 还活着（走 WiFi/TCP）✅
adb devices里 WiFi 地址还在 ✅
看起来完美？我一开始也是这么以为的，然后翻车了 👇
五、翻车实录：按新方案做了，还是死了！
我的第一次操作顺序：
# ① USB 连着，开启 tcpip
adb tcpip 5555
# ② 此时 USB 和 WiFi 两个连接都在：
# 2KE0219C04022878 device
# 192.168.0.102:5555 device
# ③ 通过 WiFi 启动 Shizuku
adb -s 192.168.0.102:5555 shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
# 输出：
# info: start.sh begin
# info: starting server...
# info: shizuku_starter exit with 0
# ④ 验证，进程确实在：
# shell 21071 1 ... S shizuku_server ← shell 用户身份，父进程是 init（已完美守护化）
# ⑤ 拔线
# ⑥ 再看 —— Shizuku 还是死了 ❌
adbd 明明活着，Shizuku 为什么还是被杀了？
反复对比后我才想明白：
华为的清杀动作，不是「adbd 死了才杀进程」，而是 「拔线这个物理事件发生的瞬间，清杀 shell 用户的进程」。不管你的 Shizuku 是从 USB 会话还是 WiFi 会话启动的，只要拔线那一刻它活着，就会被顺手带走。
这就好比公司保安规定：下班打卡那一刻，清空所有访客。你访客是从正门还是侧门进来的根本不重要，卡点在场就是被清。
六、正确姿势：先拔线，后启动
想通了这一点，解法就简单得有点好笑：
拔线事件已经发生了，之后再启动的 Shizuku，就不会再遇到下一次拔线。
修正后的完整流程：
# ① USB 连着电脑，执行一次（让 adbd 搬家到 TCP）：
adb tcpip 5555
# ② 立刻拔掉数据线！
# ③ 此时 USB 已不在，纯 WiFi 连接：
adb connect 192.168.0.102:5555
# ④ 拔线之后再启动 Shizuku：
adb -s 192.168.0.102:5555 shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
# ⑤ 验证：
adb -s 192.168.0.102:5555 shell "ps -A | grep shizuku"
启动成功的标志（ps 输出长这样）：
shell 21071 1 5237184 146152 ... S shizuku_server
重点看两处：
shell开头 → 身份正确（uid 2000），权限没问题- 父进程是
1（init）→ 已脱离 adb 会话，完美守护化
之后正常用手机、锁屏、熄屏，每隔一段时间查一次 ps，观察它是否还活着。
七、如果它过一会儿还是死了：两条兜底路
兜底 1：禁用华为的进程清杀引擎（慎用）
华为系统里有个叫 iAware 的后台管控组件，负责激进清杀后台进程。可以试着禁用它：
adb -s 192.168.0.102:5555 shell pm disable-user --user 0 com.huawei.iaware
⚠️ 注意：
- 部分系统版本会拒绝禁用，试了才知道
- 副作用是可能略耗电、后台更热闹
- 随时可恢复：
adb shell pm enable com.huawei.iaware
兜底 2：Termux 手机自启动（强烈推荐装上）
就算 Shizuku 偶尔断掉，只要 adbd 还在 tcpip 模式（重启手机前一直有效），你可以在手机上自己把它拉起来，全程不用碰电脑：
资源连接需要自取—————–
链接：https://pan.quark.cn/s/88877a8f2249?pwd=6A8D 提取码：6A8D
- 安装 Termux（F-Droid 版，Google Play 版已停更且受限）
- 安装 adb 工具：
pkg install android-tools
- 手机自连、启动：
adb connect 127.0.0.1:5555
adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
整个过程不到一分钟，Shizuku 断了随时自己续。
📌 Termux 能干而 MT 不能的原因：Termux（F-Droid 版）targetSdk 低，不受 Android 10+ 的 W^X 执行限制，能跑 adb 二进制；而且它是通过 adb 通道以 shell 用户身份启动 Shizuku，不是用自己的应用身份硬来。
八、别忘了：保活三件套 + 重启后的恢复流程
保活三件套（上一篇详细讲过，这里列清单）
- ✅ 应用启动管理：Shizuku 关「自动管理」，手动允许自启动 / 后台活动 / 关联启动
- ✅ 电池优化：Shizuku 设为「不允许优化」
- ✅ 多任务界面下拉 Shizuku 卡片，加锁 🔒
这套是对 Shizuku 应用进程的保险；而 shell 用户的 shizuku_server 进程能不能活，靠的是本文的 tcpip 方案。两套保险叠加。
重启后的恢复流程（绕不开的一步）
tcpip 模式有个硬限制：手机一重启，adbd 自动回到 USB 模式，之前设置的 5555 端口清零。
所以每次重启手机后：
- 插一次数据线
- 跑一遍
adb tcpip 5555→ 拔线 →adb connect→start.sh - 之后又是一条好汉
嫌麻烦可以写个一键 bat 把这四步串起来，插线跑一下就完事：
adb tcpip 5555
timeout /t 2
adb connect 192.168.0.102:5555
adb -s 192.168.0.102:5555 shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
adb -s 192.168.0.102:5555 shell "ps -A | grep shizuku"
pause
九、常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 拔线后 Shizuku 死了 | 先启动、后拔线（顺序错了） | 先拔线，再通过 WiFi 启动 |
拔线后 adb connect 失败 | 忘了先执行 adb tcpip 5555 | 插线执行一次再拔 |
| 重启后连不上 5555 | tcpip 模式随重启失效 | 正常现象，插线重跑一遍 |
| MT 管理器/终端里跑 start.sh 无效 | 应用 uid 没有特权 | 必须走 adb 通道（shell 用户） |
| Shizuku 活一会儿被杀 | iAware 周期清杀 | 见兜底 1 / 完成保活三件套 |
| 想完全脱离电脑 | — | Termux 自连方案（兜底 2） |
十、总结：这次探索学到了什么
回顾整个探索路径：
拔线必死
→ 没有无线调试，上一篇方案失效
→ 弯路：MT 管理器 shell（应用 uid，没特权，Pass）
→ 思路转变：adb tcpip 5555，让 adbd 搬家
→ 翻车：先启动后拔线，照样死
→ 顿悟：清杀发生在「拔线瞬间」，与启动通道无关
→ 正解：先拔线，后启动 ✅
→ 兜底：iAware 禁用 + Termux 手机自启
两篇文章合在一起，覆盖了华为 Shizuku 保活的两类机型：
| 机型 | 方案 | 重启后 |
|---|---|---|
| 有无线调试（Android 11+） | 上一篇：无线调试启动 | 手机端一键重启，最省心 |
| 没有无线调试（本篇） | tcpip 搬家 + 先拔后启 | 需插线跑一遍 bat |
📌 一句话总结：
没有无线调试不可怕，可怕的是没搞清华为「拔线清杀」的触发时机。把 adbd 搬到 TCP 上，再把启动顺序调对，老机型一样能保活。
本篇是《华为 Shizuku 保活》系列第二篇，第一篇：彻底解决华为手机 Shizuku 一拔数据线就掉线问题
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2501_90379366/article/details/166494434
