How to Inspect Device Owner Policies and Work Profile Restrictions on Android Using ADB

In enterprise mobility and Bring Your Own Device (BYOD) environments, Android devices are managed through Enterprise Mobility Management (EMM) frameworks via Android Enterprise. Devices operate either under fully managed Device Owner (DO) mode or segregated Profile Owner (PO) mode (Work Profile). When corporate security policies—such as disabling screen capture, blocking USB file transfers, forcing password complexity, or isolating clipboard copy-paste between personal and work containers—cause unexpected app behavior, auditing policy state is essential. The Android Debug Bridge (ADB) dumpsys device_policy command provides direct shell visibility into all registered admin components and active policy restrictions.

Understanding Device Owner vs Profile Owner Architecture

The Android DevicePolicyManagerService (DPMS) enforces device administration through strict operational scopes:

• Device Owner (DO): Full management authority over the entire physical hardware. The enterprise EMM agent controls factory reset permissions, global network settings, app installations, and system update policies across all user profiles.
• Profile Owner (PO): Scoped management confined strictly to a dedicated managed user profile (typically User 10). The corporate agent enforces security within the Work Profile container without inspecting or controlling the user’s personal profile (User 0).

When an application developer tests enterprise-ready applications, understanding how DPMS evaluates user restrictions (such as DISALLOW_CROSS_PROFILE_COPY_PASTE or DISALLOW_INSTALL_UNKNOWN_SOURCES) is vital. dumpsys device_policy extracts the active policy database directly from memory.

Extracting the Device Policy Manager Dump

Connect your Android device or virtual emulator with USB Debugging enabled. Verify your connection:

adb devices

To inspect the entire policy state machine, execute the device policy dump:

adb shell dumpsys device_policy

Because the dump enumerates policy providers, user IDs, security accounts, and delegation privileges, the output can span several thousand lines. Using targeted search filters allows you to isolate critical management attributes.

Verifying Device Owner and Profile Owner Registration

When testing enrollment workflows, the first priority is verifying whether the target administration component successfully bound as DO or PO.

Search the dump for device owner information:

adb shell dumpsys device_policy | grep -A 8 "Device Owner:"

A provisioned device returns the admin package and user mapping:

Device Owner:
  admin=ComponentInfo{com.google.android.apps.work.clouddpc/com.google.android.apps.work.clouddpc.receivers.CloudDeviceAdminReceiver}
  name=Android Device Policy
  package=com.google.android.apps.work.clouddpc
  owner user=0

To inspect whether a secondary managed profile (Work Profile) exists on the device:

adb shell dumpsys device_policy | grep -A 8 "Profile Owner"

This will reveal which user profile ID owns the container (e.g., User ID: 10) and the specific package enforcing container boundaries.

Auditing Active User Restrictions and Policy Flags

User restrictions prevent users from executing specific device actions. When testing app functionality that fails unexpectedly (such as taking screenshots or toggling Bluetooth), check the active restriction bitmask.

Filter the dump for user restrictions applied across profiles:

adb shell dumpsys device_policy | grep -A 25 "User restrictions:"

The output categorizes restrictions applied globally or restricted to the managed user:

User restrictions:
  User 0:
    [none]
  User 10:
    DISALLOW_CROSS_PROFILE_COPY_PASTE
    DISALLOW_INSTALL_UNKNOWN_SOURCES
    DISALLOW_OUTGOING_CALLS
    DISALLOW_SHARE_LOCATION
    DISALLOW_UNMUTE_MICROPHONE

If an app inside User 10 attempts to share data or trigger external intents, the operating system blocks the call due to the listed policy constraints.

Auditing Cross-Profile Intent Filters

In Work Profile setups, certain user actions (such as opening a web URL or dialling a telephone number) can be permitted to forward from the work container to personal apps via Cross-Profile Intent Filters.

To inspect which intents are permitted to cross profile boundaries, search for intent filters in the dump:

adb shell dumpsys device_policy | grep -A 15 "Cross-profile intent filters:"

This lists explicit intent actions (e.g., android.intent.action.VIEW with https:// schemes) that the EMM agent allows to cross between personal and enterprise workspaces.

Testing Policy Enforcement in Development Environments

On non-production test devices or Android emulators, you can set custom user restrictions manually via ADB using the set-user-restriction command:

# Temporarily disable screen capture testing
adb shell cmd device_policy set-user-restriction no_screencapture 1

# Restore screen capture permissions
adb shell cmd device_policy set-user-restriction no_screencapture 0

This allows automated UI test suites to verify that your app appropriately hides sensitive financial or health records when screenshot restrictions are enforced by corporate MDMs.

Leveraging dumpsys device_policy equips Android developers and enterprise IT administrators with forensic clarity over device management states, ensuring enterprise applications remain compliant and robust.