Android adoption has increased rapidly over the last few years, becoming the go-to OS for many organisations the world over. Due to the diversity of the platform and flexibility of form factor, application and budget, Android is making a huge impact on how employees undertake their daily responsibilities.
While iOS has typically (though not exclusively) been reserved for C-levels and senior management, employees lower down the corporate ladder are often provided more budget-friendly Android handsets. It makes sense really, although there are many flagships competing directly with Apple, there are even more directly targeting the mid-to-low end of the market at very attractive prices – perfect for mobility on a budget, right?
Up until around the end of 2016, not really.
EMM (Enterprise Mobility Management) platforms rely on APIs to communicate with and control managed devices. Things like disabling the camera, Bluetooth or preventing access to system settings are all individually exposed via one or multiple APIs. This is important to know and applies to all modern operating systems, it’s not limited to Android.
The difference is while iOS, Windows (Phone), QNX (BlackBerry) and others include these APIs with their respective operating systems and system applications, for many years Android did not, or offered comparably very few following the introduction of Device Administrator APIs in Android 2.2 – certainly not enough to consider manageable by any stretch.
That wasn’t the end of the world however; because Android is open source, manufacturers can build upon it and tweak it as much as they see fit. While other manufacturers tested the waters, offering some API functionality here and there, Samsung saw the gap in the market and devoted resources to making a splash.
And it paid off.
Today Samsung is by far the strongest Android device manufacturer for the enterprise due to their early efforts (with over 1400 APIs) and not only that, they’re the most-supported Android manufacturer for EMM solutions. Other manufacturers added APIs to try and compete but compared to Samsung with Knox (SAFE) and Knox Premium, there’s really no comparison.
The downside is how Samsung deploy their APIs; the more expensive devices tend to get the newest versions of Knox, while the mid-market and budget have to endure older versions, occasionally causing confusion (if they’re all 2017 models, why don’t they all have the same management capabilities?) and often meaning the newest EMM functionality won’t work with the cheaper devices as well (if at all).
The same goes for system applications, too. EMM requires APIs in order to push PIM data to the email, contacts and calendar apps on devices. For a long time it was either not possible or very unreliable to try to push Exchange data to a mid-range HTC, for example, and near impossible on other devices. Finding devices besides Samsung that could be reliably managed was no trivial task – eventually 3rd party apps such as K9, touchdown and many others began showing up offering EMM integration; for organisations only really needing basic management and PIM who were prepared to purchase licenses for these 3rd party apps, they could relatively safely look beyond Samsung.
And that’s really how it’d been until 2016, when it seems Google had taken notice of both the uneven playing field for enterprise device selection and a recurring perception that Android security is somewhat lacking.
Or, as it was until 2016, Android for Work.
Android Enterprise debuted with 5.0 Lollipop in 2014 as an optional* solution manufacturers could integrate in order to provide a common set of device management APIs. From 6.0 Marshmallow it was no longer optional and has since been a mandatory component for all GMS-certified manufacturers. There are still some optional components for Android Enterprise today and the occasional feature released only for newer versions of Android, however these have little impact on core management.
Android Enterprise (AE) offers a few things:
- A reliable EMM experience, knowing when a configuration is pushed, all AE devices will support and execute the relevant requests.
- A containerised work/life separation primarily aimed at BYOD, referred to as a work profile.
- A fully locked-down, managed mode for complete corporate ownership with no personal space, referred to as fully managed (previously work-managed).
- A single-use mode (Android Kiosk, but on a fully managed device) for Kiosk-like applications, referred to as dedicated (previously COSU – Corporately Owned, Single Use).
- A combined, COPE mode bringing together fully managed and work profile in order to provide a fully managed device with a personal space (fully managed devices with work profiles).
- Out of the box, zero-touch enrolment for Android 8.0 and above (or 7.0 for Pixel).
- A managed Google Play portal offering an application store for work devices containing only explicitly approved applications.
- Silent application installation without the need for a user-provided Google account on the device.
- Managed configs, a way of deploying corporate settings to managed applications (think Exchange profiles, but configurable in Gmail directly. See below).
- Mandatory device encryption.
- OEMConfig, a means for OEMs to provide additional APIs over and above Android Enterprise easily managed directly through an EMM
Here’s a breakdown of the management scenarios Android Enterprise supports:
As can be seen, there’s a lot of flexibility for supporting most business requirements baked right in, with the additional – the most common – management scenario, where the organisation controls the device but permits some personal usage (COPE), available with Android 8.0. All of these scenarios are available at no cost as soon as Android Enterprise has been bound with the EMM platform of choice.
There are two ways of enabling Android Enterprise, the first and original is through a G Suite managed domain that requires either an existing G Suite subscription or a free single-user account used for little more than initial setup and, optionally, managed app approval. If domain verification hasn’t already been done through G Suite, the business will need to undertake a couple of tasks to prove they own the domain they’re setting AE up against.
The second and newer method is managed Google Play accounts and works with any Google account – No domain verification required, takes practically minutes to set up and the EMM manages the individual Android Enterprise accounts on the managed devices, meaning there’s no need for additional Google accounts or GSuite user management. Furthermore, because the EMM manages account provisioning, Google cannot associate the accounts to any particular user and as a privacy is enhanced as a result.
Whichever method is used, it’s then possible (but not necessarily required since G Suite has basic EMM functionality) to link one of many existing EMM platforms which support AE and configure the corporate Play Store, Managed Google Play.
Some EMM platforms don’t make use of the Managed Google Play Store and instead manage apps through the integrated EMM app catalogue as has always been traditionally available, an example would be MobileIron (note, as of 9.3 MobileIron also uses Managed Google Play and from 9.5 the administrator can choose between the two):
The benefit of utilising an EMM platform for app management is managed app configs, making it extremely easy to tailor applications to the business for immediate use on deployment, no additional end-user configuration required:
For EMM admins the above config may look familiar, though apps like Chrome offer far more granular functionality around permitted domains, browser functionality and more.
Even better, because Android Enterprise (via the EMM) takes care of the accounts via managed Google Play accounts, there’s no need for a per-user or shared Google account to be on the device, and applications can be pushed down silently!
With the introduction of Android 5.0 Google made user profiles available to phones in addition to tablets already leveraging them. Using the same underlying functionality, Android Enterprise is able to create a managed user profile that although sits entirely separately encrypted on disk (and as of Android 7.0, utilises completely different encryption keys for work/personal), integrates directly with the current user on the device in order to provide both personal and work applications in the same app drawer – the latter indicated by a briefcase:
The mix of work and personal apps together on the above BYOD handset demonstrates the level of integration; as an end-user it feels like just another few apps installed, despite the underlying profile configurations working to separate and secure the corporate data. DLP policies can prevent the transfer of enterprise information outside of the work profile, and should an enterprise wipe be issued, it simply removes the work profile and leaves all user data untouched.
In addition for the work profile, Google have added work profile authentication; it’s essentially a secondary passcode requirement in order to access the corporate applications within the profile much like that of which BlackBerry’s Good, MobileIron’s Apps@Work or AirWatch’s Container have supported for many years.
Furthermore, the ability to pause (temporarily turn off) the work profile for evenings, weekends or holidays is a great asset to employees and can help tremendously in promoting a healthy work/life balance, even more so in countries where working hours are enforced.
The biggest issue with the whole BYOD approach is, as might be guessed, the limited control and visibility over the device itself since organisations cannot “see” anything outside of the work profile and may only enforce very basic device-wide policies such as passcode. For organisations needing more of a traditional managed device implementation, consider looking at fully managed.
As of Knox 3.0, Samsung offer Workspace as an alternative to the native work profile. Overall the UX is similar, but there are some quirks and differences to be aware of. The key benefit with this implementation is the capability to uplift to Knox Premium (for a price) to leverage a much broader set of management APIs over and above Android Enterprise.
Provisioning guides for the work profile deployment scenario can be found here: Android Enterprise provisioning guides
With fully managed devices there is normally no user space. As the intended use is for wholly company-owned devices, the process of provisioning a fully managed device removes any typically BYOD or COPE (Corporately Owned, Personally Enabled) scenarios and locks the device down strictly to the environment set by the EMM administrator. As of Android 8.0 however, the COPE scenario has been introduced with support for work profiles on fully managed devices.
Provisioning a fully managed device by default strips out almost all non-critical system applications unless white-listed, and instead provides access only to authorised apps via managed Google Play. Nothing more. This means should an app require the Camera to function, for example, a Camera app would need to also be authorised or white-listed for use by the business. There is support for enabling system applications, however this will include all of the OEM/carrier bloat most would want to see removed and will therefore require particular apps be disabled, rather than enabled as described above.
Fully managed provisioning is currently initiated on first boot of a new device – or one that’s been freshly factory-reset – using:
- A provisioning app on a dedicated provisioning device (configured with EMM server details) and an NFC bump, or an NFC tag on which to bump devices
- A DPC identifier on the Google account setup screen
- A QR code (ideal for devices without NFC)
- Zero-touch enrolment
In Android 10 NFC bump provisioning is deprecated, and NFC tags are instead encouraged for NFC provisioning.
With the NFC bump, depending on the EMM vendor used, the process will vary slightly in terms of pre-applied settings, what agent is downloaded in order to enrol the device on the relevant platform, etc; AirWatch for example allows for the additional configuration of a named account to directly enrol the device against – very useful for quick staging in bulk. MobileIron and others stay closer to the example set out by Google’s own provisioning app (github source).
Given the need for an NFC bump for this method of provisioning there are some limitations:
- Much like Apple Configurator, all devices being provisioned are somewhat tethered to a base location – yes, NFC tags can be placed elsewhere (it’s only a tag with some environmental information) but it cannot be done remotely “over the air” as it requires that physical bump.
- If the device is wiped, the device owner is reset and the device needs to be provisioned again, otherwise it returns to a fully unlocked, factory-reset state
- Devices not supporting NFC naturally won’t support a bump, this includes devices that have NFC disabled out of the box
Otherwise referred to as EMM token, the arguably more flexible but geekier option is the DPC identifier introduced in Android 6.0 Marshmallow. Essentially when prompted to add or create an account on a freshly wiped (or directly from the box) device, rather than pop in a Google account such as email@example.com, the user/administrator/device provisioner would type in afw#dpc, where DPC would be the EMM solution being enrolled into, for example:
- afw#mobileiron.core for MobileIron Core (on-prem)
- afw#airwatch for AirWatch
- afw#maas360 for MaaS360
Utilising this method foregoes the need for the device to be local to administrators and requires no additional provisioning device. It is however less straightforward and more prone to user-error, so clear communications need to be in place to minimise support requests when users are typing awf#dpc or other simple typos. Furthermore, there is no system app control with this provisioning method; system applications are disabled with no capability of enabling them in most EMMs beyond whitelisting any desired system application manually.
In Android 7.0 Nougat, the ability to provision a device with a QR code was introduced for both local and remote provisioning for OEMs who choose to support it (most do). By tapping on Welcome 6 times when the device boots into the setup Wizard, it will prompt the device to connect to WiFi and start QR enrolment, downloading a QR reader with which to scan an EMM enrolment code such as this one for MobileIron (and it will scan, if you’d like to try, however you’ll need a MobileIron Core to complete enrolment):
In Android 9.0 Pie, the QR payload is bundled into the system and therefore doesn’t require a download. This offers both much faster provisioning as the device no longer needs to connect to the internet to download the QR package, and the ability to add WiFi credentials to the QR, thus removing one further step from the process. It easily provisions 3x faster than in older Android versions.
Guides for all three of the above fully managed provisioning methods can be found here: Android Enterprise provisioning guides
- If issues are detected during fully managed enablement or EMM enrolment, the device may factory reset with little to no feedback. This can be frustrating.
- As mentioned above, initial app management may take some time to get right. Missing core apps may cause problems and as such the setup will need to be tweaked and tested before deployment.
Pro-tip: If the device states provisioning has failed and a reset is required, simply give the device a reboot to try again without a full factory reset. Where this doesn’t work, a reset will still be required.
As of Android 8.0, zero-touch has been introduced as a comparable solution to Apple’s DEP and Samsung KME. Devices are purchased through authorised resellers, assigned to a zero-touch console and later, when the end-user first takes the device freshly out of the box, will be ready to enrol as a fully managed device straight away; using this method administrators can now finally send devices directly to end-users without the worry of devices not being provisioned due to the number of steps required in the above deployment scenarios. More about zero touch can be read here.
In Android 10, it’s now also possible to provision a corporate-owned device through zero-touch to deploy a work profile only. Devices provisioned in this way will not be fully managed.
The above provisioning methods are also available in a handy infobyte.
Hopefully the benefits of Android Enterprise have been adequately conveyed above. To summarise:
- Prior to Android Enterprise the market was awash with inconsistent management capabilities across various Android manufacturers and app developers
- Android Enterprise offers a set of consistent APIs for device management and app management
- Android Enterprise securely separates corporate and personal data, or enables a purely corporately-owned profile without a user space
- Once provisioned, an Android Enterprise-enabled device no longer needs a Google account in order to install applications
- More features are coming in future to expand capabilities and enable more management types.
According to Google this is just the beginning. Their aim in the short term is feature parity between other offerings provided by the likes of Samsung and Apple, and long-term to far surpass the management capabilities of everyone else to make Android Enterprise the de facto choice for enterprise device management. Of course in doing so, they hope the perception of Android security improves in the process.
If your organisation has struggled managing your Android estate, is tired of dealing with Google accounts, is looking for more tools for entirely corporately-owned devices or anything else above, it could well be time to consider Android Enterprise.
NB: As of 2019, Android Enterprise has become the default means of managing Android 10 and later devices. The sooner AE is implemented, the better.
*I mentioned the voluntary incorporation of Android Enterprise there because as 5.0 devices began showing up on the market, they were being bought with Android Enterprise usage in mind and seemingly found to be missing the needed APIs for reliable management. Not all manufacturers – particularly less popular ones – felt the need to add this new, optional functionality.