Android Enterprise evolves at a rapid pace. As an inevitable result, there is a trail of confusion with terms being introduced or changing meaning often. Can you tell the difference between the following: Device Policy Controller, Device Administration API, Device Owner, Device Policy Manager, User Manager, Android Management API, Profile Owner? Let’s sort it out (in a relatively chronological manner)!
The birth of Device Admin API
The initial Android design concept was that the user is king. It ensured that if something nasty happens to the device (think of ransomware) – user could at least win their device back and start from scratch.
However, a scenario was quickly identified, which limited the adoption of Android smartphones: corporate email. Corporate admins wanted to ensure that if someone can access their email from the phone, that phone has at least a strong password and can be locked/wiped remotely if lost. Some sort of remote administration capacity was needed.
The answer – Device Administration API . Introduced in Android 2.2 it had less than 10% of the features available today. Basically, it did what the email clients wanted and a tiny bit more, with room for expansion. The mechanics were as follows:
- Developer (of the email app or EMM/MDM agent) designates their app as Device Policy Controller (DPC – developer-facing term used in the documentation) and implements corresponding code components.
- The user has to personally (manually!) approve the app as a Device Administrator (DA – user-friendly term used throughout the UI). User can revoke the DA rights at any time. User is king!
- One the DPC is approved as DA, it can enforce leverage the Device Policy Manager API to enforce policies and execute actions (set new password, wipe, lock screen). In the initial release, >90% of policies were password-related.
- There could be more than one admin on the device. What would happen if they enforce conflicting policies or otherwise clash for power? This was not defined.
We can sum this mode of operation as follows: Device Policy Controller app on the device works in Device Administrator mode, which is manually controlled by the user.
In the meantime, elsewhere…
For justice sake, if you think this is bad, look at this: the iPhone OS 3.2 Enterprise Deployment Guide ( (c)2010, same year as Android 2.2 was released) suggests the following:
But, back to Android…
Device Admin evolves, but is still lacking
The Android OS evolved, the needs for management grew, and so the features of the Device Policy Manager API. For instance, with the addition of multi-user support, a new API was spawned called UserManager, which by Marshmallow grew to several dozens features and restrictions, including this:
However, the whole Device Administration thing was still limited: it was fully user-controlled and the juiciest APIs were still unavailable to the 3rd party apps due to security risks (imagine a major malware takeover!).
This still hampered the EMM adoption (individual deals with device vendors to access the restricted APIs), necessitated vendor-specific custom extensions such as Zebra MX and Samsung KNOX (more work for EMMs!) and did not make enterprise customers happy at all…
Enter, Android for Work Android Enterprise!
The new answer to the problem was Android for Work introduced with Android 5, and promptly renamed into Android Enterprise later. The idea was to finally implement a standard and official way to manage devices across a variety of use cases.
Two new modes were implemented for the DPC app:
Device Owner (DO)
DPC owns the whole device, doesn’t really ask for user permission, cannot be disabled by the user. Own everything on the device.
Since the DO has virtually unlimited power over the device, it is only allowed on a “clean” device (after a factory reset). If you did not enroll DO during the initial setup wizard – you have to wipe and start again. Can you imagine migrating legacy devices? 😊
Designed for purpose-built, single-use and other fully-corporate-owned use cases.
Since the AfW–>AW rebranding, a more common public term is Work-Managed device. Basically Work-Managed = DO.
Profile Owner (PO)
The user still controls the device as a whole, but the DPC creates a secure container (Work Profile) fully owned, managed and controlled by the DPC itself. So, user rules the device, can enable/disable/delete container, but cannot mess with the contents of the container. The container is ruled by the DPC (Profile Owner), which cannot mess with the rest of the device.
This is clearly designed to support the BYOD scenario with a nice trust boundary between the “user” and “corporate” world.
The enterprise apps themselves appear mixed with user’s own apps, but marked with a “briefcase” overlay. The boundary actually extends into features like allowing copy/paste between work and personal apps, showing notification content for the work apps if the profile is not unlocked, sharing work/personal contacts etc – all this can be controlled via EMM.
Since the AfW–>AW rebranding, a more common public term is Work Profile.
In Android 8 one can actually run Work Profile inside a Work-Managed device, where the same DPC will be a Device Owner and the Profile Owner. This facilitates the COPE (Corporate Owned, Personally Enabled) devices, where the company buys a phone for the worker, wants to manage it as a whole, but allows them to install private apps, while still retaining full control of the corporate stuff within the profile.
To summarize, with Android Enterprise the Device Policy Controller app on the device works in either
- Device Owner mode, fully managed by the admin (vs user). User cannot even remove it.
- Profile Owner mode, where the device is manually managed by user, but the contents of the Work Profile are managed by the admin, establishing a trust boundary between the personal and corporate worlds. User can install/remove the Profile, but cannot mess with the insides.
Read about all the use cases enabled by these two modes here.
Android Enterprise is the way to go
The biggest achievement of Android Enterprise is that now we have a standardized and official (from Google vs vendor custom extensions) way of managing the devices. And while the feature set still cannot cover 100% of KNOX and MX, the vision is correct, and the pace of improvements is astonishing.
AE enjoyed an incredibly enthusiastic reception in EMM, Device Vendor and customer areas, as there are benefits for all:
- EMMs: implement standard APIs once and claim support of all devices. No need to support vendor-specific extensions and catch up after every new custom firmware. No need to strike vendor-specific deals to access device management APIs.
- Device Vendors: no need to invent custom APIs and provide support (and incentive!) for every EMM player out there. Custom extensions can still be made, but exposed via standard APIs (managed configurations, for instance) for immediate support by all EMMs.
- Customers: less custom and more uniform/standard – we all know what that means, right?
And there are even more components to the Android Enterprise framework: managed Play Store, managed app configurations, account management integration, various provisioning modes (NFC, QR, zero-touch enrollment) etc!
The levels of enthusiasm have already resulted in both device and EMM vendors declaring the “AE-first” approach, and rapidly deprecating old modes. Google followed suit with announcing the legacy DA mode deprecation plans.
So, AE is cool and you have no choice 🙂 What more can we want? Oh, wait…
Android Management API
All the previously discussed APIs and modes relied on someone (EMM vendor, corporate email app vendor etc) creating the DPC app. No wonder that most of functionality in those apps in the same. Why not standardize this? Enter Android Management API!
Basically, instead of writing your own DPC app, use this one from Google.
Now, all you have to do it to write the server part using the cloud-based API and your 1-2-3 lightweight EMM solution is ready!
- Google Play only (no AOSP devices)
- Device owner only (at least as of now) – designed specifically for purpose-built/COSU devices (kiosks etc).
- Cannot extend the agent – depends on Google’s implementation schedule. For example, the current command set is quite limited.
- Must register with Google for full production use
Anyway, the API is in Beta as of now, and will certainly evolve. If you need a lightweight EMM or just a subset of management functionality in your app – why not?
Are we done yet?
Yes! Let’s summarize in this handy (thanks to WordPress, not too handy) table:
|Friendly name (user/public facing)||Technical name (in docs)||AE or legacy?||On-device agent type|
|Device Administrator||Device Policy Controller||Legacy||Custom-built DPC app|
|Work-Managed device||Device Owner||AE||Custom-built DPC app|
|Work Profile||Profile Owner||AE||Custom-built DPC app|
|Android Management (TBD?)||Android Management API||AE (DO only)||Android Device Policy app|
More good reads (long!) from the guru Jason Bayton:
Now you should be able to differentiate between modes, API, developer-facing and user-facing names etc., roughly explain their purpose, and know where to dig deeper when you need it.
What are your impressions? For example, I haven’t formulated my own opinion regarding the newest Android Management API. What do you think of it?