初始化与授权实务：init、requestPermission 两步走

接 API 的代码面很薄，核心就两个调用，按顺序来。

第一步：初始化

应用入口处调用初始化，与中介建立 Binder 连接：

boolean ok = Dhizuku.init(context);

• 返回 true：连接就绪，后续接口可用；
• 返回 false 或抛异常：设备上中介未安装 / 未激活，按「未就绪」处理你的功能降级逻辑。

第二步：请求授权

需要权限的操作前，先查授权状态，未授权则发起请求：

if (Dhizuku.isPermissionGranted()) {
    // 已授权，直接干活
} else {
    Dhizuku.requestPermission(new DhizukuRequestPermissionListener() {
        @Override
        public void onRequestPermission(int grantResult) throws RemoteException {
            if (grantResult == PackageManager.PERMISSION_GRANTED) {
                // 用户批准，继续成功路径
            } else {
                // 用户拒绝，走失败路径或引导重试
            }
        }
    });
}

要点：

• 回调是异步的——批准结果通过 onRequestPermission 返回，别在发起请求的线程里等结果；
• grantResult 与系统权限常量对齐，PERMISSION_GRANTED 即成功；
• 拒绝后可再次发起请求，但别做成死循环轰炸，用户侧体验就是反复弹窗。

授权之后做什么

拿到授权后，通过 API 提供的包装层调用设备管理能力——典型形态是把系统 DevicePolicyManager 的调用包装后经 Binder 转发给中介执行（OwnDroid 的集成就是这条路：包装后调用 transferOwnership 等方法，见配合 OwnDroid的开发者视角）。具体接口以官方 Dhizuku-API 仓库的最新文档为准。

降级设计建议

• 中介未安装：引导用户到下载与激活（可链到官方主页），不要静默失败；
• 已安装未激活：提示「需要先完成激活」，附激活教程指引；
• 用户拒绝授权：功能置灰 + 说明原因，保留手动重试入口。