Overview

Any deployment of enterprise devices requires some control over which features of the device the user is able to access.

In general, you want to restrict an enterprise user in the following ways:

  • Only allow a specific set of named applications to be run.
  • Prevent installation or uninstallation of applications
  • Prevent access to device settings or prevent changing existing settings e.g. wireless

There may be additional considerations for your enterprise deployment:

  • The device may be designed for direct customer interaction (for example a check-in kiosk or audio tour guide)
  • You may have a variety of Android versions in your deployment and the solution needs to run across all target devices.
  • You may or may not be using a third-party Enterprise Mobility Manager (EMM) to facilitate device provisioning.

Existing solutions

There are a number of solutions to lock down your device, all of which are supported on Zebra devices. This blog will contrast these solutions to enable you to choose the solution that best fits with your deployment:

Android logo.png

Android’s APIs and workflows aimed at “Single-Purposes Devices” or “corporate-owned, single use (COSU)” devices.

Android has a set of supported APIs and modalities introduced in 5.0 which receive updates with each new Android release.  These features can be considered enterprise ready from 6.0 onwards.

https://developer.android.com/work/cosu.html
ehs-logo.png

Enterprise Home Screen (EHS).

An application provided free of charge by Zebra; this is a replacement home screen for your device and provides extensive configuration to restrict what the end user is able to do on the device.

http://techdocs.zebra.com/ehs/2-5/guide/about/
mx logo.png

Mobility eXtensions (MX).

Available on all Zebra devices, MX provides an extensive feature set which includes the ability to control which applications on the device can be run or installed as well as locking down access to device settings.

http://techdocs.zebra.com/mx/overview/

http://techdocs.zebra.com/emdk-for-android/6-3/mx/accessmgr/

 

Clearly there will be some overlap between these offerings.  The differences are summarized in the below table:

 

 

Android logo.pngehs-logo.pngmx logo.png
Restrict applications runningYes, via lock task modeYes, by only displaying enabled applicationsYes, by application whitelisting in the AccessManager
Restrict application installationNo, can still install via adb or programmatically through DPC but user ability is restricted as they cannot escape the current appNot explicitely.  Can disable USB to prevent sideloading.  Can prevent access to Play store and web to prevent download.Yes, by application whitelisting
Restrict access to device settings.Yes, via lock task mode.Yes, via a configuration settingYes, via the AccessManager
Restrict access to settings via the notification shade.Yes, via lock task mode.Not on all devices, recommendation is to use MX UiManager insteadYes, via the UiManager
Kiosk mode support (prevent back, home and recent buttons)Yes, via lock task mode.Yes, via a configuration settingNo
GMS / Non-GMS?GMS OnlyBoth GMS and non-GMSBoth GMS and non-GMS
Zebra / Non-Zebra?No restrictionZebra devcies onlyZebra devcies only
Earliest Android version supported6.0 for Enterprise use casesEarly releases of EHS supported JellyBean and upFeatures supported depend on installed framework version(s).  See matrix.
Enhancements in later Android releasesEvery version from 5.0 to present (O)  includes enterprise enhancementsLatest release (at time of writing) supports KK and upAdditional features are continually being added.
Staging (getting the functionality on device)Device needs to be configured to have a device owner and associated policy controller.  Achieved through NFC bump or QR codeEHS is just an APK. Can be installed via EMM, MX (AppManager), ADB sideload or manually via ‘unknown sources’MX is pre-installed on all recent Zebra mobile computers.  Older devices required installation via APK.
Provisioning / Integration with EMM (MDM)Integrates with all major EMMs.Can be achieved automatically with code, StageNow or EMMs that support Zebra’s MX.Zebra has a number of EMM partners who support MX and the additional functionality MX provides. See Zebra’s device management partner page.
Security of solutionCan only escape lock task mode via an API call in the app that initiated the mode.  Password to escape user mode is encryptedWhitelisted packages can be associated with a signature to ensure a ‘bad app’ could not spoof the package name.
Additional benefitsRecommended way forward by Google so benefits from Google support, development and partner ecosystem.Flexible solution, can be used in conjunction with other lock down offerings e.g. to enhance lockTask mode by disabling USB.Supported on all Zebra devices going back to JellyBean.  Provides a consistent experience without the need for special considerations on each device.
DrawbacksOnly supports GMS devices with Android 6.0+, though applications are still compatible with earlier versions of Android Locked to Zebra hardware. Does not support widgetsLocked to Zebra hardware, alternatives need to be found if the customer solution contains a mixutre of Zebra and non-Zebra devices.
API accessThe DevicePolicyAdmin APIs provide management capabilities to device administrator applications (typically provided by the EMM)NoneComplete API access is provided in Java and C# via the Profile Manager class.
When best to useNew deployments exclusively targeting GMS devices, Marshmallow or greater.Whenever you need a light weight, set and forget solution with a shallow learning curve.  When you have an exclusively Zebra deployment or need to support Zebra devices going back to JellyBean in a consistent manner.

 

 

Android’s APIs aimed at “Single-Purposes Devices”

Although Zebra devices have a wide variety of features, for the purposes of Android enterprise they fall under the category of “Single-Purpose Devices” or “corporate-owned, single-use (COSU)” since compared with a consumer smart phone, Zebra devices are generally designed with a task specific purpose in mind.

 

It is highly recommended to read Android’s developer guide for setting up single-purpose devices and the differences between app pinning and lock task mode: https://developer.android.com/work/cosu.html

 

First, some prerequisites:

  • Devices must support Google services.  Non-GMS devices (i.e. AOSP only devices) do not support lock task mode.
  • The device in question must be configured to have a device owner (DO).  Device owners are a type of device policy controller (DPC) as explained here: https://developers.google.com/android/work/overview.
    • GMS Zebra devices running Marshmallow and up support device owner mode.
    • Typically you would NFC bump or scan a QR code to specify a device owner but for testing purposes (including the screenshots & videos in this blog) you can also configure an emulator with an adb command:

adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver"

 

Screen pinning vs. Lock task mode:

cosu-pinning_vs_locktaskmode.png

The Android developer guide does go into more detail but essentially, app pinning targets consumer use cases such as handing a device to a friend to show them a YouTube video without allowing them to see your messages.  Lock task mode targets enterprise use cases, is manageable through the DPC and provides a stronger form of device lock down.

 

The concept of white listing applications is integral to lock task mode as only white listed applications can be shown in and control this mode.  White listing is accomplished through an API in the Device Policy Manager which in a real deployment would be controlled through an EMM cloud based interface.

 

Benefits of lock task mode

  • User cannot exit out of your application because the home and ‘recents’ buttons are hidden.
  • If there are multiple whitelisted applications, you can switch between them using either the back button or Intents (where one whitelisted application would be acting as an ‘app chooser’)
  • The status and menu bar are made invisible and inaccessible, this prevents the user from changing device settings.
  • Screen lock and sleep functions are potentially disabled.  You may see documentation stating that screen lock and sleep functions are disabled during lock task mode but this depends on how the device owner is managing the device and is configurable from the DevicePolicyManager APIs.  It is important to note Google’s documentation for Lock task mode may concentrate on kiosk use cases rather than handheld mobile computers as the use case is more familiar to a wider audience.

 

How to enter lock task mode

To demonstrate lock task mode our set up is as follows:

 

An app that will stand in for the user facing application.  Since the application can call startLockTask() and stopLockTask() our test application exposes those as buttons on the interface: https://github.com/darryncampbell/LockTaskMode-Exerciser.

 

 

Base case: Screen pinning

Even running on an Android Marshmallow device with GMS, calling startLockTask() does not automatically enter lock task mode.  The application must first be added to the lock task list, controlled by the DPC to whitelist the application.  If an application is not whitelisted then calling startLockTask() will just result in application pinning.

Invoking lock task mode from an application

If an application is whitelisted by the DPC, calling the startLockTask() API will cause the device to enter lock task mode.  From this mode, the user cannot leave the displayed application.

Note: the ‘Screen pinned’ toasts do not come from the test application, the Android framework is providing misleading information

Entering lock task from the DPC.

Calling startLockTask() from the DPC will cause the device to enter lock task mode.  From this mode, you can also enter additional whitelisted applications by sending an intent (for the video, this is done via adb, in a real app you would call startActivity()) resulting in a stack of whitelisted applications.  Pressing back will cause the stack to unwind and the original (DPC) application to show. Finally, calling stopLockTask() from an application that did not initiate lock task mode will result in a security error; if you call start / stop lockTask in that order from the launched app the stack will again unwind and the DPC app be shown.

Checking the state of lock task mode.

There are a couple of APIs which can be used to determine lock task mode.  Firstly the DevicePolicyManager has an API to determine whether your application is whitelisted but that must be called from the DPC. The activity also has access to getLockTaskModeState() which returns whether or not the application is currently locked or pinned

The lockTaskMode attribute in the Application Manifest

Although the documentation for lockTaskMode will list ‘normal’, ‘never’, ‘always’ and ‘if_whitelisted’; note that ‘never’ and ‘always’ are only available to system apps and privileged apps so a typical end user application will only be able to choose between ‘normal’ and ‘if_whitelisted’.

The examples listed so far have shown the effect of ‘normal’ which is also the default behaviour.  If you specify ‘if_whitelisted’ then the application will launch straight into lock task mode.  The video demonstrates an application configured with ‘if_whitelisted’ being launched twice, the first time is it not white-listed and the second time it is white-listed.

 

 

Mobility eXtensions

Mobile eXtensions (MX) are Zebra’s layer of additional functionality added on top of Android to provide an enterprise-class experience for our customers.  MX has a wide variety of features designed to facilitate device staging and configuration as well as some application management and data capture capabilities; these features are exposed as ‘Profiles’ and can be accessed in a variety of ways:

  • Through code, supported in both the EMDK for Android and EMDK for Xamarin
  • Through StageNow, Zebra’s own staging tool which offers integration with several major EMMs.
  • Through a supported EMM agent.  Several of our EMM partners support MX to enhance their ability to manage Zebra devices.

 

For the purposes of this blog we are only concerned with profile access only through code or through StageNow since these offer the greatest flexibility in how we control profiles.  The examples shown here will use EMDK for Android since it is easier to demonstrate the techniques available but in practice a typical user would most likely be applying these profiles through StageNow.

 

 

The MX lockdown application, available on GitHub can be used to quickly test the various profiles described here.  A video is also available at https://youtu.be/C9OCWsOt4W4 which shows the application running on a Zebra TC51 device

 

 

Profiles to lock down your device

The MX profiles offer multiple, often overlapping ways to lock down your device.  The most restrictive (in terms of a user’s ability to circumvent the lock down) is through the Access Manager with other profiles offering less restrictive but more fine grained options to give the most possible control. You may wish to use some of the less restrictive options in conjunction with Enterprise Home Screen to provide a fully locked down solution.

 

The table below summarizes the lock-down functionality available from the different MX profiles, it is important to note that the profiles themselves are far more functional but I have just pulled out the relevant bits related to locking down your device.

 

Profile & FunctionalityDescription

Access Manager

  • Application whitelisting
  • Prevent installation of non-whitelisted apps
  • Prevent running of non-whitelisted apps
  • Secure which apps can run through use of app signatures
  • Prevent ability of non-whitelisted apps to invoke other profiles (AKA submit XML)
  • Prevent access to system settings

This offers device administrators the most control but confusingly shares some terminology with Android’s lock task mode.  Whitelisting in this context also means specifying which applications can and cannot be run on the device but the Access Manager defines this list through the Add Package Name(s) parameter.  Whitelisting applications has no bearing on how applications are launched in contrast with LockTask mode where the user was prevented from exiting back to the launcher, AppManager will however only allow whitelisted apps to be run from the launcher with non-whitelisted apps displaying an error through a Toast.

 

The ability to restrict whether a whitelisted application can or cannot make changes to the system (through profiles, AKA ‘Allow XML’) offers greater control and fidelity.

 

No special mode is required to use the Access Manager (unlike lock task mode which requires a Device Owner configured on the device) and whitelisting applications via Package signatures, not just the package ID, avoids security concerns on unmanaged devices.

 

Finally, the parameter to prevent access to system settings provides the most comprehensive way to lock down access to device settings on Zebra device short of hiding the settings icon through EHS.

UI Manager

  • Prevent access to the notification shade
  • Prevent settings access from the notification shade
  • Prevent access to the tiles which enable / disable wireless etc.
  • Prevent Clipboard access

The UI manager offers the most control over which areas of the notification shade are displayed to the user.  The following diagram shows the three different areas (blue, red & green) which can be prevented from being shown to the user allowing for example the user to adjust the screen brightness without giving them access to WAN settings, a common use case where employees are working outdoors.

ui manager.png

Clipboard access can also be disabled via the UI manager to accommodate use cases where users need to run multiple applications but you do not want them to be able to copy data between apps, for example between a company app and a web browser.

Application Manager

  • Disable applications from running
  • Prevent access to application info settings via the Settings UI

Beyond disabling specific system applications with known package names, you can also disable certain system services.  In the MXLockDown application I use this to disable access to com.google.android.googlequicksearchbox which disables the Google assist function present on GMS devices. This is just an example and you can see all packages installed on your Android device by running the following command:

adb shell pm list packages

Or see full information about each package by adding the -f flag

adb shell pm list packages -f

Obviously disabling system packages may have unintended side effects but it is nonetheless a useful tool to have in your arsenal and can be used to restrict which applications the user can “share” content with.

 

Disabling the settings application entirely can be done through the application manager with the package "com.android.settings".  This is a very heavy handed approach however and can lead to side effects such as common actions not working and providing no feedback to the user as to why (e.g. long pressing an application and dragging onto 'App Info') or presenting confusing warnings to the user (e.g. long pressing an application notification gives a 'System UI stopped' warning).

Settings Manager

  • Prevent access to application settings via the Settings UI

To completely lock down access to settings it is recommended to use the Access Manager.

The Settings Manager only prevents the user from navigating to the ‘Apps’ menu (Settings --> Apps) but the user can still access sub menus directly, for example pressing and holding an application and then dragging over the ‘App Info’ option at the top of the screen will still display that application’s information.

 

Taking this a step further, it is possible to lock down the ‘App info’ screen with the Application Manager’s AccessToAppInfo parameter but again, this can be circumvented by accessing the sub menus directly.  You can access an application’s notification settings directly by pressing and holding on any notification from that app (Android 6.0+) and then pressing the icon (Android 6.0).

App Info.png

Android 7.0 changed this interface so you now click on ‘More Settings’, but the principle is the same.

 

MX Version support

Over time, additional features have been added to MX so whilst Zebra does not break backwards compatibility, newer MX features will only be available on newer devices.

For a full list of which profiles are available on which devices consult the compatibility table.  You will need to be able to decipher which version of OSX and MX you are running and instructions for that are here.

 

In general, the major features discussed above will be available on JellyBean devices and up, meaning MX is an ideal solution for any deployment containing a mixture of JellyBean, KitKat, Lollipop or Marshmallow devices where you want a consistent approach to how you lock down your devices.

 

Enterprise Home Screen

Enterprise Home Screen (EHS) is a free application offered by Zebra to replace your device’s default launcher application with an Enterprise-first alternative.

EHS resources including setup and configuration guidance can be found on techdocs and the application itself downloaded from the support page.

 

There is a lot of overlap between the EHS settings, Android’s lock task mode and MX capabilities.  The following table lists the available EHS configuration and how it maps or overlaps with the other lock-down options:

 

EHS SettingComparable settings in Android and MX

<kiosk>

 

<preferences>

  <kiosk_mode_enabled>

Kiosk mode is directly comparable with LockTask mode, in both cases the Home and recent options are disabled and the user is locked out of the rest of the OS.

Differences include:

  • EHS Kiosk mode is designed to run a single application whereas LockTask mode can use multiple applications, therefore the back key is disabled only in EHS’s kiosk mode.
  • Since EHS does not offer a programmatic interface there is no way for a running application to enable or disable Kiosk mode (as you can with Android’s stopLockTask() API).
EHS allows you to choose the specific activity of an application to be invoked when the app starts whereas LockTask mode is limited to the launch activity as defined in the application manifest.

<applications>

  <application>

This setting allows you to specify which applications can be run on the device.  There are obvious comparisons with the MX ApplicationManager to disable applications, MX AccessManager to whitelist only certain apps or LockTask mode’s ability to only whitelist certain apps to run.

The difference with EHS’s setting is the applications are just being hidden on the launcher so the user is not able to select them, applications can still be started by an Intent even if they are not listed under <applications>. Another difference is in the use of wildcards to specify the package name: no equivalent exists for this in MX or LockTask whitelists but this is by design since the use cases are different.

<applications>

  <link>
This functionality is specific to EHS as it is a specific use case for a launcher app.

<tools>

  <application>
This functionality is specific to EHS as it is a value add of that product.

<user_options>

  <app_icon_size>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <title>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <title_bar_icon_X>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <icon_label_background_color>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <icon_label_text_color>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <orientation>
You would expect native applications wishing to control the screen orientation to specify a screenOrientation property in their manifest.

<preferences>

  <auto_launch_enable>

<preferences>

  <service_auto_launch_enable>

<auto_launch>

  <application>

<service_auto_launch>

  <service>

There is no equivalent feature in MX or the Android APIs to launch a set of applications at predefined intervals after application reboot.  The closest feature is probably an application’s ability to listen for a BOOT_COMPLETED broadcast intent and on receiving that, start an application or service in their broadcast receiver.

 

There is overlap with Kiosk mode, as previously stated EHS Kiosk mode can only lock the user to a single application whereas the auto_launch settings will allow the user to toggle between apps quickly without going back to the launcher. Auto_launch will not lock the user out of the launcher like the EHS kiosk_mode does.

<preferences>

  <wallpaper>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <fullscreen>
Counter-intuitively this setting only affects Enterprise Home Screen itself and does not have any effect on apps other than EHS

<preferences>

<disable_status_bar_settings_icon>

On JellyBean and KitKat devices this prevents the settings icon being displayed in the Android Status bar, locking down the ability to adjust settings such as Wifi from the pull down.  In Android L the notification drop down as reworked and the official EHS documentation recommends using the MX UI Manager to block access to ‘quick settings’ also known as the ‘tiles’ you see when swiping down twice.

LockTask Mode also prevents the user accessing the notification pull down, duplicating this capability.

<preferences>

  <disable_status_bar_pulldown>

Similar to disable_status_bar_settings_icon, since the notification pull down received an overhaul in Android between KitKat and Lollipop this setting only works with pre-L devices.  EHS documentation for L and above recommends the MX UI Manager to prevent the user pulling down the notification shade.

LockTask Mode also prevents the user accessing the notification pull down, duplicating this capability.

<preferences>

  <install_shortcuts>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <exit_instead_of_reboot>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <reboot_on_install_enabled>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <airplane_option_disabled>

The MX Settings Manager has a parameter which can be set to disable access to the airplane mode selector in the settings UI, quick settings and power key menu.

In LockTask mode there is no way for a user to access the settings UI or pull down the notification shade so the lack of a specific setting is a moot point.

<preferences>

  <bypass_keyguard>
The Android DevicePolicyManager has an API to disable the Keyguard, this API is available to the device owner of a managed device.  No equivalent exists in MX.

<preferences>

  <keyguard_camera_disabled>
The Android DevicePolicyManager has an API to disable features of the keyguard, including the camera.  No equivalent exists in MX.

<preferences>

  <keyguard_search_disabled>
The Android DevicePolicyManager has an API to disable features of the keyguard.  No equivalent exists in MX.

<preferences>

  <usb_debugging_disabled>
The MX USB Manager offers a setting to disable USB adb mode.  No equivalent exists in Android enterprise APIs unless the device is rooted.

<preferences>

  <system_settings_restricted>

System_settings_restricted is directly comparable with the MX AccessManager parameter to specify “Reduced Access” to system settings.

No equivalent exists in Android enterprise APIs but the user would typically not be able to access the system settings at all in LockTask mode.

<preferences>

  <apps_disabled><application>

Prevents the application being displayed in both admin and user mode, with some special considerations for settings and search.  There are obvious comparisons with the MX ApplicationManager to disable applications, MX AccessManager to whitelist only certain apps or LockTask mode’s ability to only whitelist certain apps to run.

Disabling an application in this list truly prevents the app from being run, even via Intent which maps closer to WhiteListing and the MX ApplicationManager than the previously described <applications><application> section.

<preferences>

  <apps_enabled><application>
This is the opposite of the <apps_disabled> setting.  The implementation is a bit more confusing than the single whitelist + special lock mode as seen in both LockTask Mode and MX AccessManager but the end result is the same, you can explicitly enable or disable specific applications.  Unlike MX AccessManager where you can provide an app signature or package name, EHS only supports the package name.

<preferences>

  <admin_max_attempts>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.

<preferences>

  <admin_inactivity_timeout>
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.
Secure ModeThis functionality is specific to EHS and provides an extra layer of security to prevent tampering with the EHS configuration file.  This is only required in EHS because it is a post-loaded application configured via an XML file so there are no equivalents in MX or the Android enterprise APIs.

 

Overlap with MX

It is worth calling out the <disable_status_bar_settings_icon> and <disable_status_bar_pulldown> settings which explicitly recommend to use MX as an alternative on L+ devices. There is also an additional section in the EHS help detailing how MX can be used to enhance EHS (e.g. to prevent screenshots); this illustrates how EHS is designed to work well in conjunction with MX where required.

 

Conclusion

Controlling what the end user is able to do on your device remains a fundamental use case for enterprise Android deployments and is an area where functionality is continually being added.  With Google focussing on this market from Android 6.0 onwards it is likely this area will continue to improve and converge but there will always be the need for Zebra to offer customized capabilities on our devices.  Where we do offer customized functionality, Zebra will endeavour to work well with alternative solutions so administrators can pick and choose the desired aspects from each (hopefully that can already be seen above where Android APIs, MX and EHS can all be used together).