Are You Ready for the Future of Android Device Management?

Evolution of Android Device Management

Are You Ready for the Future of Android Device Management?
©insta_photos – stock.adobe.com

The introduction of Android Enterprise with Android 5.0 (Lollipop) back in 2014, allowed enterprises and corporations to deploy, secure, and manage Android with various deployment scenarios, including Bring-Your-Own-Device (BYOD) and Corporate-Owned, Personal-Enabled (COPE) as well as Corporate-Owned, Business-Only (COBO) devices. 


Until now, Unified Endpoint Management (UEM) vendors have been developing their own custom Device Policy Controller (DPC) application to leverage the Google Play UEM API, acting as an intermediary and facilitating policy implementation by interacting with Google APIs, allowing them to create profiles such as Work Profile or Device Owner.

What Is Android Management API?

Android Management API (AMAPI) is a Google Cloud API, part of the Android Enterprise platform that was introduced back in 2017, providing a programmatic way for developers and IT administrators to manage Android devices in an enterprise or organizational context. Not only does it support the different existing deployment types available with Play EMM API, including Work profile (BYOD), Fully managed device (COPE/COBO), and Dedicated device (COSU) management types, but also provides new capabilities, like the new Lost Mode for COPE devices.


As a self-contained API, AMAPI does not require the use of a custom DPC client to be installed on the device for enrollment and management, but instead relies on Google’s own device-built Android Device Policy (ADP) client for tasks like device enrollment and device management, as well as deployment of policies, profiles, and applications. Google is currently no longer accepting new registrations for custom DPC with Android Enterprise but is encouraging all UEM vendors to use Android Management API instead, that comes with its own native DPC client. While they are committed to supporting it for the time being, there is no deadline officially available yet as to when the previous method might become obsolete and be deprecated. 

Right now, most UEM solution vendors are adopting AMAPI, but some still rely on their custom DPC client for other specific tasks like certificates and internal (in-house) applications distributions, as well as integration with other services and Software Development Kit (SDK), for example BlackBerry with their Dynamics containerized solution. 

Limitations and Vulnerabilities

In terms of management, the workflow between the UEM solution, Google cloud API and the Android device is slightly different. Whenever an administrative action is performed (e.g., assigned a new profile or policy to a device), the UEM sever transmits the desired state to Google Cloud API, that is, the list of public apps to be installed from Google Play Store and the management policies to apply (e.g., passcode requirements, certificates, app permissions). AMAPI then pushes the corresponding policies and apps alike to the ADP client, that will apply them on the device. 


Any Android device running Android 6.0 (Pie) or later natively supports Android Management. 

Differences from End-User Perspective

From an end-user perspective, the main difference comes with Work Profile (BYOD) deployments, where the end-user no longer needs to first download the custom DPC client (ex: BlackBerry UEM client) from Google Play store on his personal device, to later enroll it with the UEM server using provided credentials or QR code. But instead, simply scanning a QR code using the device’s camera or clicking on a link will trigger the device enrollment automatically. 

Example: Personal device enrolled with BlackBerry UEM using Android Management API.
Example: Personal device enrolled with BlackBerry UEM using Android Management API.

Actions for the Administrators

From a UEM administrator point of view, the next step is to check with your solution vendor whether AMAPI is already supported, and if so, follow the instructions to enable it. 


First, start testing it with several Android devices, to validate and document all different management types (BYOD, COPE, COBO), see the existing differences (new features, missing features). 


Then at some point, when the UEM solution is mature enough with AMAPI, start the transition phase, by making the decision to use it all new enrollments, in replacement of custom DPC. During that time, both management frameworks will coexist in parallel, and there might be some duplicate work, like maintaining policies and profiles in sync every time a change is made to enable/disable a feature or modify an existing configuration. 


Finally, when ready, start migrating all Android devices relying on custom DPC to AMAPI, to finally end up with all of them using that new framework. 

Which UEM Platform Already Supports It?

While Android Management has already been used for Android device management by some vendors, including Microsoft with Intune, this is not the case for most of them, as they preferred to use the custom DPC approach, providing them more control and flexibility, allowing them to implement new features and functionalities without having to wait nor rely on Google’s roadmap. 


Looking at the top UEM solution vendors, BlackBerry just integrated Android Management with BlackBerry UEM, v12.19, while Ivanti MobileIron supports it since Core Cloud version 89. As for VMware, they provide a beta preview but limited for now to Work Profile (BYOD) deployments only. 

How ISEC7 Can Help You with Your ZTA Deployment

For now, both management frameworks (Play EMM API and AMAPI) will co-exist, allowing UEM vendors to adapt their solutions accordingly to provide full support and features parity to their customers. 


In the meantime, we encourage organizations to enable and start testing that new management mode, get familiar with it from an administrator as well as end-user points of view, in view of adopting it eventually as THE management methods for Android devices. Also, most UEM vendors roadmap includes support for migrating managed Android devices from custom DPC to AMAPI, without having to manually re-enroll said devices, and this for all deployment types (BYOD, COPE, COBO). 


The team at ISEC7 can help with incorporating AMAPI into your pre-existing enterprise deployment and navigating the other options available to you. ISEC7 is your premier one-stop-shop for all your mobility and security needs, further shaping and improving efficiency in your digital landscape. Please feel free to contact us with any inquiries and we would be happy to assist you.  


Note: Please fill out the fields marked with an asterisk.

(C) Rémi Frédéric Keusseyan, Global Head of Training, ISEC7 Group