Shizuku 运行原理：app_process 服务进程与 binder 直连

先补一块背景：应用是怎么调用系统功能的

应用获取已安装列表时调用的 PackageManager，看起来只是本地函数，背后其实是一次进程间通信（IPC）：应用进程把请求发给系统服务进程（system server）里的 PackageManagerService，对方处理完再把结果传回来。

Android 承担这类通信的底层机制叫 binder。binder 有个关键特性：通信时系统服务能拿到对方的 uid 和 pid，从而校验调用者有没有权限。应用进程在启动时，就会收到一批系统服务的 binder——这是所有应用调系统 API 的必经之路。

Shizuku 在中间做了什么

Shizuku 的做法可以概括成「拉起一个中间人进程，再把通行证发出去」：

1. 拉起服务进程：用户通过 root、无线调试或电脑 adb 三种方式之一，以 shell（或 root）身份运行一个由 app_process 启动的 Java 进程，这就是 Shizuku 服务进程；
2. 分发 binder：应用启动时，Shizuku 服务进程会把指向自己的 binder 发送给应用进程；
3. 代理转发：应用拿着这个 binder 发请求，Shizuku 服务进程收到后，以自己更高的权限替它调用真正的系统服务，再把结果原路带回。

在源码层面，请求转发由 ShizukuService 的 transactRemote 方法完成，应用侧则通过 ShizukuBinderWrapper 把对系统服务的调用包一层、改道发往 Shizuku 服务进程。对应用来说，这个体验几乎与直接调用系统 API 没有区别。

为什么这套设计能绕开「必须 root」

关键在于权限来自谁。传统方案里应用自己执行 su，等于应用亲手要 root——门槛与风险都在应用侧。Shizuku 方案里，高权限属于那个由调试通道拉起的服务进程，应用只是与它通信的普通进程：它既没有、也不需要 root，自然不需要解锁系统。

代价则是权限的「时效性」：服务进程依附于调试机制，手机重启后进程消失，需要重新激活（重启后失效的完整解释）。root 模式因为权限不依赖 adb，可以做到开机自启。

对开发者的两点额外提示

官方开发者文档里有两条容易被忽略的边界，普通用户了解后也能解释一些「应用行为异常」：

• adb 权限本身有限：不同系统版本给 shell 用户的权限清单不同，应用可以在调用前用 getUid 之类的方法判断当前是 adb 模式还是 root 模式，再决定能做哪些操作；
• 隐藏 API 限制：Android 9 起普通应用调用隐藏 API 受限，接入方需要借助额外的兼容手段，这也是少数应用「明明授权了还是报错」的原因之一。

原理看明白了，下一步可以对比一下 Shizuku 与传统 root shell 的差别，或者直接进入 启动方式的选择。