igor - Fotolia

Tip

Compare Android Enterprise vs. Android Device Administrator

In most cases, Android Enterprise will serve for organizations' Android management needs, but IT admins should understand how Android Device Admin fits into the picture.

Google Android used to release APIs for mobility management via the Android Device Administrator program, but Google has now transitioned to Android Enterprise.

Android Enterprise vs. Android Device Administrator is no longer a debate in most scenarios. IT admins should know why Android Enterprise is the more modern option that will better serve their Android management needs.

Android Device Administrator: The beginning of Android Management APIs

Android management programs started in May 2020 with Android 2.2 when Google introduced the Device Administrator APIs. These APIs can provide basic management capabilities for Android devices at a system level -- today this program is known as legacy Android management. It allows IT administrators to perform some basic actions with elevated administrative permissions on Android devices via a management console. Those basic actions include the ability to configure email on the device, run remote device wipes and configure device password policies.

Third-party vendors with products such as enterprise mobility management (EMM) platforms and security applications relied on Android Device Administrator APIs to integrate with the mobile OS. The Device Admin program also has some significant flaws.

There is only one method to enroll Android devices with Android Device Admin. Because of that, the IT administrator always receives elevated permissions -- even on a personal device. There are also very few configuration options and they are inconsistent across different manufacturers. It's even possible for multiple apps on the same device to receive the requested elevated permissions.

The introduction of the Android Enterprise program

Starting with Android 5.0 in November 2014, Google introduced Android Enterprise -- previously known as Android for Work. Android Enterprise doesn't rely solely on system-level permissions, as it introduced the managed device -- also known as device owner -- and work profile -- also known as profile owner -- modes. These different modes provide enhanced privacy, security and management capabilities for the Android users and administrators.

Android Enterprise doesn't rely solely on system-level permissions, as it introduced the managed device -- also known as device owner -- and work profile -- also known as profile owner -- modes.

Administrators can use an EMM platform's custom device policy controller (DPC) in combination with the Google Play EMM API, or rely on the Android Device Policy-- Google's DPC -- in combination with the Android Management API. These combinations allow admins to deploy the required mode and different configurations on a managed Android device.

Microsoft relies on the management path that Google provides, which means that Microsoft Endpoint Manager and Intune rely on the Android Device Policy and the Android Management API to interact with Android devices.

Note: Google recommends Android Enterprise over the legacy method of Android Device Administrator and it no longer officially supports Device Administrator.

Android Enterprise's deployment scenarios

A big change with Android Enterprise compared to Android Device Admin is the support for different deployment scenarios and modes, which admins can take advantage of in different use cases. All four of the most common different deployment scenarios are available via the Android Management API.

Android deployment scenarios

This article will use the naming convention for these deployment models that Microsoft Endpoint Manager uses, but these models are present with similar names across different EMM platforms. These models are bring your own device (BYOD), corporate owned single use (COSU), corporate owned business only (COBO) and corporate owned personally enabled (COPE).

Personally owned devices with work profile (BYOD)

Android Enterprise supports this deployment scenario with Android 5.0 and later, and the scenario focuses on providing access to company apps and data in BYOD scenarios, meaning personal devices that users rely on for business tasks. This requires the user or mobile administrator to download the Company Portal app from the Google Play Store and to enroll the device by following the steps in the app.

After the enrollment, Android creates a separate work profile on the device. That separate profile will make sure that the personal and work data are strictly separated because it's stored in a separate container. That strict separation guarantees the privacy of the user.

Administrators' management reach on the device is within the work profile, which means that an IT can only configure settings within the work profile, remove the work profile from the device and not wipe the other components of the device. This option wasn't realistic with Android Device Administrator because the program automatically elevated the admin's privilege to the highest level.

Corporate-owned dedicated devices (COSU)

This deployment scenario is supported on Android 6.0 and later and focuses on providing access to company data on COSU devices -- also known as kiosk devices. This scenario -- as well as the next three scenarios -- requires the device to be enrolled by using NFC, a token entry, a QR code or Android zero touch. These methods will make sure that the device will download the correct DPC, the enrollment will occur with the correct EMM platform, and the device uses the correct deployment scenario.

After enrollment, the EMM platform locks the device down to the specific apps that belong to the single usage of the device. The management reach is device owner, which means that the device is fully managed and that an IT administrator can wipe the device in its entirety. The device is not associated to a specific user and doesn't allow any personal use or customizations.

Corporate-owned fully managed user devices (COBO)

This deployment scenario is supported on Android 6.0 and later and it focuses on providing access to company data on COBO devices, or fully managed devices that are associated to a specific user. These methods will ensure that the device will download the correct DPC, enroll itself with the correct EMM and use the correct deployment scenario.

After enrollment, the device is ready for exclusively work-related tasks. It is, however, possible to enable some minor levels of personal use by allowing users to add personal accounts and install nonbusiness applications from the Google Play Store. The management reach is device owner, which means that the device is fully managed and that an IT administrator can wipe the device. There is no separation between personal and work data.

Corporate-owned devices with work profile (COPE)

This deployment scenario is supported on Android 8.0 and later and focuses on providing access to company data on COPE devices, or corporate-owned devices that still guarantee the privacy of the user.

After the enrollment is complete, the device creates a separate work profile. That separate profile ensures that the personal and work data is strictly separated, as it's stored in a separate container. The management reach is work profile with device-level settings, which means that IT admins can deploy a limited number of configurations on the device but can still wipe the device. IT will, however, not be able to see anything that is happening within the personal profile.

Evaluating Android Enterprise vs. Android Device Administrator for an organization

Beginning with Android 9.0, Google started deprecating settings of the Device Administration API and starting with Android 10.0 those settings are completely removed. That seriously limits the management capabilities of Android Device Administrator and is a major reason to move to Android Enterprise-based management for organization that haven't already done so.

Android program comparison

Besides that, Android Enterprise supports far more deployment scenarios and provides better security, privacy and configuration options on Android devices. That combination enables IT administrators to manage Android devices with more options and to match the deployment scenario with the use case.

However, the Android Enterprise API relies on the availability of the Google Mobile Services (GMS), and GMS is not available in every country, such as China. When GMS is not available and the EMM platform completely relies on the Android Management API, it will not be possible to use Android Enterprise.

In that case, admins will still have to look at Android Device Administrator for managing Android devices. Admins in this scenario should consider adding something like Samsung Knox on top of an existing EMM platform to add Android management capabilities.

Generally speaking, Android Enterprise is the best option for managing Android devices when GMS is available, but Android admins will have to get a bit creative when this isn't an option.

Dig Deeper on Mobile operating systems and devices

Networking
Unified Communications
Security
Close