Work profiles on fully managed devices (COPE) debuted with Android Oreo on the 21st of August, 2017. In the extortionate amount of time since then (highlighted above) there are still only a minute number of EMMs in the market which support this perfect middle-ground between the loss of control on work profile devices, and lack of support for personal use on fully managed devices.
With advancements in Android Enterprise solutions to date, in particular OEMConfig, the workload for EMM vendors today has in theory shrunk. OEMs like Samsung and Zebra have fully embraced OEMConfig, with the former recommending the adoption of Android Enterprise over legacy DA-period SAFE APIs.
Yet EMMs continue to lag behind, implementing Android’s universal APIs in dribs and drabs across the ecosystem, and providing a rather fragmented management experience for customers. COPE is just one such example.
MobileIron was the first to launch support for work profiles on fully managed devices with MobileIron Core 9.7 in early 2018. It would be several months before their other UEM, MobileIron Cloud, gained support in late 2018 with R58.
MobileIron’s implementation isn’t bad, but their approach in deciding how admins should be able to manage the parent profile (by limiting available restrictions) has been a point of contention from the beginning.
In late 2018 VMware also introduced support for COPE with version 1810.
VMware equally uniquely provision managed Google Play accounts in both the work and parent profiles, leading to the possibility in future of deploying applications to both profiles as opposed to the work profile only.
The third UEM to support COPE, BlackBerry introduced it with BlackBerry UEM 12.11, though if you thought work profiles on fully managed devices was a mouthful, BlackBerry opted bizarrely to call their’s Work and personal – full control activations for Android Enterprise devices.
Other EMM/UEM vendors are working on supporting the solution – IBM, SOTI being two of the larger vendors. Intune and other vendors who rely on Google’s Android Management API are effectively stuck until Google support the deployment scenario.
As more vendors eventually support this two-year-old deployment scenario it will be updated here.