企业官网建设流程全解析

ShizuCallRecorder是一款面向 Android 的免 Root 来电录音开源应用，它通过 Shizuku 调用 ADB 的 shell 权限来录制通话双方的声音。很多朋友第一次看到"录音还要装一个 Shizuku"都会困惑：为什么一个录音 App 非要多装一个"权限管理器"？这篇文章就用最通俗的语言，讲清楚 ShizuCallRecorder 为什么离不开 Shizuku，它背后到底在做什么，以及会给你带来哪些安全影响。

一、背景：为什么普通来电录音 App 在安卓上"活不了"

先要理解一个前提：从 Android 4.4 开始，谷歌出于隐私保护，禁止了第三方 App 直接录制电话音频。这意味着那些曾经"即装即录"的来电录音 App，在新系统上要么失效，要么只能录到单声道。

• 普通第三方 App 拿不到录音电话所需的CAPTURE_AUDIO_OUTPUT这个受保护权限。
• 只有系统级应用（如部分厂商自带拨号器）才能合法使用它，但往往还附带自己的限制或广告。

ShizuCallRecorder 的破局思路是：借助 ADB 的 shell 用户身份，让录音逻辑运行在一个"高权限"进程里。而 Shizuku，正是把 ADB 能力"安全地借给第三方 App"的桥梁。这一点在项目文档中有详细说明，可参考 docs/configuration.md。

二、Shizuku 是什么：一句话讲清工作原理

可以把 Shizuku 理解为一位"权限管家"。它本身不做任何录音，而是负责：

1. 在后台维持一个基于 ADB 的shell 进程（Linux 用户 UID 为2000，在部分设备/版本上甚至是0）。
2. 让第三方 App 的代码"寄宿"进这个高权限进程，从而拥有普通 App 拿不到的系统权限。

在 ShizuCallRecorder 中，寄宿到 shell 进程里的"代码"就叫ShellService。正如源码注释里所说：

"ShellService runs inside the privileged shell process (UID 2000 or 0) managed by Shizuku."

参见 ShellService.kt。

下面拆解三个关键阶段，帮助你真正看懂"依赖"二字。

阶段 1：检测 Shizuku 是否可用

录音开始前，App 会先"敲门"，确认 Shizuku 服务器是否正在运行。对应代码是isAvailable()，它通过pingBinder探测连接是否存活：

• 如果 Shizuku 没启动，录音就无法开始，App 会提示你开启。
• 如果已在运行，则直接进入下一步。

该逻辑位于 ShizukuConnectionManager.kt。

阶段 2：把录音服务"升格"进 shell 进程

这一步是整个"依赖"的核心。普通进程无法调用受保护的音频接口，但ShellService跑在 shell 用户下就可以。App 通过bindUserService把ShellService绑定到 Shizuku 服务器：

普通 App 进程 ──(AIDL 远程调用)──> Shizuku 服务器(shell 用户) └── ShellService.startRecording() └── 调用受保护音频接口抓音

绑定与权限申请的处理见 ShizukuConnectionManager.kt。你可以把getShellService()理解成一根"电话线"：拨通之后，App 就能在另一端（高权限进程）里下指令。

阶段 3：用 appops 命令补齐"系统级"权限

光有 shell 进程还不够，有些权限（如读取电话状态、授予拨号器角色）需要通过appops/cmd role这类系统命令来"点亮"。这些命令正是由ShellService在 shell 进程里执行的：

简而言之：没有 Shizuku，就没有 shell 进程；没有 shell 进程，这些系统级权限就无从谈起，录音功能也就无从实现。这就是"必须依赖"的根本原因。

三、安全影响：Shizuku 到底会带来什么

这是新手最关心、也最该认真对待的部分。

风险 1：开启 ADB 意味着"攻击面"变大

Shizuku 的底层依赖 ADB（开发者选项里的 USB 调试 / 无线调试）。ADB 通道一旦开启，理论上任何能接入该通道的设备或恶意程序，都可能获得 shell 级操作能力。项目文档对此有明确提示：

"Shizuku TCP Mode ... comes with increased security risks."

详见 docs/configuration.md。

风险 2：银行 / 支付类 App 可能"拒绝工作"

一些金融类应用会检测 ADB / Shizuku 是否开启，一旦检测到就直接罢工。文档给出的建议是启用 Shizuku 的"自动禁用 USB 调试（Auto-Disable USB Debugging）"，在降低风险的同时，也减少被检测的概率。

降低风险的正确姿势：用"自动管理"

ShizuCallRecorder 内置了一个很贴心的功能——Security 区里的 "Manage Shizuku"（自动管理 Shizuku）。开启后，App 会在来电时自动启动 Shizuku、通话结束后自动关闭，把高权限窗口压缩到最短：

• 需要时才开启，平时不常驻，从源头缩小暴露时间。
• 还可选"Start only when recording"，进一步收窄为"仅在真正录音时才启动"。

这个"按需启停"的实现就在 RecordingForegroundService.kt 的tryStartShizukuServer()，以及服务销毁时的stopServer()中。

💡给新手的一句话建议：如果只打算用它录电话，强烈优先开启"Manage Shizuku"，让 Shizuku 只在通话期间存活，这是兼顾"能录到"与"更安全"的最优解。具体配置步骤参考 docs/SUPPORT.md 中的Installation / Configuration。

四、新手常见疑问（FAQ）

Q1：不装 Shizuku，ShizuCallRecorder 能用吗？不能。整个录音能力都建立在 Shizuku 提供的 shell 权限之上，缺少它，App 无法抓取通话音频，也无法完成appops权限提升。

Q2：Shizuku 会偷看我手机里的数据吗？Shizuku 只是提供一个"高权限通道"，它本身不读取、不上传你的数据。真正在这个通道里做什么，取决于被授权运行的 App（本例中就是ShellService的录音逻辑）。

Q3：开启 Shizuku 会影响我日常用手机吗？若保持"自动管理 + 按需启停"，日常使用几乎无感，也不会有常驻后台通知。真正需要警惕的是"让 Shizuku 长期常开"的用法。

Q4：为什么强调 FOSS（自由开源）？因为它是同类中少见的免 Root 开源方案，代码可审计。项目采用 GPL-3.0 许可证，相关说明见 README.md。

五、小结

• 为什么必须依赖 Shizuku：安卓禁止第三方 App 直接录电话，只有借助 ADB 的 shell 高权限才行；Shizuku 正是把这份高权限安全交给 App 的"管家"。
• 它到底做了什么：检测可用性 → 把ShellService绑定进 shell 进程 → 用appops/role命令补齐系统权限 → 抓音。
• 安全影响怎么看：开启 ADB 会扩大攻击面、可能被部分 App 检测；正确做法是开启Manage Shizuku，让 Shizuku "随用随开、用完即关"，把风险窗口压到最小。

理解了这三点，你就不会再觉得"多装一个 Shizuku"莫名其妙，而是明白它恰恰是实现免 Root 通话录音、同时把安全影响控制在最小范围的关键一环。