feat(android): 可选接入 Shizuku SDK，增强无障碍服务稳定性与恢复能力

[HKLHaoBin]

背景

OpenLess Android 端目前依赖系统 AccessibilityService 完成跨应用文本插入、键盘窗口感知等能力。部分厂商 ROM 会在后台清理、重启或省电策略变化后断开服务，甚至出现设置中显示已开启、实际服务未连接的情况，导致无障碍能力不够稳定，用户需要反复进入系统设置检查或重新开启。

建议接入 Shizuku SDK，提供一个可选的、由用户明确授权的特权辅助通道，用于增强无障碍服务状态诊断与恢复能力，减少厂商 ROM 下的失效概率。

建议方案

• 引入官方 Shizuku API / Provider SDK 依赖，并通过现有 Android 构建脚本纳入生成的 Gradle 工程。
• 在 Kotlin 层封装独立的 Shizuku bridge，向 Rust / Tauri command 暴露最小能力集合。
• 提供以下状态检测：未安装、未运行、未授权、已授权、Binder 失联。
• 仅在用户主动操作后请求 Shizuku 授权，不静默申请或执行特权操作。
• 授权后，辅助检查 OpenLess AccessibilityService 的启用状态和实际连接状态；在明确提示并获得用户同意后，尝试恢复对应服务配置。
• Shizuku 不可用或授权被拒绝时，继续使用现有系统无障碍设置页流程，不影响基础功能。
• 对 Binder 断连、Shizuku 重启和应用生命周期变化进行监听，避免缓存过期授权状态。

设置页交互建议

在 Android 权限面板增加“Shizuku 增强模式”区域：

• 展示 Shizuku 安装、运行和授权状态。
• 提供“打开 Shizuku”“请求授权”“检查/恢复无障碍服务”等显式操作。
• 清楚说明 Shizuku 并非必需依赖，普通用户仍可沿用系统授权方式。
• 明确提示：ADB 模式下设备重启后通常需要重新启动 Shizuku；因此它只能提升稳定性和可恢复性，不能保证永久在线。

安全与合规边界

• 遵循最小权限原则，只开放无障碍状态诊断和恢复所需操作，不提供通用 shell 执行入口。
• 不绕过用户授权，不静默修改其他应用或系统设置。
• Debug 与 Release 签名/UID 变化后应重新确认授权状态。
• 在合入前评估 Google Play 及其他应用商店对无障碍 API、特权操作和 Shizuku 依赖的政策要求；必要时可通过构建开关或分发渠道控制该能力。
• 日志仅记录阶段和结果，不记录命令输出中的敏感系统信息。

验收标准

• Android 构建成功集成官方 Shizuku SDK，桌面端构建不受影响。
• 能准确展示 Shizuku 的安装、运行、授权及断连状态。
• 用户可以显式授权，并在授权后检查 OpenLess 无障碍服务状态。
• 恢复操作必须经过用户确认，失败时给出可理解的原因和系统设置页回退入口。
• Shizuku 未安装、未运行或拒绝授权时，现有无障碍流程保持可用。
• 覆盖 Binder 断连、应用重启和设备重启后的状态刷新场景。

备注

Shizuku 不能替代 Android 标准无障碍授权流程，也不能解决所有 OEM 后台限制。本提案的目标是增加一个可选的诊断与恢复机制，提高功能在复杂 Android ROM 上的稳定性和可维护性。

[H-Chris233]

批准~你来实现吗？

[HKLHaoBin]

在做了在做了