Locking down your device
Updated October 2018
A number of new MX features have been added to the platform related to locking down your device since the last update to this post.
Updated July 2017
Enterprise Browser 1.7 released July 2017 and available here has a number of built-in features available to help you lock down your device, I have updated this blog at the bottom to explain these.
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’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. |
|
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. |
|
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/latest/mx/accessmgr/ |
Clearly there will be some overlap between these offerings. The differences are summarized in the below table:
Restrict applications running | Yes, via lock task mode | Yes, by only displaying enabled applications | Yes, by application whitelisting in the AccessManager |
Restrict application installation | No, can still install via adb or programmatically through DPC but user ability is restricted as they cannot escape the current app | Not 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 setting | Yes, 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 instead | Yes, via the UiManager |
Kiosk mode support (prevent back, home and recent buttons) | Yes, via lock task mode. | Yes, via a configuration setting | No |
GMS / Non-GMS? | Both GMS and non-GMS | Both GMS and non-GMS | Both GMS and non-GMS |
Zebra / Non-Zebra? | No restriction | Zebra devcies only | Zebra devcies only |
Earliest Android version supported | 6.0 for Enterprise use cases | Early releases of EHS supported JellyBean and up | Features supported depend on installed framework version(s). See matrix. |
Enhancements in later Android releases | Every version from 5.0 to present (O) includes enterprise enhancements | Latest release (at time of writing) supports KK and up | Additional 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 code | EHS 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 solution | Can only escape lock task mode via an API call in the app that initiated the mode. | Password to escape user mode is encrypted | Whitelisted packages can be associated with a signature to ensure a ‘bad app’ could not spoof the package name. |
Additional benefits | Recommended 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. |
Drawbacks | Only supports Android 6.0+, though applications are still compatible with earlier versions of Android | Locked to Zebra hardware. Does not support widgets | Locked to Zebra hardware, alternatives need to be found if the customer solution contains a mixutre of Zebra and non-Zebra devices. |
API access | The DevicePolicyAdmin APIs provide management capabilities to device administrator applications (typically provided by the EMM) | None | Complete API access is provided in Java and C# via the Profile Manager class. |
When best to use | New deployments exclusively targeting 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:
- 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.
- Zebra devices running Marshmallow and up will run in 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:
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 emulated device configured with Google services and running Marshmallow.
- The emulated device has been configured to have a device owner, the test dpc provided by Google: https://github.com/googlesamples/android-testdpc
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, 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 & Functionality | Description |
---|---|
|
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. |
|
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. 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.
|
|
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). |
|
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). Android 7.0 changed this interface so you now click on ‘More Settings’, but the principle is the same. See also the related App Info Icon Enable/Disable function.
|
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 Setting | Comparable settings in Android and MX |
---|---|
|
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 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. |
|
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 |
|
This functionality is specific to EHS as it is a specific use case for a launcher app. |
|
This functionality is specific to EHS as it is a value add of that product. |
|
This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS. |
|
Anonymous (not verified)
2 Replies
Thanks. I do not have a TC56 to test with unfortunately, I tried updating everything (build tools, Android studio) and testing on my TC51 GMS but still could not reproduce. Could you please share the logcat of the failure?