Google announced its Android Work program during its developer conference in June. The program, which will launch as part of Android L this fall, marks a turning point for Android in business. Until now, there haven't been true across-the-board enterprise benchmarks or mobile management feature sets for Android, largely as a result of the open nature of the OS.
Some manufacturers like Samsung, Lenovo, LG, and Motorola have provided their own enterprise-oriented feature sets as a way of both responding to the needs of enterprise IT and as a way to differentiate products in the large sea of Android devices on the market.
Samsung has been most successful in this area with its SAFE (Samsung for Enterprise) program that offers IT administrators more than 300 granular policy options and that is reminiscent of the management capabilities of BlackBerry, and last year's launch of KNOX, a highly secure version of Android that includes a very robust enterprise feature set and powerful containerization tools for separating personal and business content on a device and for securing all business apps and content. KNOX had a slow launch in the market and suffered delays, but has begun to pick up steam since then.
The KNOX container and the ability to manage it is one of the fondations of Android Work. Building it into the core Android release offers a way to take one of the best enterprise technologies for Android and make it universally available to all devices running Android L. That establishes a very solid security posture for the platform as a whole.
Although the KNOX containerization functionality is a big part of Android Work, there are other key components, most of which Google has teased but not yet provided the full details about.
Here'e what we know about Android Work, how it compares to iOS, and what the model will likely mean for IT teams.
A seamless transition between personal and work data
Companies who invest in enterprise mobility strive to create a seamless experience, particularly when it comes to containerizing business apps and content.
When containerization first emerged on the scene, many vendors and IT departments focused on creating near total separation between personal and business facets of a managed device -- that separation involved creating separate secure apps for mail, contacts, calendars, and even web browsing. Each container had its own way of presenting secure apps to users, sometimes through a separate launcher or even a separate enterprise-only app market.
The experience was far from ideal -- it functioned as though a user was actually carrying around two separate devices. In some companies the experience was so sub-par that users rebelled against BYOD initiatives, either demanding a corporate-owned device or simply not informing IT that they were using their personal device for work purposes.
Apple took a stand against this form of containerization with the belief that creating a very obvious concrete wall between business and personal apps and content significantly degraded the appeal and functionality of a device.
Apple's solution, which debuted last year as part of iOS 7, is known as Managed Open In, and it's completely invisible to users. If an app is managed -- that is, installed via an enterprise mobile management (EMM) tool or enterprise app store -- IT has the power to say it could only exchange data with other managed apps. In such a case, a user sees no distinction between business and personal apps. The only difference is that if a user tries to share content from a managed app, he will only see the option to send data to other managed apps in the iOS share sheet. Managed apps simply look and behave like other apps, but with nearly invisible distinctions between them.
Google is taking this approach with Android Work. The Android Work container will encrypt and secure business data and restrict what users can do with it, but it will not appear as a separate workspace.
Google even seems to be borrowing Apple's managed app concept -- apps deployed by IT are considered managed and IT can impose policies on them beyond the encryption and data leak protections inherent in the container. The company hasn't provided too much information about how these per-app policies will function, but it seems likely that it will track a similar course to iOS, perhaps allowing IT to configure apps, impose additional security features, and/or manage network traffic based on specific apps.
One important difference between Apple's and Google's approach is that while Google wants Android Work users to have a seamless and native experience regardless of whether they're using business or personal apps, Android Work make it very clear which apps are business and which are personal. To that end, apps will have an Android Work badge added any time a user encounters them -- on a home screen, from the launcher, in a list of notifications, so on. That's a much more transparent approach than Apple's and one that's better for both users and IT.
Deploying, updating, and managing apps
Given how Android Work will containerize apps, it should come as no surprise that Google is also developing its own volume distribution mechanism for apps. Organizations will be able to make bulk purchases of apps for employees through Google Play and roll out enterprise apps developed for internal use. IT will also have the ability to push updates to enterprise apps to ensure everyone is working with the most recent version, which will ease security, functionality, and bug fix concerns across a large organization.
For developers, there's little concern about creating Android apps that work the new containerization and management functionality. Like Apple, Google is largely making this functionality available without imposing additional requirements on developers. For the vast majority of apps, this containerization and management will be automatic. The potential exception, according to Google's Android L API overview, will be launcher apps since they will need to aggregate information related to the primary user of a BYOD device and related to the work profile on that device.
Device Policy Client and profiles
Central to Android Work's EMM capabilities is a new Device Policy Client (DPC) app that is used to create work profiles that can be managed by IT. A work profile is used to establish the container on an Android device as well as to provision apps and policies in conjunction with an EMM solution.
On personal devices, a work profile can only be created after a user has authenticated using enterprise credentials provided by IT -- most likely this will be an Active Directory ID and password that has been associated with the right to enroll a device with a company's EMM service. Once created, a work profile is owned by the DPC, though it is also associated with the device's primary user to enable a seamless user experience as well as with Google Play to support app deployment.
To support the work profile, Google is introducing new enterprise entities, including a new profile owner entity that establishes a special kind of device administrator with enhanced capabilities. The profile owner cannot be modified by end users and is defined by IT. It can only be defined during as part of the Android Work provisioning process.
Android Work also introduces a related but broader entity known as device owner that is appropriate for corporate-owned devices and that has the authority to manage the entire device. This allows for greater management capabilities, but can only be configured for devices that haven't been previously provisioned.
The difference between these two levels of capabilities -- one targeted at BYOD devices and the other at corporate devices -- is very similar to the device supervision model that Apple introduced in 2012.
That model allows so-called supervised devices to be defined using Apple's Device Enrollment Program or Apple Configurator, a management app that requires a device to be connected to a Mac via USB for configuration. Apple limits supervision to these mechanisms because the management features available for supervised iOS devices provide much greater access to a device for both management and monitoring purposes that would impinge on the security and privacy of personal content on an employee-owned device.
It's nice to see Google making similar choices. Being transparent with users about what type of access IT will have to their device and data is critical to establishing the trust needed for them to be comfortable ceding some level of control over their devices.
For that trust to develop, however, IT departments must communicate the level of control that they have and how BYOD and corporate devices are each managed differently. Unless employees understand the distinctions, having those protections in place won't build any trust at all.
Android Work certification
A big challenge for supporting Android as part of a BYOD program is educating users on what devices will be the most enterprise-friendly. With such a large and varied range of devices, it can be challenging for users to pick the right model. It can even be difficult for IT professionals to understand the capabilities of some of the more obscure handsets or tablets available.
Google has wisely chosen to run an Android Work certification program and it already has support of major manufacturers. Rather than suggesting specific devices or trying to detail specific capabilities, IT leaders can make a blanket statement that any device bearing the program's name or logo will be supported. This also gives an opportunity to encourage users with older devices to upgrade, with or without a company subsidizing the cost of newer devices, to further bolster BYOD security.
Other advances for enterprises in Android L
Android L has a number of other advances that are not directly related to Android Work, but that will make it friendlier to enterprises.
Kill switch. Android L will be the first version of Android to support Factory Reset Protection -- a kill switch that, like Apple's Activation Lock, will prevent lost or stolen devices from being used. Microsoft will also be launching a similar capability next year.
Integration between Android and Chrome OS. Google plans to make computing experiences more fluid between Android devices and Chromebooks, which have been piloted in a wide range of companies and schools. The pairing isn't as extensive as what Apple is shooting for with its Continuity initiative, but given the low cost of most Chromebook models as well as the vast range of pricing for Android devices, the move could open some interesting options for business or classroom computing.
Positive momentum, but still just the first steps
Android Work is a major step in the right direction for Google in terms of gaining entrance to the enterprise mobility market that's currently dominated by Apple. It addresses some of the core concerns that enterprise IT has always had about Android -- solid separation of business and personal content, mass deployment of mobile apps, a single set of EMM policies that function across all Android L devices, and policy models appropriate to BYOD and corporate-owned devices.
But there are still unanswered questions and challenges . What about devices already that people already own? Many Android devices will likely be able to update to Android L at some point, but we don't know which ones and when they will receive that update. We also don't know for sure how much Android Work functionality will be available to devices running earlier versions of the OS -- although Google has indicated that it may make some Android Work capabilities available to devices running older Android releases, the company hasn't provided any details.
The support for older devices will affect adoption of Android Work in the short term. For IT departments already supporting Android to some extent, the immediate impact may be negligible. If you already have a model that allows or restricts access to resources based on the version of Android a user's device is running or other device-specific characteristics, that model should suffice until those older devices age out of your organization as employees upgrade and are replaced by Android L or newer devices.
But for companies that have not allowed Android in at all, however, it may be better to wait until Android L devices build critical mass in the mobile market.