EMM Developer's Overview

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)
  • Start here—you’re in the right place.
  • To become an official participant in the Google EMM community, visit the EMM community applicant page.
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

Developing an enterprise solution for Android involves five general steps:

  1. Complete the basic setup steps, as described in Register for the EMM Community.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Deployment scenarios

Android supports many enterprise use cases, but there are two general device deployment scenarios, BYOD and corp liable.

BYOD

Work apps are badged to make them easy to distinguish.

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.

Corp liable

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.

Identity models

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.

  • Google Accounts

    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.

The admin:

  1. Signs in to your EMM console using a Google Account. (This can't be a G Suite account.)
  2. Initiates the process to create a managed Google Play Account. For example, the admin clicks Configure Android in your EMM console.
  3. 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):

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 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.

Google Accounts

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 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 enterprise 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
    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:

EMM console

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 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 admin. We expect your DPC and EMM console to interact in the following way:

  1. Your EMM console sets policies for devices and apps.
  2. The EMM console communicates the policies to your DPC after the DPC is installed on end-user devices.
  3. The DPC implements the policies on the devices using the Android framework APIs.
EMM console communicates policies to the DPC after the DPC is installed
    on user devices.

Service accounts

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.

Both the MSA and ESA have an ID that’s formatted as an email address (for example, 123456789012-abcd1efghij2klmnopqr3stuvwxy4z@developer.gserviceaccount.com), and both are authenticated with a private key stored as a JavaScript Object Notation (JSON) or .p12 key. For details about using service accounts, see Using OAuth 2.0 for Server to Server Applications.

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

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.

App distribution

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.

Send feedback about...

Android EMM Developers
Android EMM Developers