Dhizuku: Sharing DeviceOwner Permissions With Other Android Apps

What Dhizuku Is For

DeviceOwner is the highest privilege level an Android app can hold. It is normally granted once, during device provisioning, to a single management app. That design assumes an enterprise deployment: a fleet phone is set up from scratch, an MDM package is installed, and no ordinary user ever touches the setting again. Dhizuku exists to break that one-app assumption. Its stated purpose is to share DeviceOwner permissions with other applications, so a device that already has Dhizuku as its DeviceOwner can pass those privileges on to apps that were never provisioned for the role.

The audience is narrow and specific. On one side are Android developers who need DeviceOwner-only APIs but cannot ask every user to factory reset a phone and re-provision it around their package. On the other side are users of those apps who are willing to prepare a device to make them work. The README points developers at a separate repository, Dhizuku-API, as the way to reach the permissions. There is no server component and no cloud account: the project is an app plus an API surface.

How the DeviceOwner Handoff Works

The architecture is a client and a broker. Dhizuku is installed as the DeviceOwner of the device. Other apps do not call the Android device policy APIs directly; they call Dhizuku through the Dhizuku API, and Dhizuku performs the privileged operation on their behalf. The privilege stays with one package, and the sharing happens at the API boundary.

That is why the developer story is a separate library rather than a set of instructions for obtaining DeviceOwner yourself. The repository layout reflects it: the Android application lives under app/, a hidden-api/ module exists alongside it, and settings.gradle.kts wires the modules together. Kotlin is the primary language. The practical consequence is that the trust relationship is inverted compared with normal Android permissions. Instead of the system asking the user to grant each app a capability, Dhizuku holds the capability and decides which callers get to use it. Anything that goes wrong inside that boundary is a problem for the DeviceOwner app, not for the calling app.

Installing Dhizuku and Activating It

The README lists three distribution channels: Google Play (package id com.rosan.dhizuku), F-Droid, and the IzzyOnDroid repository. There is no build-from-source quickstart in the README, and no command-line install. Pick one of the three stores and install the app the normal way.

The part that catches people out is activation. Dhizuku has to become the DeviceOwner, and the README does not spell out the steps itself. It sends readers to a pinned discussion on GitHub Discussions titled as the activation tutorial. The repository also shows a package named com.rosan.dhizuku.server and a receiver referenced as dhizukudareceiver, which is what the activation flow targets.

Before you start, read the warning the README puts in a callout. It states that setting up the device without any accounts is strongly recommended, and that if the device is already set up you may need to remove those accounts before enabling Dhizuku. It adds that support may not be available if any accounts are configured. Treat that as a hard prerequisite rather than a suggestion.

The supported range is Android 8.0 through 17. A device outside that range is not covered. After activation, the way to confirm the setup is to open Dhizuku and check that it reports itself as the DeviceOwner; the README does not describe the exact screen text, so rely on the app itself rather than on a quoted string.

Using the Dhizuku API From Your App

For developers, the README's only instruction is to use the Dhizuku API repository to access DeviceOwner permissions. It does not publish a Gradle coordinate, a version number or a code sample in the README text, so the dependency declaration has to come from that API repository rather than from this page. What the README does establish is the shape of the integration: your app is a client of Dhizuku, and the privileged work happens in Dhizuku's process.

The hidden-api/ module in the repository is a signal about how the project reaches system internals that are not part of the public SDK. That is common for tools in this category, and it is also the reason version support is bounded. Android 8.0 through 17 is a wide range, but hidden APIs move between releases, and a tool that depends on them carries the maintenance cost of tracking those changes. The release history is consistent with that: v2.12.0 in June 2026, preceded by v2.11.2 and v2.11.1 in November 2025. The gaps between releases are months, not weeks. The last push to the repository was on 2026-09-21, so the project is still being touched, but the release cadence tells you not to expect a fix the same week a new Android build breaks something.

Where Dhizuku Is the Wrong Choice

The account requirement is the biggest limitation, and it is stated plainly. If you cannot remove accounts from the device, activation may not be possible, and the README says support may not be available in that case. A phone that is someone's daily driver, signed into a Google account and a work profile, is exactly the device Dhizuku is awkward to set up on. A spare device is the realistic target.

The second limitation is the privilege model itself. Giving one app DeviceOwner over a device is a serious decision, and Dhizuku then extends that privilege to other apps. Every app you route through it inherits a capability that can change device-wide policy. The README does not describe a per-app approval flow or an audit log, so the trust decision is effectively made when you choose which apps to point at Dhizuku.

Third, this is not a general-purpose permission tool. If an app only needs storage, camera or notification access, Dhizuku adds nothing and costs you the provisioning work. And if you want DeviceOwner for a single app that you control end to end, provisioning that app directly is simpler than inserting a broker between it and the system.

Dhizuku and Shizuku Are Not the Same Tool

The most common comparison is with Shizuku, and the difference is in which privilege is being shared. Shizuku works through adb and the shell user, which is why its setup involves wireless debugging or a connected computer. Dhizuku works through DeviceOwner, which is a device policy role rather than a shell identity. The two grant different sets of APIs, and the activation procedures have nothing in common.

That distinction matters when you pick one. Shell-level access through Shizuku is the better fit when you need to call system services that the shell user can reach and you want to keep the device's provisioning intact. DeviceOwner access through Dhizuku is the better fit when the APIs you need are gated behind device policy, and you are willing to prepare a device with no accounts to get them. Neither replaces the other, and an app that targets one will not work through the other. The README's own framing supports this: it describes Dhizuku as sharing DeviceOwner permissions, not as an adb bridge.

Licence, Releases and What Maintenance Costs You

Dhizuku is licensed under GPL-3.0, and the README states it will remain open source. That is a copyleft licence, so if you distribute a modified version of Dhizuku itself, the GPL's source-disclosure terms apply to that distribution. Calling the API from your own app is a different question from modifying and shipping Dhizuku, and the README does not address the boundary. If your product depends on the answer, that is a question for a lawyer, not for this page.

Upgrade cost is driven by Android's release cycle. The project claims support from Android 8.0 to 17, and each new platform version is a chance that a hidden API used by the hidden-api/ module has moved or been restricted. The release dates suggest the maintainer ships when there is something to ship rather than on a schedule, so plan for a window where a new Android version is not yet handled. There is no documented rollback path in the README if an update goes wrong, and no migration notes for moving between major versions. Back up anything you care about before installing an update, and check the release notes for the version you are moving to.

Editorial conclusion

Dhizuku fits developers who need DeviceOwner-level calls inside their own app and users willing to set up a device with no accounts, since the README warns support may not be available once accounts are configured. It is not for anyone who needs to keep an existing signed-in phone untouched, and not for apps that only need ordinary permissions. Before adopting it, check the activation guide in GitHub Discussions, confirm your Android version falls inside 8.0 to 17, and read the Dhizuku API repository to see whether the calls you need are exposed.

Frequently asked questions

Official sources

1. iamr0s/Dhizuku on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases