In our previous blog post called Implementing Kiosk Mode in Android: Part 3, we briefly explored the Device Owner concept that was introduced in Android 5.0, Lollipop. In this article, we will provide a more in-depth look at the Android Device Owner, device policy controllers and what these mean to OEMs, EMMs, and solution providers. The article is structured as a Q&A to attempt to address some frequently asked questions (FAQs).
What is a Device Owner in Android?
A Device Owner is an application that runs as a device administrator on your Android 5.0+ device. The Device Owner app can use the programming methods in the DevicePolicyManager class to take control of the configuration, security and other applications on the device. A device can have only one Device Owner. No other applications can utilize the methods in that class to control the device.
What are some of the ways a Device Owner can administer the Android device?
The Device Owner, using the DevicePolicyManager class, is capable of performing the following key functions. See the class documentation for the full details and additional functionality.
Enable or disable hardware functions, such as the camera or fingerprint sensor
Enable or disable software functions, such as the lockscreen (keyguard), notifications, widgets, visible applications (make them hidden or unhidden), credentials on device boot or device encryption
Configure a password policy
Configure user accounts on the device
Configure network parameters, CA certificates and VPN information
Wipe the device (factory reset) or contents on external storage
Set Global Settings, like Airplane Mode, GPS, Bluetooth, Roaming, etc.
Switch users
Clear the current Device Owner
Does the Device Owner have to be an EMM application, like MobileIron or MobiControl?
No. Any application can be the Device Owner, but it must be written and provisioned to become the Device Owner. For example, if you have a kiosk application or a simple launcher, that app could be the Device Owner. It would also have access to the functionality described above to provide fine-grained control of the device.
What is device provisioning? What is being configured in the provisioning process?
Device provisioning is configuring or preparing a device for the user or environment in which it will be deployed. This includes the application(s) that will be used, network settings, security certificates, etc. For our context, it also includes the administrative app that will be the Device Owner.
When and How can I provision a device for Device Owner?
A Device Owner app is provisioned when the device is in an unprovisioned state. You can get to the unprovisioned state with a device factory reset (under Backup & Reset in Settings). A device may be provisioned with the Device Owner app using NFC; again, only when it is in the unprovisioned state. We discussed this provisioning in Part 3 and Part 4 of our article on Android kiosk mode. In Part 4, we discussed provisioning using NFC through the Blue Agent Writer app, writing the Device Owner app information to a NFC tag (NTAG216). In Part 3, we also discussed some other ways of configuring the Device Owner app.
What is the relationship between a Device Owner and Device Administrator?
The Android Device Administrator was introduced back in Android 2.2. It included support for the DevicePolicyManager class, along with the DeviceAdminReceiver and DeviceAdminInfo classes. The Device Owner app is a Device Administrator. A Profile Owner app is also a Device Administrator. But, the Device Owner can perform functions that a Profile Owner cannot. You can think of a Device Owner as a Device Administrator with special privileges. Even the semantics of some normal API methods change for a Device Owner. For example, any activity can call startLockTask(), but it only enables full kiosk mode for the Device Owner.
What is the difference between a Device Owner and a Profile Owner?
A Device Owner and a Profile Owner can perform many of the same functions, and the functionality of both may indeed be provided by a single app (like a Device Policy Controller (DPC) from your EMM provider). Profile Owner functionality is usually utilized on a device that has both work and personal data. The Profile Owner app creates a user profile on the device that separates the work data from personal data. The apps that are installed on the device in the work profile contain the Android for Work “briefcase” badge in order to distinguish those work apps from personal apps. Devices with both personal and work profiles fall into either the BYOD (Bring Your Own Device) or COPE (Corporate Owned, Personally Enabled) device classes.
A Device Owner can perform some functions that a Profile Owner cannot. It can disable Wi-Fi and Bluetooth, wipe device data, configure kiosk applications (whitelist “lock task” packages), and more. In other words, for corporate-liable devices that have no personal data, you want to configure a Device Owner, rather than a Profile Owner. Some apps, like EMM Agents (DPCs), may be written to function as both Device Owner and Profile Owner. See this Google developer information for more details on Profile and Device Owner.
What is a Device Policy Controller (DPC)?
A Device Policy Controller is an application that manages the company policies on an Android device. It may implement Profile Owner, Device Owner or both. Sometimes referred to as the device EMM agent, it is the application from your EMM provider that enforces the security and usage restrictions on the device. For more information, see this Google help note.
Need more help or information?
Please use the comment section below to ask additional questions that you would like answered. For engineering help, we offer software development services to assist you with the development of your Android applications, including Device Owner apps.
Learn how to provision and control Android devices with a device owner application in this post.
Comments