Managing Android Devices: Workspace ONE Operational Tutorial

Overview

Omnissa provides this operational tutorial to help you with your Workspace ONE® UEM environment. This tutorial covers the configuration and management of Android devices using Workspace ONE UEM.

Purpose of This Tutorial

This tutorial takes you through the basic configuration and management of Android devices using Workspace ONE UEM. Throughout the tutorial, we explore the various management capabilities available on the Android operating system. We start with understanding the different management modes, then explore different device management features available based on device manufacturers (OEMs). We also learn about the tools available in Workspace ONE UEM that help streamline Android device management.

Audience

This operational tutorial is intended for IT professionals and Workspace ONE UEM administrators of existing production environments.

Knowledge of additional technologies such as network, VPN configuration, Workspace ONE® Intelligence, Workspace ONE® Access™, Google Workspace Suite, Google Admin portal, and the Google Zero Touch portal is assumed.

Getting Started with Android Enterprise

Android Enterprise is a solution set from Google that provides a standardized framework to help manage Android devices in the workplace. It was first introduced with Android 5.0. Workspace ONE UEM integrates with Android Enterprise APIs to provide IT administrators with the tools they need to manage their Android device fleet.

There are two main ways to manage Android devices. As these management options are known by different names, we will examine each option by name(s) and use case, so you can best determine how to manage the device by use case. Android device management can generally be broken down based on who owns the device(s).

Personally Owned (Work Profile or BYOD)

• Work profile for employee-owned devices (BYOD):
  
  • These are employee-owned devices that are being used to access corporate resources.

Corporate Owned (Work Managed)

• Work profile for company-owned devices (formerly known as Corporate Owned Personally Enabled (COPE):
  
  • These are corporate-owned devices issued to employees and can be used for both work and personal use. These devices have a container inflated on them that isolates personal data from company data.
• Fully Managed devices:
  
  • These are devices that are solely used for work purposes and generally cannot be used for personal use.
• Shared devices (with Workspace ONE Launcher):
  
  • These are devices shared by multiple frontline workers or shift-based workers that check out a device using their user credentials to perform certain tasks, then return the device upon completion.
• Dedicated devices (Kiosk):
  
  • These are generally kiosk devices that serve a single dedicated purpose. They might be locked down to either a single or multiple application(s) and/or webpage(s).
• Fully Managed Closed Network / Android Open Source Project (AOSP) devices:
  
  • These are Android devices that either do not support or cannot connect to essential Google Mobile Services (GMS).

This tutorial will help you understand and decide which Android Enterprise mode might best fit your deployment use case for your organization.

Because the Android operating system has deprecated support for legacy device management (Device Admin) mode, procedures in this document focus on device management for Android Enterprise supported devices. For a list of Android Enterprise supported devices, see Android Enterprise Solutions Directory. Alternatively, see Legacy Android Migration on Omnissa Docs.

To ensure Android Enterprise is available in your country or region, refer to the Google support article Is Android Enterprise available in my country?.

Closed Network/AOSP Support

Workspace ONE UEM supports devices that are running the Android Open Source Project (AOSP) version of Android in Work Managed mode only. AOSP devices run the open-source version of Android that provides a common framework for device-level functionality, like call and email. AOSP, however, lacks support for essential Google Mobile Services (GMS).

GMS is a collection of Google applications and APIs pre-installed on approved devices by certain Android manufacturers under specific licensing agreements with Google. These apps include Google Search, Google Play Store, Google Maps, Gmail, YouTube, and more, which are not natively available on AOSP devices.

A closed network device here refers to a deployment environment where network rules prevent Android devices from connecting externally to essential, preinstalled Google services.

Android Go Support

Android Go is a streamlined version of the Android mobile operating system designed for low-end hardware that can be sold at a more accessible price point. To learn more, see the official Android Go product page.

Workspace ONE UEM supports devices running Android Go in Work Managed mode only. For these devices, all device management capabilities for the Work Managed mode are supported except for the following:

• Workspace ONE Launcher
• Product Provisioning features that require accessing or modifying files or directories on the device
• Files/Actions - Only Reboot and Run Intent Actions are supported
• Conditions - All Conditions except Launcher are supported
• Event/Actions - All Actions except Apply Custom Settings are supported

Network Requirements

End-user devices must be able to reach certain endpoints for access to apps and services. The network requirements for Android are a list of known endpoints for current and past versions of enterprise management APIs.

For the most updated version of the network port list, see Workspace ONE UEM Ports and Protocols.

Key Terms

In this tutorial, we frequently use terms commonly associated with Android deployments, which might include specific Google terms as well as Workspace ONE terms. The following table describes the key terms used throughout this guide. We recommend familiarizing yourself with these terms before continuing further in the tutorial. A list of terms can also be found on Omnissa Docs: Integrating Workspace ONE UEM with Android.

Terms	Description
Managed Google Account	Refers to Google domain registered accounts that are created and controlled by an organization using the Google Workspace console (formerly G-Suite). A managed Google account can be used to register/bind a Workspace ONE UEM tenant with Google.
Managed Google Play Account	Refers to a personally registered Google account (Gmail) which can also be used to register a Workspace ONE UEM tenant with Google.
Google Service Account	A Google service account is a special account that is used by applications to access Google APIs. This service account can be created in the Google Cloud console and is required in conjunction with a managed Google Account to complete the Android EMM Registration when binding Workspace ONE UEM with Google using a managed Google account.
EMM Token	Unique ID generated within the Google Workspace console (formerly G-Suite) that Workspace ONE UEM uses to connect with Google Workspace. EMM Token is required in conjunction with a managed Google account and a Google service account to complete the Android EMM Registration.
Managed Google Domain	Refers to the domain claimed and verified with Google Workspace.
Google Domain Setup	Google defined process for claiming and verifying the organization’s domain with Google Workspace.
User-based enrollment	When a device is enrolled, the Google account that is created is the same across all devices enrolled by this employee. This enrollment method is ideal for when you assign employees to devices with no staging involved.
Device-based enrollment	The generated Google account is unique to each device enrolled by the same user. This is ideal for a staging device or dedicated devices.

Understanding Android Enterprise Modes

Android device management modes can broadly be classified into personally-owned devices and company-owned devices.

Personally-owned devices have a work profile container inflated on them to help segregate work resources from personal data. This container provides the end user secure access to corporate apps and resources and keeps personal data hidden from the IT administrator.

Corporate-owned devices as the name suggests, are company-owned assets given to employees to help them with their day-to-day job functions. These devices can either be fully managed or can be configured to support both work and personal use.

Each device mode offers a unique device-side user experience and management options. To help determine which device mode best addresses your use case, let’s look at the table and descriptions below:

Table 1: Android Enterprise management mode and use case examples

Android Management Mode	Entire Device Management	Dedicated Container for Enterprise Apps	Dedicated Personal Apps
Work profile for employee-owned devices (BYOD)	❌	✅	✅
Work profile for company-owned devices (WPCO) (formerly COPE)	❌	✅	✅
Fully managed devices	✅	❌	❌
Shared devices (with Workspace ONE Launcher)	✅	❌	❌
Dedicated devices (Kiosk)	✅	❌	❌
Fully managed closed network / AOSP devices	✅	❌	❌

Work Profile for Employee-Owned Devices (BYOD)

Work profile for employee-owned devices, more commonly known as bring your own device (BYOD), allows employees to securely access corporate data using their personal devices. A work container is created on the device at the time of UEM enrollment, which segregates work data from employees’ personal data. In this mode, IT Admins can manage apps and restrictions within the work container but do not have access to the user’s personal data and apps. Work apps on BYOD devices are denoted with a briefcase icon, so they are easily distinguishable from personal apps. When an employee leaves, IT can perform an enterprise wipe using Workspace ONE UEM, removing only the work container and resources; leaving the personal data untouched. This mode is available on Android 6.0 or later devices.

Work Profile for Company-Owned Devices (WPCO)

Work profile for company-owned devices (WPCO), formerly known as corporate owned personally enabled (COPE) devices, are company-owned devices that employees can use for both personal and work purposes. Like BYOD, these devices have a dedicated work profile to separate work data from personal data during UEM enrollment. WPCO is available on Android 8.0 or later devices.

Starting from Android 11, Google implemented privacy-focused changes on company owned, personally enabled devices. WPCO mode now restricts certain device and app management capabilities on the personal side to bolster user privacy on devices being used for both work and personal purposes. For a list of all changes, see the Omnissa Knowledge Base article Changes to WPCO (COPE) in Android 11.

Fully Managed Devices

Fully managed deployments are for company-owned Android devices intended exclusively for work purposes. Organizations get complete control on how compliance policies and apps are configured, deployed, and monitored. These devices are usually assigned to specific individual users. Fully managed mode is available on Android 5.0 and later devices.

Shared Devices (with Workspace ONE Launcher)

Shared devices are a subset of fully managed devices and serve a specific purpose. These devices can be fully managed by the IT administrator and are not assigned to individual users. Instead, they can be shared between multiple users and job functions. Devices are typically available in a device pool, where users can check-out a device to perform their tasks. After use, the user can sign out, and return or check-in the device back to the device pool for others to follow the same check-in check-out (CICO) process and perform their respective job functions.

Dedicated Devices (Kiosk)

Dedicated devices are a subset of fully managed devices and serve a specific purpose. Dedicated devices are typically locked, kiosk-style, to a single app or set of apps/webpages. IT administrators can deploy granular control over a device's lock screen, status bar, keyboard, and other key features, to prevent users from enabling other apps or performing other actions on dedicated devices. 

Fully Managed Closed Network/AOSP Devices

As mentioned earlier, Workspace ONE UEM supports management of both AOSP and closed network devices. AOSP and closed network devices can only be fully managed, and work profile containerization is not supported. This mode is particularly suitable for intranet environments where access to Google services might be restricted due to security, demographic, or hardware constraints, or when such access is intentionally not required.

Registering for Android EMM

This exercise helps you register Workspace ONE UEM as your Enterprise Mobility Management (EMM) provider with Google.

There are two ways to register Workspace ONE UEM as your EMM with Google:

1. By using a personal registered Google account (Gmail) also referred to as a managed Google Play account.
2. By using a Google registered domain account (managed Google account) (recommended for Google Workspace users).  

A managed Google Play account is used when your business does not use Google Workspace (formerly G Suite) and allows binding Workspace ONE UEM with Android Enterprise using a personal Gmail account. No Active Directory sync or Google verification is required here.

Setting up Android Enterprise using a Google Workspace domain (formerly G Suite) requires your enterprise to register a Google domain for your organization and follow a verification process to prove that you own the domain. This domain can only be linked to one verified EMM account. To enable Android Enterprise enrollment using Google Workspace, your organization should create a service account with Google, and provide specific API access to apply the configurations to the managed devices. It is also important to decide how your users will authenticate into Workspace ONE.

Gmail Registered Account (Managed Google Play Account) Based EMM Binding

This exercise walks through registering Workspace ONE UEM as your EMM solution with Google using a managed Google Play account.

Prerequisites

Before you can perform the steps in this exercise, you must meet the following requirements:

• Obtain a personal Gmail account
• Enable Google URLs in your network architecture to communicate with internal and external endpoints

Configure Android Enterprise with a Google Play Account

To configure Android Enterprise with a Google Play account, perform the following steps:

1. Log in to the Workspace ONE UEM console and select the OG in which to configure the EMM binding.
2. Navigate to Groups & Settings > Devices & Users > Android > Android EMM Registration and click Register with Google.

3. If you are already signed in with your personal Google account credentials, you are directed to a Get Started page. In the browser, confirm that you are logged in to the correct Google account that you want to associate with your Workspace ONE EMM binding. If you are NOT signed in, click Sign In to enter your Google credentials, and then click Get Started.

4. Enter your Business Name. The Enterprise Mobility Manager (EMM) provider field populates automatically as Workspace ONE UEM.
    

The next page prompts you for key contact information of your organization's Data Protection Officer and an EU representative. If you do not have this information, it can be added later, in the Admin Settings section of the managed Google Play console. Scroll down to agree to the listed Terms & Conditions, then click Confirm.
 

5. On the next page, click Complete Registration.

6. After registration is complete, you are redirected back to the Workspace ONE UEM console, and your Google Service Account credentials automatically populate.

7. Click Test Connection to ensure the service account is set up and connected successfully.
   When the Test Account shows successful, click Save.

Google Registered Domain (Managed Google Domain) Based EMM Binding

Setting up Android Enterprise using a managed Google domain or Google Workspace (formally G-Suite), requires the organization to set up a Google domain. You also complete several manual tasks, such as verifying domain ownership with Google, obtaining an EMM token, and creating an enterprise service account to use this type of setup. For a detailed list of steps, see Register Android EMM with Managed Google Domain (G-Suite Customers) on Omnissa Docs.

Deploy without Google on a Closed Network

Workspace ONE UEM can be configured to manage corporate-owned Android devices that are enrolled and deployed within a closed network. A closed network here refers to one in which devices cannot connect to Google services. The environment can simply be intranet or might be in a region where Google services are not available. No Google account is created on the device during device enrollment. Public app management through Managed Google Play is not available.

The Workspace ONE UEM console configuration varies based on whether all or some of your Android devices are going to be connecting behind a closed network. For detailed instructions, see Deploying Corporate Owned Android Devices on a Closed Network on Omnissa Docs.

Unbind Domain from Workspace ONE UEM

You can unbind Workspace ONE UEM’s registration with Google in case you want to change the Google accounts used or switch the organization group (OG) in which the binding was initially performed. This section walks you through unbinding your Workspace ONE UEM console’s registration as your EMM with Google. Note that binding Workspace ONE UEM and Google is a prerequisite to enrolling and managing Android devices with Workspace ONE UEM.

Figure 1: Android EMM Setting in the Workspace ONE UEM Console where EMM Binding was done via Google Play account

1. Log in to your Workspace ONE UEM console and select the OG where Android Enterprise is configured.
2. Navigate to Groups & Settings > Devices & Users > Android > Android EMM Registration.
3. Click Clear Settings on the Android EMM Registration page.

Figure 2: Android EMM Setting in the Workspace ONE UEM console where EMM Binding was done via Google Workspace (formally G-Suite)

OEM Specific Configurations and Management capabilities 

Workspace ONE offers various Android OEM-specific configurations and device management capabilities as part of its Unified Endpoint Management (UEM) platform. Certain original equipment manufacturers (OEMs) allow specific management configurations and lifecycle enhancements on top of Android Enterprise capabilities. In this section, we discuss OEM-specific configurations for Samsung, Zebra, and Honeywell.

Prerequisites

This procedure discusses OEM-specific configurations and device management capabilities. Availability of OEM-specific supported devices along with basic knowledge of the subsequently mentioned OEM-specific tools is assumed.

Access to an OEM-specific device and online services is also assumed. You might need to contact the OEM to gain access to these services.

Samsung Specific OEM Controls and Options

On Samsung devices, the following OEM-specific configuration options are available:

Samsung KNOX Mobile Enrollment (KME)

Samsung Knox Mobile Enrollment (KME) is an easy and efficient way to enroll large numbers of corporate-owned devices while minimizing end-user interaction. To prepare for Samsung KME, first determine your enrollment type, then set up user credentials in Workspace ONE UEM, configure the KME Console, and create MDM profiles to deploy on your devices.

Devices that are corporate-owned can be deployed using Samsung KME. For detailed instructions, see Samsung Knox Mobile Enrollment on Omnissa Docs.

Samsung KNOX Service Plugin (KSP)

The Knox Service Plugin (KSP) allows enterprise customers to use Knox Platform for Enterprise (KPE) features as soon as they are made available. Administrators can use Workspace ONE UEM to activate their KPE license and install the KSP app along with its configurations. For detailed instructions on activating and deploying KSP, jump to Deploying Samsung KNOX Service Plugin (KSP) in this guide.

Samsung Enterprise Firmware Over-The-Air Updates (E-FOTA)

Samsung Enterprise Firmware Over the Air (EFOTA) allows you to manage and restrict firmware updates on Samsung devices running Android 7.0 Nougat or later. To get started, you must register for a Samsung E-FOTA license to get updates. Features are not available until registered.

The Samsung EFOTA flow involves registering your EFOTA settings provided by your licensed reseller, enabling Register Enterprise FOTA in the Android restrictions profile, and viewing and selecting applicable updates to push to devices. For detailed instructions, jump to Deploying Samsung E-FOTA Updates in this guide.

Honeywell-Specific OEM Controls and Options

For supported Honeywell devices, the following configuration options are available:

Integrated Honeywell Enterprise Provisioner Enrollment Barcodes

You can enroll Honeywell Android devices with a staging barcode generated from the Workspace ONE UEM console. The Honeywell Enterprise Provisioner is Honeywell's Android solution for staging devices and preparing them for production use. For detailed instructions, see Enroll Honeywell Devices with Staging Barcode, Android on Omnissa Docs.

Honeywell UEMConnect

The Honeywell UEMConnect is an administrative tool for configuring Honeywell-specific features on Honeywell Android devices using Android Managed Configurations. For detailed instructions, jump to Deploying Honeywell UEMConnect in this guide.

Zebra-Specific OEM Controls and Options

On supported Zebra devices, the following configuration options are available:

Zebra Integrated StageNow Enrollment Barcodes

You can enroll Zebra Android devices with a StageNow barcode generated from the Workspace ONE UEM console. The StageNow staging client is Zebra's Android solution for staging Zebra devices and preparing them for production use. For instructions on generating enrollment barcodes, see Enroll Zebra Devices with StageNow Barcode, Android on Omnissa Docs.

Zebra OEMConfig

Zebra OEMConfig is an administrative tool for configuring Zebra Mobility Extension (MX) features on Zebra Android devices using Android Managed Configurations. For detailed instructions, jump to Deploying Zebra OEMConfig in this guide.

Zebra LifeGuard and OS Updates

Workspace ONE UEM allows you to deploy LifeGuard and OS updates to enrolled Zebra devices. For detailed instructions, jump to Deploying Zebra LifeGuard and OS Updates in this guide. 

Device Enrollment Methods

Procedures to enroll Android devices into Workspace ONE UEM depend upon whether these devices are being enrolled as Corporate Owned (Work Managed), Work Profile (for BYO and personally enabled devices), or Closed Network/AOSP devices.

Device Enrollment Methods Matrix

This chart covers the different enrollment options Workspace ONE UEM offers for different Android Enterprise modes.

Android Management Mode and supported enrollment methods	Self-Onboarding with Intelligent Hub	Google Zero Touch portal	Workspace ONE QR Barcode Enrollment	DPC Keyword afw#hub based Enrollment
Work profile for employee-owned devices (BYOD)	✅	❌	❌	❌
Work profile for company-owned devices (WPCO) (Formerly COPE)	❌	✅	✅	✅ - Android 10 and earlier ❌ - Android 11 and later
Fully managed devices	❌	✅	✅	✅
Shared devices (with Workspace ONE Launcher)	❌	✅	✅	✅
Dedicated devices (Kiosk)	❌	✅	✅	✅
Fully Managed Closed Network / AOSP devices	❌	❌	✅	❌

Onboarding Personally Owned (Work Profile or BYOD)

This procedure discusses enrolling Work Profile on Employee Owned (or Bring Your Own) Android devices into Workspace ONE UEM. The steps are sequential and build upon one another, so make sure that you complete each step before going to the next step.

Prerequisites

Before you can perform the steps in this exercise, ensure that you have the following:

• Android devices running Android 6.0 (Marshmallow) or later with an associated personal Gmail account
• Workspace ONE UEM server URL and group ID
• Workspace ONE Intelligent Hub login credentials

Google Account Generation for Employee-Owned Devices

Android Enterprise generates a Google account for devices once enrolled. These accounts can be device based or user based.

User-Based is the best option for BYOD devices as the Google account created for this device will be the same across all devices enrolled by this employee.

Self-Onboarding with Intelligent Hub Steps

The following steps discuss enrolling a personally owned Android device into Workspace ONE UEM in Android Enterprise’s BYOD mode. Screenshots of steps might differ based on device make and OS version. To document this procedure, a Samsung S22 running Android 13 was used.

1. Search for and install Workspace ONE Intelligent Hub on your Android phone.

2. Launch Workspace ONE Intelligent Hub.
3. Enter a registered email address or your Workspace ONE UEM Server URL and click Next. If Workspace ONE UEM has been configured with simple enrollment, the next step isn’t necessary, as the server URL and group ID will be automatically populated.
4. Enter the enrollment Group ID and click Next. 

5. Enter your login username and password and click Next. 
6. Accept the Privacy Statement and Data Sharing conditions in the prompts that follow.

7. Click Agree on the next screen to set up a work profile.

8. During the enrollment process, you will see several processing screens. You do not need to interact with the device further until you see an enrollment confirmation from the Intelligent Hub. After the enrollment process is complete, the Agent displays the notification.
9. Confirm Work Profile enrollment from the Intelligent Hub app by navigating to Account > This Device.

Onboarding Corporate Owned (Work Managed) Devices

This procedure discusses the various options available to enroll Corporate Owned (Work Managed) Android devices into Workspace ONE UEM such as Fully Managed devices, Shared devices (with Workspace ONE Launcher), and Dedicated devices.

Prerequisites

Before you can perform the steps in this exercise, you must meet the following requirements:

• Decide on the Work Managed Android Enterprise management mode for your use case
• Register Workspace ONE UEM as your EMM provider with Google
• Credentials to third-party enablement tools such as Google’s Zero Touch Portal
• Workspace ONE server and group ID details where applicable

Google Account Generation for Corporate Owned Devices

Android Enterprise generates a Google account for devices once enrolled. These accounts can be device based or user based.

Device-Based is the best option for corporate-owned devices, with the exception of Work profile for company-owned devices (WPCO) formerly COPE. The generated Google account on the device is unique to each device enrolled by the same enrollment user making it ideal for staging and dedicated devices.

1. Log in to your Workspace ONE UEM console.
2. Select the desired organizational group (OG) in which to enroll in Work Managed devices.
3. Navigate to Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration > Enrollment Settings.

4. Set Management Mode for Corporate Devices as Work Managed.

 

5. Set Google Account Generation for Corporate Devices as Device-Based or User-Based.
   
   1. For more information on User-Based and Device-Based Google Account Generation, see the Key Terms at the start of this tutorial. For Work managed devices, Device-Based would be chosen for specific purpose-built devices.
6. Click Save.

Google Account Generation for Work Profile for Company-Owned Devices (WPCO)

Note: Work profile for company-owned devices (WPCO) requires Android devices running Android 8.0 (Oreo) or later.

The following steps need to be completed in the desired OG where devices will enroll before devices can be enrolled into Workspace ONE UEM in Work profile for company-owned devices (formerly COPE) mode:

1. Log in to your Workspace ONE UEM console.
2. Select the desired organizational group in which to enroll in Corporate Owned Personally Enabled (COPE) devices.
3. Navigate to Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration > Enrollment Settings.

4. Set Current Setting to Override.
5. Set Management Mode for Corporate Devices to Corporate Owned Personally Enabled.
6. Set Google Account Generation for Corporate Devices to Device-Based.

7. Click Save.

Google Zero Touch Portal Integration

Zero-touch enrollment allows for Android 9.0+ devices to be configured with Workspace ONE UEM as the enterprise mobility management provider out of the box.

When the device is connected to the internet during the initial device setup, the Workspace ONE Intelligent Hub is automatically downloaded, and enrollment details are automatically passed to enroll the device with no user interaction. After you configure Zero-touch in Android’s Zero-touch Portal, you can manage zero-touch devices for your organization from the Android EMM Registration page in your Workspace ONE UEM console.

For additional information on zero-touch enrollment, see the Android support article Zero-touch enrollment for IT admins.

Quickly enrolling COPE devices into Workspace ONE UEM via Google’s Zero-Touch is supported on Android 9+ devices. Steps to enroll COPE devices using zero-touch are like enrolling Work Managed devices using Zero-Touch. For detailed instructions, jump to Google Zero-Touch Enrollment.

Google Zero Touch Prerequisites

Before you can perform the steps in this exercise, ensure that you have the following:

• Android device running Android 9.0 (Pie) or later
• Device in factory reset / freshly out-of-the-box mode with Google Setup Wizard on the initial Start/Welcome page
• Google Zero-Touch portal admin credentials (partner.android.com/zerotouch)
• Work with your carrier/device reseller to upload IMEI and serial numbers for your devices into the Zero-Touch portal

Configure Google Zero Touch

Perform the following steps:

1. Go to https://partner.android.com/ZeroTouch and log in using your administrator credentials.
2. Navigate to the Configurations section and click the plus icon +.

3. Enter a Configuration Name and select Intelligent Hub as the EMM DPC (device policy controller) from the drop-down menu.

4. Enter the enrollment credentials in the DPC extras text box. These DPC extras are configured in the Workspace ONE Intelligent Hub during enrollment. You can include the Workspace ONE UEM console server URL, group ID, enrollment username, and password. Copy the JSON-formatted text in this section.

Depending on whether devices have a single staging user or are assigned to specific users, there are different DPC extras you can use for zero-touch configurations:

If end users are provisioning their own devices, exclude the username and password from the DPC extras. The user will enter them when prompted during device setup:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
"serverurl":"<WS1 UEM ServerURL>",
"gid": "<GroupID>"
 }
}

If you are assigning all Zero-Touch provisioned devices to a single staging user, like for kiosk and multi-user shift worker devices, enter the staging user credentials:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
"serverurl" : "<WS1 UEM ServerURL>",
"gid" : "<GroupID>",
"un" : "<username>",
"pw" : "<password>"
 }
}

For a list of additional JSON enrollment flags (DPC Extras), see Additional Supported Enrollment Flags for Android Enrollment (DPC Extras) on Omnissa Docs.

5. Enter the Company Name, Support email address, and Support phone number.
6. Enter the (optional) Custom message to display on the device during setup. Then click Add.

Zero-touch configuration is successfully created. You can assign zero-touch configurations to your devices from the Devices tab, by selecting the enrollment configuration just created and applying it to the device(s). For detailed instructions on assigning Zero-Touch configurations to your devices, see the Google zero-touch support page Zero-touch enrollment for IT admins.

Link Google Zero Touch with Workspace ONE UEM

After you have configured your zero-touch account, you can link your Google zero-touch account and the Workspace ONE UEM console to manage your zero-touch devices and configurations from within the UEM console.

By linking your zero-touch account to the UEM console, you can view devices associated with the zero-touch account, set a default enrollment configuration, and edit support information directly through the Workspace ONE UEM console. This section covers the steps involved in linking your zero-touch account to Workspace ONE UEM.

Note: Before linking accounts, specify the parameters for the default zero-touch enrollment configuration. After you link these accounts, Workspace ONE UEM sets these parameters as the default enrollment configuration for the account.

1. Log in to your Workspace ONE UEM console and select the correct OG.
2. Navigate to Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration > Zero Touch.

3. If you would like any default zero-touch configurations to apply to a specific organization group, set Specify Organization Group to Enabled and select the desired OG. When the setting is Disabled, settings apply to all OGs.
4. Enter DPC extra key and values. For a list of supported DPC extras, see Additional Supported Enrollment Flags for Android Enrollment (DPC Extras) on Omnissa Docs.
5. Click Link ZeroTouch. You now can view zero-touch accounts, configuration, devices, and support information. You can also link additional zero-touch enrollment accounts.

Note: To change this default configuration, unlink the zero-touch enrollment account and repeat this linking process.

Workspace ONE QR Barcode Enrollment

The QR code enrollment method sets up and configures Work Managed Device (as well as Corporate Owned Personally Enabled (COPE)) mode(s) by scanning a QR code generated with Workspace ONE UEM’s Enrollment Configuration Wizard.

To perform the steps in this exercise, you must satisfy the following requirements:

• Android device running Android 7.0 (Nougat) or later
• Device in factory reset / freshly out-of-the-box mode with Google Setup Wizard on the initial Start/Welcome page

Configure Workspace ONE QR Barcode Enrollment

Perform the following steps:

1. Log in to your Workspace ONE UEM console and select the destination OG.
2. Navigate to Devices > Lifecycle > Staging > List View > Configure Enrollment.

3. Select Android.

4. Select the QR Code, then click Configure.

5. In the Wi-Fi section, configure the optional Wi-Fi for the device to connect to before enrollment. Then click Next.

6. In the Hub section, select either the latest version of the Workspace ONE Intelligent Hub or a previous/custom version hosted on an external URL. Then click Next.

7. In the Enrollment Details section, set Configure Organization Group to Enabled and select the desired OG in which to enroll devices. Then configure login credentials based on your use case. Set the desired state for System Apps availability on the device. Then click Next.

8. The QR Code is ready to view or download. Note that QR codes are not automatically saved in the console and must be downloaded.

DPC Keyword afw#hub-based Enrollment

During Work Managed device enrollments (or Work profile for company-owned devices, in some cases), the user enters a special DPC-specific identifier token when they are prompted to add a Google account as part of the Android Setup Wizard. The token for Workspace ONE UEM is afw#hub which automatically identifies Workspace ONE UEM as your EMM provider and proceeds to download the Workspace ONE Intelligent Hub on the device before prompting the user to configure the Intelligent Hub.

DPC Keyword-based enrollment is supported on Android 5.0 (Lollipop) or later devices.

DPC Keyword-based enrollment for Work profile for company-owned devices has been deprecated on Android 11 and later devices. For more information, see the Omnissa Knowledge Base article Changes to Corporate Owned Personally Enabled (COPE) in Android 11.

For detailed instructions, see Enroll Android Devices using Omnissa Workspace ONE Intelligent Hub Identifier on Omnissa Docs.

Enroll in Closed Network/AOSP Work Managed Devices

Workspace ONE UEM can be used to manage your corporate-owned Android devices that are enrolled and deployed within a closed network. A closed network here refers to one in which devices either cannot connect to Google services or are running Android Open-Source Project (AOSP) code.

Considerations for Closed Network/AOSP Devices

• Only Work Managed enrollment is possible. Corporate Owned Personally Enabled (COPE) is not available without Google connectivity.
• Public applications cannot be deployed as there is no access to the Play Store. By extension, Public App Auto Update profiles also cannot be applied.
• Applications must be uploaded to the Workspace ONE UEM console as an internal app for deployment to devices on closed networks.
• You must use AirWatch Cloud Messaging to manage your Android devices in real time. Firebase Cloud Messaging is not supported as devices cannot connect to these servers.
• For Samsung Android devices and accessing advanced Knox capabilities, a Knox License Key must be activated on the device. Samsung offers on-premises installations of the Knox license activation servers for closed network deployment since activation requires public internet.

For detailed instructions on configuring your Workspace ONE UEM console to enroll work-managed devices on a closed network, see Configure Android EMM Settings in the Workspace ONE UEM Console on Omnissa Docs.

Configuring Android Profiles in Workspace ONE UEM

This exercise helps you understand the basics of configuring Android Profiles in Workspace ONE UEM.

Android profiles help ensure device and data compliance. Profiles serve many different purposes, from enforcing corporate restrictions on devices (both Fully Managed and Personally Enabled), like disabling USB Debugging and/or Screen Capture and so on, as well as installing organization-specific policies such as Certificates and VPN configurations.

Prerequisites

To perform the steps in this exercise, you must meet the following requirements:

• Complete the Android EMM registration in your Workspace ONE UEM console
• Enroll Android devices into Workspace ONE UEM using any of the aforementioned enrollment modes

Android Versus Android Legacy Profiles

When deploying profiles there are two Android profile types: Android and Android (Legacy).

The Android (Legacy) profiles option is available for organizations that haven’t migrated to Android Enterprise. Because Android Enterprise is the de-facto device management framework standard for managing Android devices as defined by Google, we focus only on using profiles in this section. To learn more, jump to Migrating Legacy Android Devices to Android Enterprise in this guide.

Note: If you select Android but have not walked through the Android EMM Registration, an error message displays prompting you to go to the settings page to complete EMM registration.

Work Managed vs Work Profile Tags

Android profiles in Workspace ONE UEM display the following tags: Work Managed Device and Work Profile.

Work Managed device profiles apply to corporate-owned, fully managed devices that are enrolled from an un-provisioned state (factory reset). Workspace ONE Intelligent Hub is installed during the setup process and set as the device owner, meaning that Workspace ONE UEM has full control of the entire device.

A Work Profile is a special type of administrator tailored primarily for employee-owned and company-owned personally enabled device use cases. In Android 11 and newer versions, the Workspace ONE Intelligent Hub installs within the Work Profile container and hence only controls the Work Profile. Managed apps install within the Work Profile and display an orange briefcase badge to differentiate themselves from personal apps.

In Android 11 and prior versions, specifically for Work Profile on Company Owned devices (formerly known as COPE), profile features with both Work Managed and Work Profile tags can be applied.

There are times when more than one profile needs to be implemented for various reasons. When duplicate profiles are deployed, the most restrictive policy takes priority. Therefore, if two profiles are installed, and one says to block the camera and another says to allow the camera, Intelligent Hub for Android combines the profiles and blocks the camera to choose the more secure option.

Configure Android Profiles in Workspace ONE UEM

In the Workspace ONE UEM console, you can follow the same navigation path for each profile. The Preview section shows you Total Assigned Devices with a list view. You can also see the added profiles on the Summary tab.

To configure profiles, follow these steps:

1. Navigate to Resources > Profiles & Baselines > Profiles > Add > Add Profile > Android.

2. Configure the following to get started:
   
   1. Name – Set the name for your profile and add a description that would be easily recognizable to you.
   2. Profile Scope – Set how the profile is used in your environment either on Production, Staging, or Both.
   3. OEM Settings – Turn on OEM settings to configure specific settings for Samsung or Zebra devices. After you select the OEM, you will see additional profiles and settings displayed that are unique to either OEM.

However, it is strongly advised to use Samsung KSP or Zebra OEMConfig to configure OEM-specific settings as these apps provide zero-day support for OEM-specific device configurations. For more info on OEMConfig, jump to the OEMConfig/AppConfig section of this guide.

3. Select the Add button next to the desired profile payload and configure the settings as desired. You can use the drop-down and preview the profile configuration settings before selecting Add. A detailed description of each profile’s payload is mentioned in the next section.
4. After the profile is configured, click Next to configure the general Assignment and Deployment profile settings as appropriate.

5. Configure the following settings:

Settings	Description
Assignment
Smart Group	Select the desired Smart Group(s) that should receive the profile.
Allow Exclusion	When turned on, a new text box Exclude Group displays. This text box allows you to select those smart groups you want to exclude from the assignment of the device profile.
Deployment
Assignment Type	Determines how the profile is deployed to devices: Auto – The profile is deployed to all devices. Optional – An end user can optionally install the profile from the Self-Service Portal (SSP) in the Workspace ONE Intelligent Hub app, or it can be deployed to individual devices at the administrator’s discretion. End users can also install profiles representing Web applications, using a Web Clip or a Bookmark payload. And if you configure the payload to display in the App Catalog, then you can install it from the App Catalog. Compliance – The profile is applied to the device by the Compliance Engine when the user fails to take corrective action toward making their device compliant.
Allow-Removal	Determines whether the end user can remove the profile. Always – The end user can manually remove the profile at any time With Authorization – The end user can remove the profile with the authorization of the administrator. Selecting this option adds an account Password text box. Never – The end user cannot remove the profile from the device.
Managed By	The organization group with administrative access to the profile.
Install Area Only	Turn on to display geofencing option: Install only on devices inside selected areas: Enter an address anywhere in the world and a radius in kilometers or miles to make a ‘perimeter of profile installation’.
Schedule Install Time	Turn on to configure time schedule settings: Turn on Scheduling and install only during selected time periods: Specify a configured time schedule in which devices receive the profile only within that time frame.
Preview
View Device Assignment	After you make the desired Smart Group(s) selection, you can preview a list of all assigned devices, taking all the smart group assignments and exclusions into account.

6. Click Save & Publish.

For a detailed description of available Profile Payloads and their corresponding configuration settings, see How to Configure Android profiles on Omnissa Docs.

Configure OEM-Specific Policies
OEMConfig is a standard solution for Android original equipment manufacturers (OEM) to provide additional management capabilities to administrators, on top of what is natively offered by the Android Enterprise. It is an application that is built and maintained by the OEM and hosted on Google Play. The application takes advantage of AppConfig standards by allowing the administrator to dynamically configure any setting desired that the OEM offers in a data-driven user interface. Because the settings are data-driven and app-based, console upgrades are not required to access the latest settings offered by the OEM.

To apply configurations for OEM-specific devices, you must add the relevant OEMConfig application from the Google Play store and send the configuration settings.

When assigning the OEM-specific application, on the Application Configuration tab, you will see configurable settings for that OEM.

The following images depict the Application config confirmation setting options. In the next part of this tutorial, we cover how to deploy applications in the next section of this guide and touch more on OEMConfig as part of application deployment.

Android Application Management

This exercise helps you to get started with the deployment and maintenance of mobile applications on Android devices. It will introduce you to the various app delivery and update mechanisms Workspace ONE UEM offers for Android app management.

Prerequisites

Before you can perform the steps in this exercise, you must meet the following requirements:

• Complete the Android EMM registration for the destination OG in your Workspace ONE UEM console
• Enroll Android devices into Workspace ONE UEM using any of the three enrollment options (Work-Managed, BYOD, or COPE)

Workspace ONE Tunnel

Workspace ONE Tunnel enables secure access for mobile workers and devices. Users have a simple experience and need not enable or interact with Tunnel, and IT organizations might take a least-privilege approach to enterprise access, ensuring only defined apps and domains have access to the network.

Workspace ONE Tunnel provides industry-best security and builds on TLS 1.2+ libraries, implements SSL Pinning to ensure no MITM attacks, and includes client certificates on the allowlist to ensure identity integrity. Combined with explicit definitions of managed applications and integration with the Workspace ONE compliance engine, Tunnel can help customers attain Zero Trust goals for their workforce.

For more information on Workspace ONE Tunnel, see:

Use Managed Google Play to Deploy Public Apps

You can use Workspace ONE UEM to manage the deployment and maintenance of publicly available Android applications via the managed Google Play Store. Public apps can be installed and updated on Work Managed devices and in the Work Profile container of BYOD and COPE devices. On Android 11 and older COPE devices, public apps can also be pushed to the personal side.

This configuration is not available for closed network/AOSP devices. 

To add public apps from the managed Google Play store to Workspace ONE UEM and then install them on your enrolled Android devices, perform the following steps:

1. Log in to your Workspace ONE UEM console and select the destination OG.
2. Navigate to Resources > Apps > Native and select the Public tab.
3. Click Add Application.

4. Select Android from the drop-down menu.
5. Enter the name of the application to search in managed Google Play. In this example, we are searching for Workspace ONE Boxer.

6. Select the desired application from the managed Play Store iFrame pop-up window.

7. Click Approve.

8. Review app permissions in the pop-up window that follows, then click Approve.

9. Set approval settings and notification parameters for handling new app permissions for the selected app, then click Done. This setting defines how new app runtime permissions are handled when an updated version of the same app requests a new app runtime permission.
10. Enter details in the Edit Application section with appropriate information (optional) in the Details, Terms of Use, and SDK tabs respectively, then click Save & Assign.

11. Enter the appropriate information in the Distribution section of the Assignment page.

12. (Optional) From the Tunnel section, select the Workspace ONE Tunnel Profile used to configure per-app VPN/MobileSSO settings.

13. (Optional) Select the Application Configuration section, then enable Send Configuration to send managed AppConfig settings to the devices, if applicable. For more information, jump to the OEM-specific Managed Configurations section of this guide.
14. Select the Smart Group(s) of devices to assign this app in the Assignment Groups section before you click Create. You can configure the following options:

1. App Delivery Mechanism: Deploy the application automatically (Auto) or manually (On-Demand) when needed.
2. Auto-Update Priority: When assigning this application, an auto-update priority can be given to Google Play to raise or lower the priority with which automatic app updates are installed. Postponed updates will be delayed for 90 days.                                                        

High-priority updates will be installed within minutes of being available.  

Apps not using the default auto-update priority will ignore the Public App Auto-Update Profile if one is assigned.

Note: Assignments for supported Android apps can also accompany sending managed application configurations. For more information demonstrating this procedure, jump to the OEMConfig/AppConfig section of this guide.

15. Create additional assignments, if required, on the following page. Then set the priority of the assignments. When you have added all assignments, click Save.

16. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

The public app is now published to your devices.

Use Google Play to Deploy Private Apps

You can publish applications developed by your organization or the applications that are developed specifically for your organization can be hosted and distributed through the managed Google Play Store. When adding a public app on an organization group with Android Enterprise enabled, the iFrame is loaded and the private apps menu is available on the left side-panel. Additional information such as a description, images, and more can be added in the Advanced options after uploading your private app’s .apk file. These applications are visible to devices managed by the enterprise but are not available publicly outside the enterprise.

Note: Private apps uploaded through the iFrame can never be visible in the public Google Play Store. If your application might eventually be made public for use outside your organization, it is recommended to publish the application directly in the Google Play Developer Console instead of using the iFrame.

A few considerations to keep in mind:

1. You must verify that the private apps APK file with the same application ID is not published and publicly available in the Google Play store.
2. Google publisher account has a limit of 15 APKs per day which means that you can only upload up to 15 applications per day.
3. This configuration is not available for Closed Network/AOSP devices.  

To upload private apps to the managed Google Play store using Workspace ONE UEM and then install those apps on your enrolled Android devices, perform the following steps:

1. Navigate to Resources > Apps > Native > Public > Add Application.

2. Select Android as the Platform and leave the name blank. Click Next.

3. Select the Private Apps tab from the left menu, then click the add (+) button.

4. Upload your private app’s APK file and give it a name. Then click Create.

Note: After the APK file is uploaded and accepted, it will be listed under the Private apps section. It can take up to 10 minutes until the app is published on the managed Google Play Store.

You also can add a detailed description, screenshots, and so on from the Advanced Editing Options menu.

5. Select the Private app (after it is published) to add the app to the Workspace ONE UEM console.

6. Fill out the Edit Application section with appropriate information (optional) in the Details, Terms of Use, and SDK tabs respectively, then click Save & Assign.

7. Enter the appropriate information in the Distribution section of the Assignment page. Then select the Smart Group(s) of devices to assign this app in the Assignment Groups section. You can configure the following options:

1. App Delivery Mechanism: Deploy the application automatically (Auto) or manually (On-Demand) when needed.
2. Auto-Update Priority: When assigning this application, an auto-update priority can be given to Google Play to raise or lower the priority with which automatic app updates are installed. Postponed updates will be delayed for 90 days. High-priority updates will be installed within minutes of being available. Apps not using the default auto update priority will ignore the device-wide Public App Auto-Update Profile if one is assigned.

8. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. After you have added all assignments, click Save.

9. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

The private app is now published to your devices.

Use Google Play to Deploy Web Apps

Note: This procedure is not available for Closed Network/AOSP devices.

To create Web apps in the managed Google Play store using Workspace ONE UEM, and then deploy them to your enrolled Android devices, perform the following steps:

1. Navigate to Resources > Apps > Native > Public > Add Application.

2. Select Android as the Platform and leave the name blank. Click Next.

3. Select Web apps from the left menu, then click the add (+) button.

4. Enter the appropriate details of the Web app in the Title and URL bars, then set the optional Display and Icon settings. Click Create when complete.

5. Select the Web app to add it to your UEM console.

6. Navigate to Resources > Native > Apps > Public > Add Application. Select Android as the platform, then select Import from Play.

7.  Select the check box for the Web app listed and then click Import.
8. After the app is imported, the Web app is listed in the Resources > Apps > Native > Public > List View in your UEM console. Click Assign.

9. Enter the appropriate information in the Distribution section of the Assignment page. Then select the Smart Group(s) of devices to assign this app in the Assignment Groups section. Click Create.
10. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. Click Save.
11. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

The Web app is now published to your devices. 

Use Workspace ONE to Deploy Internal Applications

You can use Workspace ONE UEM to distribute, track, and manage your internal Android applications. These are applications built in-house and not hosted on Google Play Store. You can upload the application’s APK file(s) directly to the Workspace ONE UEM console for deployment.

Note: This procedure is only available on Work Managed Android devices including AOSP/Closed Network Work Managed Android devices.

To create Web apps in the managed Google Play store using Workspace ONE UEM, and then deploy those apps to your enrolled Android devices, perform the following steps:

1. Navigate to Resources > Apps > Native > Internal > ADD > Application File.
2. Click Upload to either upload the application’s APK file or to enter the URL of the hosted application file. Then click Save.

3. Enter the appropriate application details, then click Save & Assign.

4. Enter the appropriate information in the Distribution section of the Assignment page. Then select the Smart Group(s) of devices to assign this app in the Assignment Groups section. Click Create.
5. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. Click Save.
6. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

The Internal app is now published to your devices.

Update Policy

On managed Android devices, public applications are installed on the device through the managed Google Play Store. Likewise, Google Play can automatically update those applications over time as new versions are published to the Play Store by the developer. This section walks you through the different settings on the Workspace ONE UEM console to help you manage how these applications are automatically updated. It also provides a background on how these settings can be utilized for an application or a group of applications.

Auto Update Priority

With the release of Workspace ONE UEM 2209, administrators can use the Application auto update priority settings to prioritize the application installation. This configuration allows administrators to configure per-application auto update while overriding the global device policy set by the public app auto update profile.

The public app update profile is a Global policy that can be set to control auto update behavior for all public applications which are currently managed by Workspace ONE UEM. For more information, check Public App Auto Update in the documentation.

By setting the Auto Update Priority of an application, an administrator can override the global policy set in a public app auto update profile assigned to the same device.

Auto Update priority has three configurations available:

1. Default
2. High Priority
3. Postpone

Default

By selecting the Default configuration, the application will adhere to the global update policy set via the public app auto update profile. If such a profile has not been configured, then the application will follow the Google Play Store’s default update policy. For more details, see Manage App Updates on Google support.

High Priority

Selecting High Priority mode for an application update will enforce Managed Play to automatically update the application update on the device as and when a new version is published to the Play Store. The app update will be carried out without considering the status of the device. This could lead to end users being interrupted while the application gets updated.

Postpone

The Postpone mode can be used to delay the application update for a period of time. On an Android Enterprise device, the managed Play Store application periodically checks if there are new versions of an application published by the developer. When Play Store discovers a new update, it will normally proceed to schedule that update based on the policies set on the device. If Auto Update Priority is set to Postpone for an application, the next time the managed Play Store app discovers a new update, it will postpone the update for 90 days. The application is then updated once the 90-day period is over or when the Auto Update Priority is set back to Default or High Priority. This mode is typically used when you want to carry out testing of a new application version prior to publishing it to all devices.

A few points to note:

• When the managed Play Store application installs an application update, it will always install the latest version of the application. This means that when the 90-day postponement period expires, the device will update to the latest application version that is published in the Play Store at that time. If you are postponing application updates to test a specific version of the app, the best practice is to set the Auto Update Priority for this application back to Default or High Priority to ensure that devices upgrade to this tested version. This way, devices upgrade to the application version that you tested while it is still the latest version published in the Play Store.
• Devices with outdated versions of the application might not adhere to the 90-day postponement update policy. This is because the managed Play Store might have already discovered a new version of this application available in the Play Store and have scheduled an update for the same. For these reasons, organizations looking to upgrade devices only to versions of applications that they have tested can follow the flow chart below and cycle between Postpone and High Priority modes to stop and start updates as needed.

Let’s consider Acme Corp as an organization managing Android devices that requires updates for applications such as:

1. Browser
2. Third-party application
3. Internal application published using Managed Play Store

The three applications listed have separate update requirements, the browser update can be carried out by the Public App Auto Update profile which can be set to update the application using a specific time such as 10 PM to 6 AM.

Figure: Configure Public App Auto Update payload

If the browser application has a critical update and you cannot wait for the update window, then the High Priority update setting can be utilized to ensure the application is updated immediately. Once all the devices have the updated version of the application, the App Auto update priority setting can be reset to default.

Say that the Internal application developed by Acme Corp is a critical app and is required to be updated on an immediate basis; in this scenario, you can set Auto Update priority to High priority which will ensure that the application is updated on the device.

Third-party application releases are not controlled by Acme Corp. In this case, the administrator can set the Auto update priority to postpone such that Acme Corp gets sufficient time to carry out tests and only when the release is validated, Auto Update Priority settings can be changed to High priority or Default based on the urgency.

If Acme Corp has a requirement to not allow automatic updates for any managed applications except for certain applications, Acme Corp can configure the Public Apps Auto Update Policy to Never auto update. They could then use the Auto Update Priority setting to override the global policy set by the profile and push the update using High Priority mode for the application which needs to be automatically updated on the devices.

Application Permission

In Workspace ONE UEM, the Application Permission profile allows administrators to set permissions for public applications managed within the platform. These permissions define what actions users can perform with the applications, such as installation, updating, or uninstallation. However, when it comes to internal applications, which are applications developed internally or obtained from sources other than public app stores, setting permissions requires a slightly different approach.

Custom XML is the method used to configure settings for internal applications in Workspace ONE UEM. Administrators can create custom XML files containing specific configurations and then upload these files to the Workspace ONE UEM console to apply the desired settings to internal applications.

This section will help you configure the permission profile and also cover the custom XML configuration for internal applications.

Android Permission Types

Android has different types of permissions which are categorized as:

1. Install time permission
2. Runtime permission

Among the listed permission types, Workspace ONE UEM can only manage the runtime permissions for applications on the device. Administrators can set a global policy to silently grant all or deny all runtime permissions requested by an application. Administrators can also add exceptions to this global policy by granting or denying specific runtime permissions for specific apps.

When administrators define exceptions in the permissions profile UI for a public application, the Workspace ONE UEM console shows the administrator a list of all the permissions declared in the application’s manifest. To learn if a permission is a runtime permission or not, you can check Manifest Permissions in the Android documentation.

However, if you are unable to determine if the permission is a runtime or other type of Android permission, an administrator will have to carry out a trial-and-error method to configure the permission for the application.

To learn more about Android permission types, check Android Permission types in the Android documentation.

Permission Profile Configuration for Public Application

Although we will cover the configuration steps for a permission profile, it is important to understand the expected behavior of a Global Policy vs Exceptions.

If you set up a global policy to either allow or deny all permissions, those permissions will be applied only when the application actively requests them. However, if you use the exception feature to configure permissions, they will be granted or denied proactively regardless of whether the application asks for them or not.

Configuring permission profiles for public applications within Workspace ONE UEM involves establishing the rules that govern user actions with those apps on managed devices.

Perform the following steps:

Navigate to Resources > Profiles > Add > Add Profile.

 Select the Android platform and enter the details as follows:

1. Profile Name, such as Application Permission.
2. Permission Policy – Select either Deny all permissions, Grant all permissions, or Prompt user for permission.
3. To configure permissions for a specific application, you must add an exception to the global policy. Enter the application name to which you would like to add additional permission for. In this case, we have added Google Chrome.

Note: The public application needs to be added to the Workspace ONE UEM console prior to this step.

Let’s consider Acme Corp would like to restrict certain user actions such as Chrome application from accessing contacts and recording audio. 

The administrator can configure the Permission type to Deny permission.

After permissions have been enabled, click Next and Save & Publish the profile.

Validate Permission on the Device

To validate if the permissions have been configured on the device, the user can navigate to Settings > Apps > Select Application (Google Chrome) > Permissions.

The user is presented with the following app permissions options:

1. Allowed
2. Ask every time
3. Not allowed

Figures a-e:

a: Displays the app permissions set for Google Chrome

b: Displays the microphone permission disallowed by admin

c: Displays the microphone icon is no longer visible 

d: Displays the contact permission disallowed by admin

e: Displays the Prompt user can see when clicking the microphone symbol

If the admin set the permission to Prompt user for permission for Microphone, the end user would see the prompt as seen in Image e.

Permission Profile Configuration for Internal or Unmanaged Application

The process for configuring runtime permissions for an internal or unmanaged application differs from the process for a public application. Unmanaged applications usually consist of system/pre-installed applications, such as Google Chrome on a GMS Android device. Currently, for these applications, we do not have an option to directly pull a list of permissions the applications use and configure them using the Console UI as we did for public applications. To configure app permissions for an internal/unmanaged application, we must use a custom XML and publish it using a custom settings profile to devices.

To configure permissions for the Workspace ONE Web application, perform the following steps:

1. Extract the manifest of the application (This can be done using a third-party tool).
2. The runtime permissions in the extracted manifest will normally start with “android.permission” (e.g. android.permission.INTERNET)
3. Add {"name":" Permission Name","value":"0"} syntax to all the permissions.
4. Set value to either:
   
   • 0 – Prompt
   • 1 – Grant
   • 2 - Deny
5. The Permission array should look like the following:
   
   [{"packageName":"com.airwatch.browser","permissions":[{"name":"android.permission.INTERNET","value":"0"},{"name":"android.permission.ACCESS_NETWORK_STATE","value":"1"},{"name":"android.permission.READ_PHONE_STATE","value":"0"},{"name":"android.permission.WRITE_EXTERNAL_STORAGE","value":"0"},{"name":"android.permission.READ_EXTERNAL_STORAGE","value":"0"},{"name":"android.permission.FOREGROUND_SERVICE","value":"0"},{"name":"android.permission.ACCESS_FINE_LOCATION","value":"0"},{"name":"android.permission.ACCESS_WIFI_STATE","value":"0"},{"name":"com.airwatch.sdk.BROADCAST","value":"0"},{"name":"android.permission.VIBRATE","value":"0"},{"name":"android.permission.CAMERA","value":"2"},{"name":"android.permission.CHANGE_NETWORK_STATE","value":"0"},{"name":"android.permission.WAKE_LOCK","value":"0"},{"name":"com.airwatch.email.permission.ACCESS_PROVIDER","value":"0"},{"name":"com.android.alarm.permission.SET_ALARM","value":"0"},{"name":"com.google.android.c2dm.permission.RECEIVE","value":"0"},{"name":"android.permission.RECEIVE_BOOT_COMPLETED","value":"0"},{"name":"android.permission.USE_BIOMETRIC","value":"0"},{"name":"android.permission.USE_FINGERPRINT","value":"0"}]}]
6. The requirement here is to block the camera, so the value set is 2.
7. Encode the permission array using base64.
8.  Take the encoded string and insert it into the applevelruntimepermission value field of the following xml: 
   
   <characteristic uuid="ece876fd-da7d-424f-9bab-85a1b483e95d" type="com.airwatch.android.androidwork.permissions" target="1"><parm name="MasterRuntimePermission" value="1" type="integer" /><parm name="AppLevelRuntimePermissions" value="<insert_encoded_string_here>" type="string" /></characteristic>
9. Add a new profile on the Workspace ONE UEM console.
10. Add a custom settings payload and insert the XML.
11. Save and Publish the profile.

Validate Permission on the Device

To validate if the permissions have been configured on the device, the user can navigate on the device to Settings Apps > Select Application (Web) > Permission.

The user is presented with which app permissions are allowed, ask every time, and not allowed.

                  

A                                          B

Figure A: App permissions seen for the Web application

Figure B: Camera permission disallowed

OEM-Specific Managed Configurations

AppConfig enables you to send apps together with their configuration profiles when distributed through the managed Google Play Store. This allows you to deploy application-specific managed configurations with the managed app remotely.

OEMConfig is a standard solution for Android OEM to provide additional management capabilities to administrators, on top of what is natively offered by the Android Enterprise. It is an application that is built and maintained by the OEM and hosted on Google Play. The application takes advantage of AppConfig standards by allowing the administrator to dynamically configure any setting desired that the OEM offers in a data-driven user interface. Because the settings are data-driven and app-based, console upgrades are not required to access the latest settings offered by the OEM.

Use OEMConfig applications to add, create, and customize OEM-specific settings for Android Enterprise devices. The application is published to devices through UEM and silently installed using Android Enterprise Managed Google Play. Customized settings are delivered to the application during or post-install, and the application calls the corresponding, proprietary APIs on the device. Different OEMs can include different settings, and these settings can vary depending on the management mode (Work Managed, Work Profile, or COPE). The available settings depend on what the OEM includes in their OEMConfig app. Contact your OEM vendor for more information on their support of OEMConfig.

Before you start configuring OEMConfig on your devices, consider the following caveats:

• If any of the OEM settings are blank or are not selected, the UEM console does not send the key-value pair to the device, and the setting is excluded from the configuration.
• An OEMConfig app is built by the OEM and uploaded to Google Play. If it is not on Google Play, contact the OEM for more information.

Prerequisites

Before you can perform the steps in this exercise, ensure that you have the following:

• Workspace ONE UEM 1907 or later
• Complete the Android EMM registration for the OG in your Workspace ONE UEM console
• Enroll Android devices into Workspace ONE UEM in either a Work Managed or Work Profile state

 Deploy Samsung KNOX Services Plugin (KSP)

The Knox Service Plugin (KSP) is an administrative tool for configuring Knox Platform for Enterprise features on Samsung Android devices using Android Managed Configurations.

This requires the use of a Knox premium license activation, which is free. For more information, see Knox Platform for Enterprise licenses in the Samsung documentation.

Certain deployment scenarios might require the KSP app to be pushed as an internally-managed application. In such a scenario, you must push a profile containing the XML file to configure the KSP application. See the Omnissa blog Deploying the Knox Service Plugin (KSP) as an internally-managed application.

To add the Samsung KSP application to your Workspace ONE UEM, perform the following steps:

1. Log in to your Workspace ONE UEM console and select the destination OG.
2. Navigate to Resources > Apps > Native > Public > Add Application.
3. Configure the following settings, then click Next:
   
   1. Managed By – The OG with administrative access to the profile.
   2. Platform – Select Android from the drop-down menu.
   3. Source – Select Search App Store.
   4. Name – Enter Samsung KSP.
       

4. Click Approve and click Select for the Knox Service Plugin.

5. Under Assignments, navigate to the Application Configuration tab, and activate the Send Configuration toggle. 
6. Enter the KPE license key and then select the desired KSP configuration settings. For detailed information on Knox Service Plugin’s features, see Schema structure in the Samsung Knox Documentation.

7. Select the Assignment Group(s) that will receive the KSP app in the Distribution tab. Then click Create.
8. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. Click Save.
9. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

Samsung KSP along with its configuration is now installed on your devices.

 Deploy Zebra OEMConfig

Zebra OEMConfig is an administrative tool for configuring Zebra Mobility Extension (MX) features on Zebra Android devices using Android Managed Configurations.

Zebra OEMConfig interfaces with Zebra Mobility Extensions Management System (known simply as MX), an XML-based communication framework for managing the capabilities and behaviors of Zebra Android devices.

At the time of writing, there are two versions of Zebra OEMConfig:

• Legacy Zebra OEMConfig: not compatible with devices running Android 13 and later.
• Zebra OEMConfig powered by MX: compatible with Zebra devices running Android 11 and later.
• Both versions of the Zebra OEMConfig app work on Android 11.

For more information, see About OEMConfig in the Zebra documentation.

To add the Zebra OEMConfig application to Workspace ONE UEM, perform the following steps:

1. Log in to your Workspace ONE UEM console and select the destination OG.
2. Navigate to Resources > Apps > Native > Public > Add Application.
3. Configure the following settings, then click Next:
   
   1. Managed By – The OG with administrative access to the profile.
   2. Platform – Select Android from the drop-down menu.
   3. Source – Select Search App Store.
   4. Name – Enter Zebra OEMConfig.
4. Click Approve and select the appropriate version of Zebra OEMConfig depending on your device OS.

5. Under Assignments, navigate to the Application Configuration tab, and activate the Send Configuration toggle. 
6. Select and configure the desired OEM settings. For detailed information on Zebra OEMConfig features, see Zebra Managed Configurations in the Zebra documentation.

7. Select the Assignment Group(s) that will receive the OEMConfig app in the Distribution tab. Then click Create.
8. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. Click Save.
9. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

Zebra OEMConfig along with its configuration is now installed on your devices.

 Deploy Honeywell UEMConnect

The Honeywell UEMConnect is an administrative tool for configuring Honeywell-specific features on Honeywell Android devices using Android Managed Configurations.

To deploy the Honeywell UEMConnect application to your devices through Workspace ONE UEM, perform the following steps:

1. Log in to your Workspace ONE UEM console and select the OG.
2. Navigate to Resources > Apps > Native > Public > Add Application.
3. Configure the following settings, then click Next:
   
   1. Managed by – The OG with administrative access to the profile.
   2. Platform – Select Android from the drop-down menu.
   3. Source – Select Search App Store.
   4. Name – Enter Honeywell UEMConnect.
4. Click Approve and click Select for the Honeywell UEMConnect app.

5. Under Assignments, navigate to the Application Configuration tab, and activate the Send Configuration toggle. 
6. Select and configure the desired OEM settings. For detailed information on Honeywell UEMConnect features, see the UEM Connect User Guide in the Honeywell documentation.

7. Select the Assignment Group(s) that will receive the UEMConnect app in the Distribution tab. Then click Create.
8. Create any additional assignments, if required, on the following page. Then set the priority of the assignments. Click Save.
9. The Preview section displays a list of all assigned devices. Verify the selection and then click Publish.

Honeywell UEMConnect and its configuration is now installed on your devices.

Managing Operating System Updates with Workspace ONE UEM

Android devices can receive and install over-the-air (OTA) updates to the system and application software. Usually, Android notifies the device user that a system update is available, and the device user can install the update immediately or later.

Using Workspace ONE UEM, an IT admin can manage system updates for the device user. Granular controls for deploying OS updates are usually device and OEM-specific. However, the following control options are available to Work Managed and Work Profile devices through Workspace ONE UEM integration with Android Enterprise:

1. In the Workspace ONE UEM console, navigate to Resources > Profiles & Baselines > Add > Add Profile > Android.
2. Select the System Updates payload.
3. Use the drop-down menu for Automatic Updates to select the update policy.

Setting	Description
Automatic Updates (Android 6.0 and later Work Managed and COPE devices)	Install Updates Automatically: Automatically install updates when they become available.
	Defer Update Notifications: Defer all updates. Send a policy that blocks OS updates for a maximum period of 30 days.
	Set Update Window: Set a daily time window in which to update the device.
Annual System Update Freeze Periods (Android 9.0 and later Work Managed and COPE devices)	Device owners can postpone OTA system updates to devices for up to 90 days to freeze the OS version running on these devices over critical periods (such as holidays). The system enforces a mandatory 60-day buffer after any defined freeze period to prevent freezing the device indefinitely.
	During a freeze period: Devices do not receive any notifications about pending OTA updates. Devices do not install any OTA updates to the OS. Device users are not able to manually check for OTA updates.
Freeze Period	Use this field to set freeze periods, in month and day, when updates cannot be installed. When the time of the device is within any of the freeze periods, all incoming system updates, including security patches, are blocked and cannot be installed. Each individual freeze period is allowed to be at most 90 days long and adjacent freeze periods need to be at least 60 days apart.

Deploy Samsung E-FOTA Updates

Samsung provides an Enterprise Firmware Over-The-Air (E-FOTA) tool for firmware management on supported devices running KNOX v2.5 or later. It provides advanced control over system software updates across Samsung devices. Admins can also connect the Samsung E-FOTA console with their Workspace ONE UEM to sync device and group information.

Before you can perform the steps in this exercise, you must:

• Obtain the necessary Samsung E-FOTA licenses.

Integrate Samsung E-FOTA One Console with Workspace ONE UEM

To configure an API key to allow Samsung E-FOTA One to establish a connection with the Workspace ONE UEM server, perform the following steps:

1. From your Workspace ONE UEM console, navigate to Groups & Settings > All Settings > System > Advanced > API > REST API.

2. Click Add and specify the Service Name, Account Type (Admin), then click Save.
3. In your Samsung KNOX console, launch the E-FOTA module, then navigate to EMM groups > Connect EMM >Workspace ONE UEM.
4. Enter your login credentials, supply the REST API URL and the API Key. Then click Connect to load the smart groups from your Workspace ONE UEM account.
5. Click Sync next to the appropriate smart group(s) from the list displayed on the next page to sync them with the E-FOTA console.
6. Click Add E-FOTA Groups to complete the sync.

After the groups and device information are synced with the E-FOTA console, you can select the appropriate group of devices to deploy the firmware updates. To learn more about Samsung E-FOTA One, see the Knox E-FOTA admin guide.

Deploy Zebra LifeGuard and OS Updates

Zebra LifeGuard is an operating system update program for Zebra Android devices meant to increase the lifecycle of a Zebra device. Administrators can install these LifeGuard update packages on enrolled Zebra devices using Workspace ONE UEM.

For managing OS updates on Zebra devices, see Zebra Android OS Update Methods.

Workspace ONE Relay Server Integration

Relay servers are used to make product provisioning content available for local devices over the WLAN. They act as a content distribution node that provides more bandwidth and data use control in Workspace ONE UEM.

Relay servers act as a proxy between the Workspace ONE UEM server and the rugged device to transfer larger files like operating system update files. This proxy can act as an FTP / Explicit FTPS / SFTP or HTTPS server to endpoints, by distributing product provisioning content to the device, making it available for download and installation.

Relay servers also add redundancy by providing a fallback feature in case a relay server is not reachable, by making the device fall back to the next available relay server in the hierarchy until a working relay server is found. If a working relay server is not available, the content is then directly downloaded from the Workspace ONE UEM server.

Use of a relay server is optional for content distribution. In cases where relay servers are not available or not configured, the device will download product provisioning content directly from Workspace ONE UEM.

For more information about configuring relay servers, see Relay Servers on Omnissa Docs.

Deploy Honeywell OS Updates

System update files can be pushed and installed on Honeywell Android devices using Workspace ONE UEM. This procedure walks you through deploying OS updates on Honeywell Android devices using Workspace ONE UEM.

Before you can perform the steps in this exercise, you must:

• Download and install the Honeywell Enterprise Provisioner software on your Windows machine. For more information, see What is Enterprise Provisioner in the Honeywell documentation.
• Obtain the latest Enterprise Provisioner configuration bundle for the devices in question from the Honeywell downloads site.
  Ensure that the correct bundle is selected based on the appropriate device chipset number (HON660 or HON4290), OS version, and Build number.
• Install the appropriate version of the Workspace ONE Honeywell Service app on enrolled devices. There are three Honeywell Service APK files available for different device models:
  
  • Next-Gen Honeywell devices (newer models including CT40 & CT60).
  • Older Honeywell devices (such as EDA51).
  • Intermec devices.

 To install OS updates on Honeywell Android devices, follow these steps: 

1. Download the appropriate OS update (.zip) file from the Honeywell download site and save the file locally. Rename the file with a friendly name, for example, OSUpdateFile.zip.

2. In the Honeywell Enterprise Provisioner application, navigate to the Provisioning tab. Make sure the Download files from Enterprise Provisioner check box is deselected.

3. Select Create Task, then select Software Update task from the drop-down menu. Next, specify the destination path of the OSUpdateFile.zip, as shown in the screenshot.

4. Navigate to Files > Export, then select the Tasks check box listed under the Provisioning section. Then select Export in Export options.
5. Save the Provisioner.xml file locally on your computer.

6. In Workspace ONE UEM, navigate to Devices > Provisioning > Components > File/Actions > Add File/Actions > Android.

7. Complete the sections in the General tab, then navigate to the Files tab.

8. Upload the OSUpdateFile.zip, then click Save.

9. Enter the desired Download Path. The download path entered here must match the download path mentioned in the Enterprise Provisioner Device Settings Package (e.g., /sdcard/Download/OSUpdateFile.zip). Then click Save.
10. Click Add Files again and upload the Provisioner.xml file previously generated in step 5. Next, set the path of this file to sdcard/Honeywell/Provisioner.xml. Then, click Save.

11. Navigate to the Manifest tab.

12. Select Run Intent as the Action(s) to Perform and enter the following command line intent argument to run:
    mode=explicit,broadcast=true,package=com.honeywell.tools.ezconfig,class=com.honeywell.tools.ezconfig.EZConfigBroker,action=com.honeywell.ezconfig.intent.action.IMPORT_XML,extraString=path=/sdcard/honeywell/Provisioner.xml
    Ensure that the path of the Provisioner.xml matches the path selected in step 10.
13. Save the File/Action Component.

14. Navigate to Devices > Provisioning > Product List View > Add Product > Android.

15. Complete the General tab with the Name and Description of the Product. Then select the Smart Groups to assign the Product, as well as configure Assignment Rules. Navigate to the Manifest tab.

16. Select File/Action Install as the Action(s) to Perform, then select the File/Actions component created in step 13.

17. Complete the additional tabs as needed, then click Activate to proceed to View Device Assignment.

18. Confirm the device assignment and click Activate.

The OS update is now installed on the device. 

Migrating Android Device Administrator (Legacy) to Android Enterprise

Android (Legacy), also known as device administrator, is the legacy method of managing Android devices. Android Enterprise Work Managed and Work Profile modes were introduced from Android 5.0. Workspace ONE UEM can help migrate devices from using Android (Legacy) management to Android Enterprise to take advantage of device functionality for the enterprise.

A common use case for this migration might be purpose-built devices like retail scanners or shift workers, that want to migrate over and get consistent functionality across the device fleet.

See Legacy Android Migration on Omnissa Docs for details on migrating Legacy Android Device Administrator to Android Enterprise.

Summary and Additional Resources

 This tutorial took you through the fundamentals of the configuration and management of Android devices using Workspace ONE UEM. Throughout the tutorial, we explored the various management capabilities available on the Android operating system.

Throughout this tutorial, we delved into the different management modes and then investigated different device management features available based on device manufacturers (OEMs). We also learned about the tools available in Workspace ONE UEM that help streamline Android device management.

Additional Resources

For more information about Windows Modern Management with Workspace ONE, you can explore the following resources:

https://techzone.omnissa.com/anywhere-workspace

Changelog

The following updates were made to this guide:

Date	Description of Changes
2024/09/04	Updated links and references to latest documentation
2024/03/04	Added new sections: Application - Update Policy, Auto Update Priority, Application Permission, Permission Profile Configuration for Internal or Unmanaged Application.
2023/09/20	Guide was published.

About the Author and Contributors

This tutorial was written by:

• Wasif Syed,  Solution Engineer, Omnissa
• David Dwyer, Senior Solutions Engineer, Omnissa
• Siddesh Patil, Senior Technical Marketing Architect, Omnissa

Feedback

Your feedback is valuable. To comment on this paper, contact Omnissa Technical Marketing at tech_content_feedback@omnissa.com.