Implement device management

This page describes guidelines for device manufacturers to enable device management on Android. To support device management, devices must meet all the software compatibility requirements defined under section 3.9. Device Administration in the Android Compatibility Definition document (CDD). The implementation guidelines provided here aren't exhaustive and serve only as a starting point for implementing Android device management.

Enable device management

To enable device management on Android, enable these features:

  • android.software.device_admin
  • android.software.managed_users

To confirm that a device supports device management, run the following adb command on a device and verify that those features are present: adb shell pm list features.

Setup requirements

Devices that implement device owner or profile owner provisioning must present appropriate disclosures to end users during setup (out-of-box experience or work profile setup). AOSP provides a reference implementation. Managed provisioning is the Android framework UI flow invoked during fully managed-device or work profile setup to ensure that device users are adequately informed of the implications of setting a device owner or managed profile on the device. Managed provisioning performs the following activities or delegates them to a device policy management role holder during provisioning:

  • Encrypts the device (if encryption is enabled).
  • Establishes a managed user.
  • Disables optional apps.
  • Sets the Enterprise Mobility Management (EMM) Device Policy Controller (DPC) app as device owner or profile owner.

In turn, the DPC app performs the following activities:

  • Adds user accounts.
  • Enforces device policy compliance.
  • Enables any additional system apps.

After provisioning completes, the DPC app's ADMIN_POLICY_COMPLIANCE intent handler runs in the fully managed device user (for device owner provisioning) or in the work profile user (for profile owner provisioning). Then the DPC app adds accounts and enforces policies.

Launcher requirements

To support device management, the Launcher must support badging apps with work icon badges (provided in AOSP to represent managed applications). Other user interface elements on managed devices or profiles, such as notifications, must use work badged assets. Launcher3 in AOSP already supports these badging features.

Default work apps

By default, only applications essential for correct operation of a managed device or work profile are enabled as part of Android enterprise provisioning. Device manufacturers can specify a list of default apps using these XML files:

  • vendor_required_apps_managed_profile.xml
  • vendor_required_apps_managed_device.xml
  • vendor_required_apps_managed_user.xml

After device provisioning, IT admins can use the EMM console or Managed Google Play to push any additional apps deemed necessary by an organization.

In both device owner (fully managed device) and profile owner (work profile) modes:

  • Apps without launcher icons are considered vital system components and are enabled automatically by Android.
  • Apps with launcher icons can be enabled by default during device provisioning by allowlisting their package names in vendor_required_apps_managed_[device|profile|user].xml files.
  • All other apps are disabled automatically during device provisioning.

Device owner implementation in devices configured with headless system user

Android 14 (API level 34) introduces the headless system user mode configuration where the system user is a background user and the foreground users are secondary users. Because device owner functionality traditionally relies on the system user also being in the foreground, the headless system user configuration brings certain unique challenges to fully managed devices (device owner provisioning).

Headless system user mode

Figure 1. Headless system user mode.

On a headless system user mode device, a device policy controller (DPC) application can be set as device owner only if it supports affiliated mode (HEADLESS_DEVICE_OWNER_MODE_AFFILIATED). The system checks if affiliated mode is supported by calling getHeadlessDeviceOwnerMode(). Device provisioning is handled accordingly depending on if the DPC application supports affiliated mode provisioning.