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.


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.


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.

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.

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

Android logo.png ehs-logo.png mx logo.png
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:

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

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

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

  • Disable the home button
  • 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.


MX7.1 has introduced 2 new UI Manager features: Disable the NavigationBar and Disable the Recent Apps Button

MX 8.x has introduced several new UI Manager features: Long-Press HOME Key Enable / Disable , App Info Icon Enable / Disable​, tapping on the status bar time launches the clock app Enable / Disable and the ability to disable split screen.

As updates get rolled out onto devices through OS updates you should be able to take advantage of these new features.

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

  • Control whether or not the user can enter airplane mode
  • 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.  See also the related App Info Icon Enable/Disable function.


MX 7.x and MX 8.x have introduced new features to the Settings manager related to locking down your device, specifically the ability to disable the slide-out settings drawer and the ability to control tethering.

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


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


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.


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


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


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


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


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





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.


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


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

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.


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.


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


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


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


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.


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.


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


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


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


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.


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


This is the opposite of the 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.


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


This functionality is specific to EHS, it is a value add unrelated to locking down access to the OS.
Secure Mode This 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 and 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.

Enterprise Browser

Enterprise Browser (EB) 1.7, released July 2017 incorporates a number of features to prevent users exiting your EB application.  These lock-down features are only useful for developers targeting Enterprise Browser who do not expect their end users to exit from EB and take the form of a kiosk mode locking the end user into Enterprise Browser.

There is not a single setting for kiosk_mode_enabled, like there is with Enterprise Home Screen, instead you need to configure the individual settings, as explained below.  Remember if you completely prevent the application from being exited you can potentially make it hard to develop for, you might consider enabling DebugButtons during development if this is the case.  Also be careful, if you use a tool like EHS to launch EB on boot and you have not included any ability to exit from EB you may find yourself requiring a factory reset to exit the application.

Configuration Setting Description
SetHomeKeyDisable Makes the home key completely ineffective

Probably more accurately described as disabling the notification pull-down, this has the same effect of disabling the notification shade using the MX UI manager.  The end user is still able to see the status bar by swiping at the top of the screen revealing battery and signal levels but they are prevented from:

  • Interacting with notifications including accessing the application AppInfo setting on 6.0+ (as explained under MX Settings Manager, above)
  • Accessing the quick settings (tile) UI to directly disable settings such as WiFi and Bluetooth

Pressing the back key will still navigate back to the previous page in your application just as it does with any mobile web browser e.g. Chrome but with this setting enabled it is not possible to exit Enterprise Browser by pressing the back key. You may notice some visual aberration as EB pauses and then quickly resumes after you press the key but the functionality of your EB application will remain unaffected.

It is not currently possible to prevent the user from going back to the previous page within EB by pressing this button so you should design your application workflow with this in mind.


Note the spelling error in ‘Buton’, for EB 1.7 you need to spell it this way but for subsequent versions the team will fix this whilst retaining backwards compatibility.

Prevents the user from adjusting the device volume.  Obviously on Android, the volume key provides access to the ringer, alarm and notification volume so the user can circumvent lots of functionality by adjusting the volume levels on the staged values.

SetRecentAppDisable This setting enables or disables the recent applications button.  Similar to the back key, you may see some visual aberration as EB pauses and then quickly resumes after you press the key but the functionality of your EB application will remain unaffected.  During this visual aberration, the other recent applications are visible (though you cannot interact with them) so you may wish to avoid this by clearing the recent apps list using the MX App Manager



These settings are not new in Enterprise Browser 1.7 but are worth including in this list.  You can specify an exit password which must be entered when EB is quit through the EB quit API or debug button.  Note that the exit password is not required if EB is quit via the menu or recents key.  If you are configuring your application with some of these described kiosk settings it is conceivable you also have some kind of admin menu in your app which enables an authorized user to quit EB for maintenance purposes, in that case it may also prudent to specify an exit password

Enterprise Browser overlap with other solutions

It is entirely possible to lock your end user to Enterprise Browser by using a combination of other solutions, for example Enterprise Home Screen’s kiosk mode can be configured to only show Enterprise Browser MX can be used to prevent users from accessing device notifications.  The primary advantage of the Enterprise Browser lock down features is that you can do everything entirely within EB, not having to worry about deploying EHS, some MX solution or whether or not your device is a managed Android device.

Overall 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 focusing on this market from Android 6.0 onward 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).

Submitted by Anonymous (not verified) on November 10, 2011 Permalink

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?

Submitted by Anonymous (not verified) on August 15, 2013 Permalink

Great overview, thank you very much!

The only thing is that your LockTaskMode Exceriser crashes immediately after launch on my TC56 (Latest BSP w/ GMS) - anything I should check and do to make it work?