This overview is primarily for enterprise mobility management (EMM) providers who are integrating Android for Work into their EMM solution. It gives a high-level view of the EMM development process.
|Audience||Where to start|
|EMM solution provider (EMM)||
|OEM or carrier|
|App developers and ISVs||
|Enterprise administrator or end user|
Over a billion people carry Android devices, and Android for Work is opening huge markets for these devices in the workplace. The Android for Work ecosystem has many participants—end users, enterprise customers, EMMs, OEMs, carriers, app developers, and administrators—and Android for Work means something different for each.
With Android for Work, end users do their work on dedicated work devices or mixed-use devices that securely separate work and personal data. The enterprise customer manages and controls these devices with the help of a solution provided by an EMM. An EMM coordinates the products, OEMs, and carriers that make up an enterprise customer’s unique Android for Work solution.
App developers create work apps that are compatible with Android for Work. Administrators manage devices and apps on behalf of the enterprise customer, often by means of an EMM console and the Google Play for Work store.
Develop an Android for Work solution
Developing an Android for Work solution involves five general steps:
Complete the basic setup steps, as described in Register for the EMM Community.
Use the Play EMM API to enroll Android for Work enterprises. How you do this depends on whether your customer uses Android for Work Accounts or Google Accounts. For full instructions, see Create and Enroll an Enterprise.
Decide which user identity models you need to support, then set up your DPC and your EMM console to support them. How you do this depends on whether your customer uses Android for Work Accounts or Google Accounts. For details, see Provision User Identities.
Decide which deployment scenarios you need to support—for example, bring your own device (BYOD) or corp liable—then set up your DPC to support them on your user devices. For details, see Provision Customer Devices.
Decide how you and your customer will handle app approval, distribution, and so on, then set up your EMM console accordingly. For more information, see Distribute Apps.
For information about tools, APIs, and other resources that are available to you as you do this work, see APIs and Tools.
Android for Work supports many device and app use cases, but there are two general device deployment scenarios, BYOD and corp liable.
In a BYOD scenario, your enterprise customer allows its employees to use personally owned Android devices to access corporate apps and data.
Typical Android for Work BYOD deployments use the profile owner mode of operation, in which the customer sets up and manages a work profile on each employee device.
A work profile is a managed corporate profile associated with an Android device’s primary user account (which typically holds the end-user’s personal accounts). A work profile securely isolates work apps and data from personal apps and data. Work apps are located in the same launcher as personal apps, but badged to make them easy to distinguish.
The customer controls work profiles by means of a device policy controller (DPC) that is installed on every user device.
In a corp-liable deployment scenario, the enterprise customer owns and fully controls employee work devices. Corp-liable deployments use the device owner mode of operation, in which the customer directly manages the entire device by means of a DPC.
Corporate-owned, single-use (COSU) is a subset of the corp-liable scenario for shared or special-use devices. Unlike corp-liable devices that are associated with individual employees, COSU devices are associated with particular business functions. For example, a COSU device might be used as a kiosk.
Android for Work requires some information about an organization’s users in order to deploy and manage their apps. The identity model used determines the type of identities that an enterprise and its users need before they can get up and running with Android for Work. Two models are available, and they can can coexist within an organization:
Android for Work Accounts
Using Android for Work Accounts for user and device identity is the easiest option for administrators and end users to set up if the organization does not use Google Apps, and it allows for multiple instances of Android for Work within an organization.
This option uses Google Accounts for user identity, and it requires the organization to set up a managed Google domain if they don’t already use one.
Both identity models are supported by the Google Play EMM APIs.
You can support one or or both models, depending on your customers’ needs and what's best for your feature set. This section explains what to take into account as you decide.
Android for Work Accounts
Android for Work Accounts provide a lightweight identity model for organizations that aren’t currently using Google Apps. Android for Work Accounts:
- Are not tied to domains, and your customers can structure them how they like within an organization
- Are quick to set up, no verification required
- Support device accounts for COSU devices
- Are entirely managed by the EMM, no complex sync required
An Android for Work Accounts enterprise is a set of user, device, and administrator accounts that aren’t linked to a domain name in any way. An organization can have multiple Android for Work Accounts enterprises. For example, departments or regions within an organization might set up separate Android for Work Accounts enterprises.
At the highest level, here’s the Android for Work Accounts workflow.
- Signs in to your EMM console using a Google Account. (This can't be a Google Apps account.)
- Initiates the process to create an Android for Work Accounts enterprise. For example, the administrator clicks Configure Android for Work in your EMM console.
- Follows a brief sign-up flow.
The administrator’s Google Account becomes that enterprise's administrator account, as described in Create and Enroll an Enterprise.
You (the EMM):
- Through the Play EMM API, enroll Android for Work Accounts enterprises.
- Through the Play EMM API, create and manage Android for Work Accounts.
- Within your EMM console, maintain a mapping between Android for Work Accounts and the corresponding user identities.
The end user signs in to the DPC on the device, for example using their company email address and password.
Invisible to the user, your DPC authenticates the user’s Android for Work Account and provisions the account on the device. (A compatibility library is available to handle several aspects of the Android for Work Accounts setup within your DPC. For details, see Build a Device Policy Controller.)
The user's Android for Work Account gives them access only to Google Play.
To set up Android for Work using Google Accounts, an organization must have a managed Google domain. Each domain can be linked to only one EMM console, and the organization must follow a verification process to prove that they own the domain.
For organizations that use Google Apps, you can leverage the existing domain and identities for Android for Work—Google Apps customers already have enterprise IDs, and users are already set up with managed Google Accounts.
User identity and access to Google Play is provided by managed Google Accounts, with the following implications:
- Each user must have an individual Google Account and sign into it when setting up their device.
- For some configurations, users must sign in twice—once into the DPC, typically with their corporate email and password, and once into Google, probably with the same email and password.
- If you (the EMM) manage account life cycles, you maintain a mapping in your EMM console between Google Accounts and users’ regular identities.
- If the enterprise manages account life cycles, the enterprise might need to synchronize their users' online identities with their Google Accounts.
For more about user identities in the Google Accounts scenario, see Provision User Identities.
Components you must provide
For a complete list of requirements for EMM integration, see EMM Community Participant Product Requirements. Whatever solution sets you provide, you need a DPC and an EMM console, as described below. If you already have these, you need to modify them for your Android for Work customers.
Device policy controller
Google requires EMMs to provide a DPC that manages apps and policies on a device. Google doesn’t control or communicate with the DPC directly; this is up to you as the management solution owner. You use the methods that work best for you to link your DPC app to your customer’s deployed management server or your cloud service.
The DPC directly controls local device policies and pre-installed system applications. You can use the DPC to restrict device features (such as cameras), require apps to enforce restrictions, and do other similar tasks.
Depending on your deployment scenario, the DPC app manages either work profiles or whole devices:
- DPC manages work profile: BYOD scenarios on supported devices
Most BYOD deployments use the profile owner mode of operation, in which the DPC provisions and manages a work profile on the device. The DPC has limited control outside of the work profile. This scenario is supported only in Android 5.0 and higher.
- DPC manages whole device: corp-liable scenarios
Corp-liable deployments use the device owner mode of operation, in which the DPC manages the entire device. The DPC can create and remove profiles that belong to the primary user account, create and remove secondary users and their profiles, and configure global device settings. This scenario is supported only in Android 5.0 and higher.
For more details:
- For instructions on how to modify your management app to become a DPC for Android for Work, see Provision Customer Devices.
- To learn how to create a DPC, see Build a Device Policy Controller.
- For more about the role of DPCs, see What is a device policy controller?
We expect you to have an EMM console or other application that serves as the center of the management experience for your customer administrators. EMM consoles are sometimes referred to as management consoles, management servers, mobile device management (MDM) consoles, mobile application management (MAM) consoles, EMM dashboards, or admin consoles.
Typically, administrators use your EMM console to manage user devices and control the distribution of apps that they acquire through Google Play for Work, as described in Distribute Apps. They might also use the EMM console to manage aspects of user identity provisioning; for example, the EMM console could call the Google Directory API for provisioning of your customer’s Google Accounts. For more information about identity provisioning, see Provision User Identities.
Your EMM console must also support all of the device management functions that the DPC then implements on the device.
How your DPC and EMM console interact
Your DPC is the center of the end-user experience, and your EMM console is the center of the management experience for the administrator. We expect your DPC and EMM console to interact in the following way:
- Your EMM console sets policies for devices and apps.
- The EMM console communicates the policies to your DPC after the DPC is installed on end-user devices.
- The DPC implements the policies on the devices using the Android framework APIs.
Two types of service accounts are used in interactions between you and Google’s cloud APIs on behalf of your customers:
- Your master service account (MSA)—You create your MSA in the Google API Console, as described in Register for the EMM Community. The MSA is responsible for enrollment and un-enrollment, and you use it to authorize requests to the EMM Play API, using OAuth 2.0. You cannot use the MSA to access customer data.
The enterprise service account (ESA)—You or your customer create the ESA in the API Console, or in some cases you can create the ESA programmatically.
The ESA manages the Play EMM API resources, and you use it mainly to limit the scope of a service account to a customer. Even though it’s possible to use the same ESA for multiple customers, we recommend that you use any given ESA for only one customer, which ensures data separation among your customers.
User and device provisioning
Provisioning Android for Work involves setting up end-user identities and devices so that they function properly in the Android for Work environment.
EMMs, enterprise customers, OEMs, and app developers each have provisioning tasks to complete at different times. This section focuses on the provisioning tasks for you as an EMM.
User identity provisioning
User identity provisioning (or account provisioning) is the process of setting up user and device accounts and, if necessary, synchronizing your customer’s user data with Google Account information or your own database of customer information so accounts are consistent.
For detailed instructions, see Provision User Identities.
Device provisioning refers to setting up and configuring Android for Work on end-user devices. How you (or your customers) provision user devices depends several factors, including which deployment scenarios you support.
For detailed instructions, see Provision Customer Devices.
Google Play for Work is the app management platform and marketplace for Android for Work, and it’s available free of charge to Android for Work customers. Android for Work users and administrators use Google Play for Work to browse apps. Administrators use the Google Play for Work console to select and approve public apps, upload private apps, and bulk-purchase paid apps for their users.
After apps are approved and purchased, administrators use the EMM console to distribute the apps to user devices.
For more details about app discovery, approval, distribution, and management, see Distribute Apps.