OwnDroid review: Android device-owner management with an Intent API

OwnDroid's DevicePolicyManager control surface

OwnDroid addresses a specific problem: Android does not expose its device-administration controls as an ordinary consumer settings panel. The project packages those controls in a Kotlin application for people who need to suspend applications, remove their icons, prevent uninstallation, adjust permissions, disable screenshots or cameras, control USB-related behavior, create users, and wipe data. The intended audience is therefore narrower than general Android users. It fits an engineer managing a test device, an automation developer connecting Android policy actions to another system, or an advanced user willing to grant a privileged application control over the device.

The application relies on Android's `DevicePolicyManager` API rather than implementing a separate policy service. Its feature list includes application controls, network configuration, user restrictions, user management, and keyguard or password operations. A wipe operation is especially sensitive because it can destroy device data. The README does not describe confirmation screens, authorization prompts, audit logs, recovery procedures, or granular access controls for each administrative action, so the feature list should not be read as a security policy by itself.

Device owner mode is the recommended mode because it provides the clearest Android policy identity. Other activation paths include Shizuku, Dhizuku, root, an ADB shell command, and work profile mode. Work profile mode is a different Android policy boundary, so it should not be assumed to offer the same controls as full device ownership. The project does not publish a capability matrix comparing every mode in the README.

Installing OwnDroid and completing enrollment

The README does not provide a package-manager installation command. It directs users to download releases from GitHub or the IzzyOnDroid F-Droid repository. ColorOS users are specifically directed to the testkey version on GitHub. The choice of distribution channel matters because OwnDroid is privileged software, and the README states that its testkey and normally signed versions differ only in their signatures, not in functionality.

For a device that has no existing accounts and no secondary users, the documented ADB activation path is the following command. It registers `com.bintianqi.owndroid/.Receiver` as the device owner. The README does not document the preceding `adb` setup steps, so device debugging and USB authorization must already be arranged outside this instruction.

dpm set-device-owner com.bintianqi.owndroid/.Receiver

A successful enrollment should replace the README's failure messages with an active device-owner state, although the exact success text is not documented. If Android reports that accounts already exist, the README gives two possible responses: freeze the accounts' holder applications or delete those accounts. Deleting an account is destructive to local data and account access, so the project's instruction is an enrollment workaround rather than a harmless default.

The command is not universally reusable. Android also rejects enrollment when several users exist, and a device owner may already be assigned. The latter case requires deactivating the existing owner first. On MIUI and HyperOS, the README identifies `USB debugging (Security setting)` in developer options, or execution from a root shell, as the documented responses to the shown `MANAGE_DEVICE_ADMINS` error.

First OwnDroid API action through ADB

OwnDroid includes an Intent-based API for advanced users. The API must first be enabled in OwnDroid settings, and an API key must be configured there. The documented ADB example sends a broadcast to `ApiReceiver` with the action `com.bintianqi.owndroid.action.HIDE`, a key, and an application package. This is the shortest documented path from installation to a policy operation outside the application interface.

am broadcast -a com.bintianqi.owndroid.action.HIDE -n com.bintianqi.owndroid/.ApiReceiver --es key abcdefg --es package com.example.app

The example uses `com.example.app` as a placeholder package value. A reader would need to substitute an installed application package and use the API key configured in OwnDroid. The README does not state the broadcast result, permission requirements, delivery guarantees, or whether repeated requests are idempotent. It also does not explain how to revoke an API key after use. Those omissions matter for automation because a broadcast that appears successful is not necessarily proof that Android accepted the policy change.

The API exposes actions including `HIDE`, `UNHIDE`, `SUSPEND`, `UNSUSPEND`, metered-data control, user-control restrictions, uninstall blocking, storage clearing, permission changes, screen capture control, camera control, USB control, `LOCK`, and `REBOOT`. Several actions have minimum Android versions, while `SET_USB_DISABLED` and `SET_USB_ENABLED` are marked for Android 12 and later. `REBOOT` deserves particular caution because it interrupts device availability, and `CLEAR_APP_STORAGE` can remove an application's local data.

Kotlin integration through ApiReceiver

The same API can be invoked from an Android application using Kotlin. The documented example constructs an explicit Intent for `com.bintianqi.owndroid.ApiReceiver`, places the action, key, and package in the Intent, and sends it through the application's `Context`. This approach differs from ADB in one important respect: the caller needs an Android execution context and must send the broadcast from the app process. It does not require typing the `am broadcast` command manually for each operation.

val intent = Intent("com.bintianqi.owndroid.action.HIDE")
    .setComponent(ComponentName("com.bintianqi.owndroid", "com.bintianqi.owndroid.ApiReceiver"))
    .putExtra("key", "abcdefg")
    .putExtra("package", "com.example.app")
context.sendBroadcast(intent)

The README presents the API as a list of Intent actions and minimum Android versions rather than as a versioned SDK with typed request objects. Consequently, an integration must preserve the action strings, component names, extra names, and key handling shown in the documentation. It should also account for device-owner privileges already being unavailable if another package owns the device. The README does not describe broadcast permissions, exported receiver protection, retries, error extras, or synchronization with the OwnDroid interface.

That makes the API suitable for controlled automation, but not for treating OwnDroid as a fully specified remote-control protocol. An engineer would need to decide separately how to verify the resulting application state, especially for destructive actions such as `CLEAR_APP_STORAGE`, `SET_USB_DISABLED`, and `REBOOT`.

Building OwnDroid from the master branch

For engineers who want to build the repository themselves, the README specifies Gradle command-line builds. The default build uses testkey signing. A custom signing key can be supplied through Gradle properties, including the keystore path, keystore password, key password, and key alias. The project includes both `gradlew` and `gradlew.bat`, with the batch file intended for Windows.

./gradlew build

The documented custom-signing form is:

./gradlew build -PStoreFile="/path/to/your/jks/file" -PStorePassword="YOUR_KEYSTORE_PASSWORD" -PKeyPassword="YOUR_KEY_PASSWORD" -PKeyAlias="YOUR_KEY_ALIAS"

This build documentation does not state the required JDK version, Android SDK level, Gradle invocation prerequisites, test suite commands, or generated APK location. The repository layout confirms an `app/` module, Gradle build files, and wrapper scripts, but it does not provide enough information here to claim a particular local toolchain configuration. Contributors are asked to run the app on a device or emulator before submitting code changes, with device testing required for code contributions and optional for translation contributions.

Signing is a release-engineering concern rather than a functional distinction. The README explicitly says testkey and signed versions have the same functionality. A custom key can also affect upgrade continuity if a later build is signed differently, although the README does not state OwnDroid's update or downgrade policy. Engineers should therefore treat signing key custody as part of deployment planning.

Enrollment limits and device-maker workarounds

OwnDroid's main limitation is that Android's device-owner enrollment is a state transition, not a permission switch that can be granted after arbitrary device use. Existing accounts and secondary users block the documented ADB command. Samsung devices can return `user limit reached`, and the README states that Samsung restricts Android's multiple-user feature and that there is currently no solution. ColorOS can produce `Unexpected @ProvisioningPreCondition`; the project responds by directing users to the testkey build. These are vendor-specific behaviors, not merely missing OwnDroid settings.

Device ownership also changes how work profiles and users are created. The README says that a system-managed `no_add_managed_profile` restriction is applied when a device owner is set. It says the device owner cannot modify system-imposed restrictions, while rooted devices may remove several restrictions with `pm set-user-restriction` commands. It warns that doing so may cause unexpected behavior, including silent deletion of a created user during reboot. It also says that device owner and work profile owner cannot be the same app, because the device owner would lose its privilege during reboot.

That last boundary makes OwnDroid unsuitable as a single-app solution for every Android management identity. A device with an existing corporate management app, an enrolled work profile, or vendor-managed users may require a different ownership arrangement. The README's root commands are presented as bypasses with an explicit risk warning, not as a supported universal installation method.

OwnDroid versus direct Android policy integration

The closest documented alternative is a separate application or automation service that calls Android's `DevicePolicyManager` directly through its own device-owner receiver. Both approaches depend on the same Android policy boundary, but OwnDroid supplies a user interface, a broad management catalog, and a documented Intent API. A direct integration can define its own request schema and error handling, which may be preferable when an existing Android management workflow already has a provisioning component and audit requirements.

A second alternative is root-based administration. The README lists root as an activation path and documents root shell commands for selected user restrictions. Root can reach controls that ordinary device ownership cannot change, but it also creates a larger security and maintenance burden. It does not remove Android's account or multi-user enrollment checks, and the README warns that bypassing user restrictions can produce unexpected reboot behavior.

OwnDroid is therefore not a replacement for Android enterprise management in every setting. It is a concrete implementation of Android policy operations with a convenience layer. The decision depends less on the number of listed commands than on whether the target device can enter the required policy state and whether the caller can verify the results.

OwnDroid maintenance and GPL obligations

The repository is not archived, and its last push was on 2026-10-09. Recent releases include v8.3.1 on 2026-08-26, v8.3 on 2026-08-26, and v8.2 on 2026-06-06. Those dates indicate recent project activity, but the README does not describe a support policy, compatibility matrix, migration guide, security response process, or long-term-support branch. A deployment should therefore budget for device-specific validation after upgrades rather than assume that every release preserves behavior across Android and vendor builds.

OwnDroid is distributed under GPL-3.0, with copyright attributed to BinTianqi. The README says the program may be redistributed or modified under the GNU General Public License and refers readers to `LICENSE.md`. That creates license obligations for code distribution and modification, but this review does not provide legal advice. An organization distributing a modified build should review the license text and its own distribution practices, especially when signing or integrating the application with another product.

The practical upgrade cost is concentrated in enrollment and vendor behavior. Existing device ownership, account state, profile restrictions, and signing identity can matter more than ordinary application updates. The repository's Gradle wrapper and release channels provide build and acquisition paths, while the README leaves rollback and downgrade procedures undocumented.

Editorial conclusion

OwnDroid is appropriate for an engineer or advanced Android user who needs application, user, and device-policy controls and can clear the enrollment prerequisites. It is a poor fit for an ordinary handset with active accounts, secondary users, or vendor restrictions that cannot be changed. Before adopting it, verify the exact `DevicePolicyManager` behavior on the target Android and device-maker build, especially account state, existing ownership, user limits, and the recovery path. The first practical checkpoint is whether `com.bintianqi.owndroid/.Receiver` can become the active device owner without removing accounts or profiles.

Frequently asked questions

Official sources

1. BinTianqi/OwnDroid on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases