shizuku 介绍

StarShip
3 阅读10分钟

相关链接：

官方网站： shizuku.rikka.app/ github.com/RikkaApps/S…

架构解析： codewiki.google/github.com/… app.devin.ai/wiki/RikkaA…

代码仓库： github.com/StarShipNow…

用法介绍： sspai.com/post/73294

1. 核心作用

1.1 Shizuku是什么？

Shizuku 是一个 Android 平台上的开源工具/服务，它的本质可以概括为：

在不（必须）Root 的前提下，为普通应用提供“像 Root 一样调用系统 API 的能力”的中间层服务。

具体来说：

  • 它通过 ADB 或 Root 启动一个在高权限环境（类似 shell / system 权限）的后台服务；

  • 再通过 Binder IPC（进程间通信） 把这个服务暴露给普通应用；

  • 普通应用只要获取到 Shizuku 的授权，就可以借助这个服务去调用许多原本只能在高权限/系统环境中调用的系统 API。

Shizuku 自身并不会“帮你做事”，它更像是一个 “权限放大器 + 通讯桥”，真正的功能由使用 Shizuku 的各种应用实现。

1.2 它解决了哪些痛点？

对开发者和技术型用户来说，它主要解决了这几类问题：

  1. 非 Root 设备难以做深层系统操作

  • 传统上要修改系统设置、访问隐藏 API、批量管理应用、改动某些系统配置，常常需要 Root。

  • 许多用户不愿意 Root（保修、稳定性、安全原因），但仍希望实现一些“高级玩法”。

  • Shizuku 让很多这类操作可以在非 Root 的情况下以较为安全的方式实现。

  1. Root 方案风险大、不易控制

  • Root 后所有具备 Root 权限的应用理论上都能接管设备；

  • 权限粒度难以细分，存在更高风险。

  • Shizuku 提供了 “按应用、按会话” 的可控授权机制：你可以明确地对某个 App 授权或撤权，而不是“全局 Root”。

  1. ADB 命令使用门槛高

  • 纯 ADB 方式需要 PC + 命令行；

  • 对普通用户不友好，也不方便日常自动化。

  • Shizuku 把 一次 ADB 授权 → 持续后台服务，之后应用可以直接通过 API 调用，无需用户反复敲 ADB。

1.3 它与传统 Root 权限的区别

可以从几个维度对比：

1）授权模式

  • Root：

    • 一旦设备 Root，任何获得 Root 授权的应用，都能以最高权限运行，能做几乎“任何事”；
    • 对普通用户来说，难以理解每个操作的风险。

  • Shizuku：

    • 不给应用原生 Root，而是让应用通过 Shizuku 服务去调用特定系统 API；

    • 权限更像是“API 访问授权”，而不是“完全系统控制权”。

2）对系统的改动程度

  • Root：

    • 通常需要解锁 Bootloader，刷入自定义镜像/引导，改动系统分区；
    • 对系统安全机制影响更大。

  • Shizuku：

    • 非 Root 模式下，只用 ADB 在用户会话/特定用户环境中跑一个高权限服务；

    • 不需要解锁 Bootloader，不改系统分区，整体风险可控许多。

3）使用门槛

  • Root：

    • 操作复杂，且不同厂商、机型差异大；
    • 有一定刷机、救砖成本。

  • Shizuku：

    • 对大多数机型，只需：

      • 打开开发者选项 → 开启 USB 调试
      • 用电脑执行一次 ADB 命令
      • 后续即可以图形界面授权应用使用

    • 对技术爱好者来说门槛明显更低。

4）能力范围

  • Root： 能力几乎无限，可以直接改系统文件、内核参数等。

  • Shizuku：

    • 一般限于“在已有系统服务/API 的能力范围内做事”；

    • 更适合做“系统设置/应用管理/自动化” 类操作，而不是刷内核、改分区这类底层行为。

2. 工作机制

2.1 总体架构概览

可以用一句话抽象：

Shizuku = 一个高权限后台服务 + 一套 IPC & 授权框架 + 面向开发者的 API

主要角色：

  1. Shizuku 服务进程（server）

    1. 运行在具有较高权限的环境（通过 ADB shell 或 Root 启动）；

    2. 能够直接访问一些系统服务、隐藏 API；

    3. 提供 Binder 接口供其他应用调用。

  2. Shizuku 管理应用（客户端 App）

    1. 就是你在手机上安装的 “Shizuku” 这个 App；

    2. 用来启动/停止服务、管理授权、显示状态等。

  3. 第三方应用（使用方）

    1. 比如应用管理工具、自动点击工具、系统设置增强工具等；

    2. 集成了 Shizuku 的 SDK，通过 Shizuku 的 Binder 接口访问系统 API。

2.2 通过 ADB 或 Root 获取高权限

1）ADB 启动模式（非 Root 设备）

  • 用户在 PC 上执行类似：

    • adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh
    •   之类的命令（命令细节不同版本略有不同，Shizuku App 会提示具体命令）。

  • 这条命令在手机上以 adb shell 用户（通常是 shell 用户，权限高于普通 app） 的身份启动 Shizuku 服务。

  • 服务获得的权限相当于 adb shell 的能力，可以调用许多系统服务/隐藏接口。

2）Root 启动模式（已 Root 设备）

  • Shizuku 直接向 Root 管理工具（如 Magisk 管理 app）申请 Root；

  • 获得 Root 后启动服务，这时服务权限更高；

  • 不再需要 PC/ADB，每次重启系统也可以更自动地拉起服务。

2.3 与系统 API 通信的方式

Shizuku 的核心是通过 Binder IPC 将“高权限服务”和“普通 app”连起来：

  1. 服务端（高权限 Shizuku 进程）

    1. 绑定到特定的 Binder 服务名；

    2. 持有一些关键系统服务的句柄，比如 IPackageManager、IActivityManager、IWindowManager 等；

    3. 封装这些服务的访问接口。

  2. 客户端（使用 Shizuku 的应用）

    1. 通过 Shizuku SDK 调用：

      • 首先绑定到 Shizuku 服务的 Binder；

      • 检查权限（用户是否授权该应用使用 Shizuku）；

      • 调用封装好的接口，间接调用相应系统服务/隐藏 API。

  3. 授权控制

    1. Shizuku App 负责：

      • 记录哪些包名已经被授权；

      • 在新应用第一次请求时弹出授权对话框；

      • 允许用户随时撤销授权。

形象一点：

“应用 → Shizuku SDK → Shizuku 高权限服务 → Android 系统服务/API”

中间加了一层极可控的“代理人”。

2.4 应用层如何调用底层接口

以一个典型操作为例：卸载系统应用（或管理应用）

  1. 第三方 App 集成 Shizuku SDK，并声明需要 Shizuku 权限；

  2. 用户在 Shizuku App 中授权该 App 使用 Shizuku；

  3. 第三方 App 通过 Shizuku 获取到 IPackageManager 的代理对象；

  4. App 调用类似隐藏方法（示意）：

IPackageManager pm = ShizukuSystemApis.getPackageManager();
pm.deletePackageAsUser(packageName, observer, flags, userId);

  1. 实际执行是在 Shizuku 服务进程内，由它以高权限和系统服务交互，完成卸载。

开发者层面，只需要用 Shizuku 提供的封装，不必自己折腾低层 ADB 调用、反射复杂隐藏 API。

3. 使用指南

以下以典型 Android 10+ 机型为例，细节会随 ROM/版本略有差异，但总体流程一致。

3.1 安装与启动：ADB 启动方式（常用，非 Root）

步骤 1：开启开发者选项和 USB 调试

  1. 在手机 设置 → 关于手机，连续点击“版本号”多次，直到提示进入开发者模式；

  2. 返回设置，进入 开发者选项；

  3. 启用 USB 调试（如有“仅充电时允许 ADB 调试”等附加选项，也建议打开）。

步骤 2：在电脑上准备 ADB 环境

  1. 安装 Android SDK Platform Tools（包含 adb 命令行工具）；

  2. 连接手机到电脑，首次连接时手机会弹出“USB 调试授权”，勾选 “始终允许” 并点击允许；

  3. 在电脑终端中执行：

    1. adb devices

    2.   确认设备已显示在列表中。

步骤 3：安装 Shizuku App

  1. 从可信渠道下载安装 Shizuku（建议使用官方分发渠道）；

  2. 打开 Shizuku App，切到“启动方式”页面；

  3. 选择 ADB 启动，App 会显示相应的 ADB 命令（包括 start 脚本路径等）。

步骤 4：执行 ADB 命令启动服务

在电脑终端中复制/粘贴 Shizuku App 提示的命令，大致格式类似：

adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

  • 命令执行成功后，Shizuku App 通常会显示 “正在运行（通过 ADB 启动）” 或类似状态；

  • 部分系统上，如果有后台限制或电池优化，需要在系统设置中将 Shizuku 设为“允许后台运行/不优化”。

注意：

  • 重启手机后，ADB 模式一般需要你 再次执行命令 才能重新启动服务（最新版通常提供“无线调试 + 一键连接”等功能，可以减少每次用电脑的麻烦）；

  • Android 高版本上，可以使用 无线 ADB，流程类似，只是通过局域网连接。

3.2 安装与启动：Root 启动方式（已 Root 设备）

前提：设备已正确获得 Root，且装有 Root 管理工具（如 Magisk 管理）。

步骤 1：安装并打开 Shizuku

  • 同样从可信渠道下载安装 Shizuku；

  • 打开 App，选择 Root 启动 方式。

步骤 2：申请 Root 权限并启动服务

  • 点击“通过 Root 启动”；

  • Root 管理应用会弹出授权请求，选择允许（可以设置为始终允许）；

  • 若启动成功，Shizuku 会显示“正在运行（通过 Root 启动）”。

优点：

  • 一般可以 自动在开机时拉起服务，不用每次重启都重新 ADB；

  • 权限更充足，能实现更多需要更高权限的功能。

3.3 为其他应用授权 Shizuku 权限

当某个 App 想使用 Shizuku 的能力时，一般流程如下：

  1. 该 App 在代码中检查 Shizuku 是否运行、是否有权限；

  2. 如果没有权限，通过 Shizuku SDK 拉起 Shizuku 的授权界面；

  3. 用户在 Shizuku 的授权弹窗中会看到：

    1. 请求应用的名称/包名；
    2. 它请求使用 Shizuku 的原因（有的开发者会写说明）；

  4. 用户选择：

    1. 允许一次 / 永久允许 / 拒绝（具体选项随版本不同）；

  5. 授权后，该 App 随即可以调用 Shizuku 提供的接口。

你也可以在 Shizuku App 中：

  • 查看已授权应用列表；

  • 对某个应用单独撤销授权。

3.4 典型应用场景 & 推荐搭配工具

Shizuku 自身功能不多，但它成就了一个生态。典型场景包括：

场景 1：应用管理增强

  • 关闭/冻结系统应用或预装软件；

  • 批量卸载用户应用（包含某些原本不能轻易卸载的组件）；

  • 批量禁用/启用组件（Activity/Service/Receiver/Provider）。

典型工具：

  • 应用管理类工具（如 App 管理器、包管理增强工具等） 通过 Shizuku 调用 PackageManager 的隐藏/高级方法来实现对应用的复杂管理。

场景 2：系统设置/功能深度定制

  • 修改一些系统级参数或隐藏设置（例如部分 ROM 隐藏的 Debug/实验功能）；

  • 更精细地调整应用权限、前台服务行为、系统动画等；

  • 某些桌面/系统增强工具通过 Shizuku 实现更丰富的功能，而不需要 Root。

场景 3：自动化 & 无障碍增强

  • 自动点击、自动跳广告、自动处理弹窗等工具，使用 Shizuku 以更高权限实现更稳定的操作；

  • 可以减少对无障碍服务的依赖，或者配合无障碍，实现更精准、更快速的控制。

典型工具：

  • 自动点击/广告跳过工具（如基于 Shizuku 权限的自动化工具） 可更稳定地识别并操作 UI/系统弹窗。

场景 4：开发调试 & 逆向辅助

  • 简化开发时对隐藏/系统 API 的调用，无需构建系统级插件；

  • 在非 Root 环境下做某些调试（例如定向修改系统服务参数、监控进程状态等）。

avatar
文章
阅读
粉丝