This overview is primarily for enterprise mobility management (EMM) providers who are integrating Android 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 admin or end user|
Over a billion people carry Android devices, and Android's management capabilities are opening huge markets for these devices in the workplace. The Android enterprise ecosystem has many participants—end users, enterprise customers, EMMs, OEMs, carriers, app developers, and admins.
With managed Android devices, 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 solution.
App developers create work apps that are compatible with managed Android devices. Admins manage devices and apps on behalf of the enterprise customer, often by means of an EMM console and the managed Google Play store.
Develop an enterprise solution for Android
We’ve organized the most common use cases for Android devices in the enterprise into five solution sets. Each solution set is made up of mandatory and optional features. Before you can release your Android EMM software publicly, it needs to fulfill the mandatory requirements of at least one solution set.
At a high level, developing an enterprise solution for Android involves five general steps:
Complete the basic setup steps, as described in Register for the EMM community.
Use the Play EMM API to enroll enterprises. How you do this depends on whether your customer (the enterprise) uses managed Google Play 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 managed Google Play 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 supports many enterprise 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.
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 securely isolates work apps and data from personal apps and data. Work app icons 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 an application called a device policy controller (DPC) that is installed on every 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 in the enterprise 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 their managed Android devices up and running. Two models are available, and they can coexist within an organization:
Managed Google Play Accounts
Using managed Google Play Accounts for user and device identity is the easiest option for admins and end users to set up if the organization does not use G Suite, and you can set up multiple accounts 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 API.
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.
Managed Google Play Accounts
Managed Google Play Accounts provide a lightweight identity model for organizations that don't use G Suite. Managed Google Play 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
A managed Google Play Account is a set of user, device, and admin accounts that aren’t linked to a domain name in any way. An organization can have more than one managed Google Play Account. For example, each department or region within an organization might set up a separate managed Google Play account.
At the highest level, here’s the managed Google Play Accounts workflow.
- Signs in to your EMM console using a Google Account. (This can't be a G Suite account.)
- Initiates the process to create a managed Google Play Account. For example, the admin clicks Configure Android in your EMM console.
- Follows a brief sign-up flow.
The admin’s Google Account becomes that enterprise's admin account, as described in Create and Enroll an Enterprise.
You (the EMM):
- Through the Play EMM API, enroll the enterprises.
- Through the Play EMM API, create and administer managed Google Play Accounts.
- Within your EMM console, maintain a mapping between managed Google Play 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, the DPC authenticates the user’s managed Google Play Account and provisions the account on the device. (A compatibility library is available to handle several aspects of the managed Google Play Accounts setup within your DPC. For details, see Build a device policy controller.)
The user's managed Google Play Account only gives them access to managed Google Play.
To set up Android enterprise 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 G Suite, you can leverage their existing domain and identities—G Suite customers already have enterprise IDs, and users are already set up with managed Google Accounts.
User identity and access to managed Google Play is provided by managed Google Accounts.
- 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 their Google, Account, possibly 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 of an Android enterprise solution
All enterprise solution sets require a DPC and an EMM console. These components must meet the mandatory feature requirements of the solution set (or sets) you've chosen to support. For a complete list of these requirements, see EMM community participant product requirements.
Device policy controller
EMMs supporting the COSU or Purpose-built solution sets should use Android Device Policy, provided by Google, as their DPC. Android Device Policy works in conjunction with the Android Management API to fulfill the mandatory feature requirements of these solution sets. You can try the API and start managing a limited number of test devices in minutes using the quickstart guide.
For all other solution sets, Google requires EMMs to provide a DPC that manages apps and policies on a device. Google doesn’t control or communicate with your 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
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 in the enterprise, 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 admins. 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, admins use your EMM console to manage user devices and control the distribution of apps that they acquire through managed Google Play, 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 a DPC and EMM console interact
The DPC is the center of the end-user experience, and your EMM console is the center of the management experience for the admin. We expect your EMM console to interact with a DPC in the following way:
- Your EMM console sets policies for devices and apps.
- The EMM console communicates the policies to the 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 users and devices for Android involves setting up end-user identities and devices so that they function properly within an enterprise 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 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 is the app management platform and marketplace for Android, and managed Google Play is available to enterprise customers for free. Users and enterprise admins use managed Google Play to browse apps. Admins use the managed Google Play console to select and approve public apps, upload private apps, and bulk-purchase paid apps for their users.
After apps are approved and purchased, admins use the EMM console to distribute the apps to user devices.
For more details about app discovery, approval, distribution, and management, see Distribute apps.