应用开发者如何接入 Shizuku：API 与迁移要点

为什么值得接入

官方首页对开发者的许诺直白：如果你的「需要 root 的应用」其实只需要 adb 权限，接入 Shizuku 就能扩大用户群体——未 root 用户装个 Shizuku 就能用上完整功能。官方还替你解决了最大的负担：详细的用户文档现成，你只需引导用户安装 Shizuku。

API 与工程入口

• Shizuku-API：官方独立仓库，提供完整的 API、示例与文档，是接入工作的起点；
• 示例代码：仓库内的示例应用覆盖了权限请求、服务检查等标准动作；
• 迁移指南：仓库文档里有专门面向 pre-v11 旧版接入应用的迁移说明——旧应用无需强制改造也能继续工作，但新特性要走新 API。

核心调用模式一瞥

Shizuku 的设计哲学是「对应用几乎透明」：应用拿到指向 Shizuku 服务进程的 binder 后，用 ShizukuBinderWrapper 把对系统服务的调用包装一层，请求经由服务进程以高权限转发给 system server，结果原路返回。

对开发者而言，调用 PackageManager 等系统服务的代码结构几乎不变，只是入口多了一层包装；官方文档里给出的授权操作示例（如授予运行时权限）总共不过十来行。

运行时必须处理的四件事

官方文档对几个坑位有明确提示，接入前通读一遍能省掉大量支持成本：

1. 先检查再调用：用 getUid 判断服务当前是 adb 还是 root 身份、用 checkPermission 确认权限是否足够——adb 权限在不同系统版本上差异不小，别假设权限一定够；
2. Android 9+ 隐藏 API 限制：普通应用调用隐藏接口受限，需要借助社区提供的绕行方案；
3. Android 8.0 的 binder 分发限制：旧系统上 adb 缺少注册 uid 观察者的权限，对非 Activity 启动的进程，需要用透明 Activity 触发 binder 发送；
4. 不要直接裸调 transactRemote：不同 Android 版本上事务码可能不一致，包装层已经处理了大部分情况，绕过它等于放弃兼容性。

发布时的合规红线

开源协议的附加条款对开发者同样生效（协议详情）：不得使用 Shizuku 的图标文件、不得以 Shizuku 命名应用、不得声明 moe.shizuku.privileged.api 包名与 moe.shizuku.manager.permission 权限。做「辅助工具」可以，冒充本体不行。

给开发者的最后一条建议

把 用户手册的启动流程 自己完整走一遍——你面对的支持问题（配对卡住、MIUI 通知样式、后台被杀）十有八九都写在官方 FAQ 里。用户问到的，直接给对应文档链接即可，不必重复造轮子。

到这里，全站的横向内容告一段落。回到 首页 可以按目录继续查漏补缺。