Skip navigation
1 2 3 Previous Next

Android Blogs

77 posts

This document details the developer impact of moving to Zebra devices running Android Nougat (API level 24 & 25). It is the follow-up to my previous document about preparing for Android Marshmallow (API level 23).  If you are moving from Lollipop directly to Nougat, I recommend you read the documents in sequence since all of the information related to Marshmallow (e.g. runtime permissions or doze mode) is also pertinent to Nougat.


Audience for this document

Zebra’s new TC20 and TC25 devices ship with Android Nougat installed.  Zebra's TC51, TC56, TC70x and TC75x can already be updated to Nougat and in due course, additional Zebra devices (both old and new) may receive the Nougat update.  Any developers targeting deployments featuring at least one Nougat device, or any devices that will be updated to Nougat should be aware of the changes detailed here.  Since Zebra devices are shipping with Android Nougat 7.1 (API 25) this document does not distinguish between 7.0 (API 24) and 7.1.



In contrast to some of the fundamental changes that took place in Marshmallow like dynamic runtime permissions, the changes introduced for Nougat should have less of an impact for Enterprise developers.  Google published an overview of the Nougat changes on its developer portal for 7.0 and 7.1 with more detail on Android 7.0 behaviour changes also available.  This document does not replace recommendations from Google, but is designed to supplement those recommendations for enterprise use-cases.


Multi-window Support

Arguably the biggest change introduced in Nougat is support for multiple windows, displaying two applications to the user simultaneously, enabling them to multi-task.  Although Google will give use-cases such as watching a YouTube video whilst searching Google for recipes, it is not too difficult to conceive of enterprise use-cases, especially where a worker needs to quickly switch between two applications to perform their job.  Google has additional information on multi-window mode available on their developer portal.


Multi-window mode will work on Zebra devices, but if you are looking to support it with your application, it is worth bearing the following in mind:

  • There is no way to provision the device to launch in multi-window mode, or to (easily) prevent the user from exiting the mode or preventing them sliding the divider to give one application more real estate than another.  Entry into multi-window mode is controlled entirely by the user, so you should not design your application to run exclusively in multi-window mode.
  • The ergonomics of Zebra devices are designed around an application running full screen; elements such as the position of the hardware trigger will have been exhaustively user-tested for usability in the standard orientation.
  • Although two applications are displayed, only a single application can be the “active” app. If you are expecting scanned barcode data to arrive in your application via DataWedge as keystrokes, these will be sent only to the active application.  Because the active application depends on which app was last touched by the user, this could lead to confusion and missed scans if the user inadvertently taps the other visible application.
  • Multi-window mode will not work with Enterprise Home Screen (EHS), you cannot enter multi-window mode if EHS is your launcher application.


Your app can report support for multi-window by specifying android:resizeableActivity="true" in its manifest under either the <activity> or <application> element.  The following table shows whether an application supports multi-window:

Manifest / API levelResult

resizeableActivity not specified

Target API level is 24+

resizeableActivity assumed to be ‘true’

Your application is assumed to support multi-window.

No toast is shown when multi-window is started

resizeableActivity is ‘true’

Target API level is 24+

Your application is explicitly stating support for multi-window.

No toast is shown when multi-window is started

resizeableActivity is ‘false’

Target API level is 24+
A toast is shown when multi-window is started: “App doesn’t support split screen”

resizeableActivity is not specified

Target API level is 23 or below
A toast is shown when multi-window is started: “App may not work split screen”

(for completeness)

resizeableActivity is ‘true’ or ‘false’

Target API level is 23 or below
Application will not build, no resource identifier found for resizeableActivity.


Not all out-of-the-box applications provided by Zebra will support multi-window mode. For example, the DataWedge Demo app by design does not support it so that it avoids the potential confusion described earlier about which application will receive scan data.


A developer or administrator looking to prevent the user from entering multi-window mode can do so by suppressing the ‘Recent’ key.  If supported on your device, this can be done via the MX UI Manager or  MX KeyMappingManager and remapping the key using the ‘Suppress key’ parameter.  Other options include using Enterprise Browser (<setRecentAppDisable value=”1”>) or initiating lockTaskMode if your Android device is managed.  Disabling the ‘recent’ key also will prevent the key being used to switch between applications, so this workaround may not work for everybody; it may be better to ensure that required applications work well with multi-window mode or report resizeableActivity as ‘false’.


Notification Enhancements

Messaging is a big use-case for many of our enterprise customers and in two ways these have received great improvements:

  • Direct reply allows users to reply to messages without leaving their current application, i.e. they do not have to switch out to the messaging application in order to send a reply.
  • Bundled notifications allow an application to choose how messages are grouped to a user. For example, email conversations can be bundled by subject to avoid clutter.


Other notification enhancements are detailed on Google’s developer page and can be easily integrated into your application.  Also consider if you are using managed Android devices and deploying applications through the managed Play Store you are likely already using popular 1st and 3rd party applications such as Gmail. If this is the case, you will likely get these kinds of new features for free without any additional development effort.


The notification UI has received an update:


Sliding an application to the right will reveal a small cog icon

Pressing on the cog icon revealed in the previous step or long pressing on the notification will bring up a drop-down that allows the user to silence or block notifications.


Whilst it is not currently possible to prevent the user from silencing or blocking notifications in this way, this will be possible in the future.

If the users press on ‘MORE SETTINGS,’ they are taken to the Notifications settings for your application. This is the same screen as is shown if the user navigates to Settings --> Apps --> <App> --> Notifications; it also allows the user to block notifications associated with your application.


As with Android Marshmallow, the only way to reliably block access to the ‘Notifications’ settings screen is by using the Access Manager’s ‘system settings access’ parameter to limit access to all but a small subset of settings.


Additional notification control is available via the System UI tuner and branded ‘power notification controls.'  I cannot find any specific Google documentation on these, but searching for ‘android power notification controls’ reveals a number of blogs that go into detail.  To disable this feature, the easiest thing to do is to disable the System UI tuner entirely (as detailed in the “What’s new for Android ‘M’” document) or to disable user access to the device settings.


Doze Light / Doze on the Go

Android Nougat enhances the Doze mode introduced in Marshmallow by allowing a moving device to now be subject to Doze mode whereas previously only stationary devices were able to doze.  Google’s documentation on the subject is comprehensive. The delta between Marshmallow and Nougat doze, as explained by Google, is the same on both consumer and Zebra devices.

Figure 1: Doze mode as explained by Google's developer docs


All the advice given under “What’s New for Android ‘M’ and the impact on Zebra developers” still applies. Also be aware of a more thorough blog explaining how to keep devices awake and the interaction between doze mode, wake locks and wifi locks.


Zebra devices running Android Nougat are running MX 7.0, and therefore will support the newly introduced BatteryOptimization action added to the App Manager in that version.  “Battery Optimization Remove Apps” and “Battery Optimization Add Apps” are features of the App Manager that allow you to add or remove an application from the Doze whitelist respectively.  This enables you to whitelist an application so it is not subject to doze mode without requiring the user to perform any manual steps.

Note that the value tier product line (e.g. TC2x) only supports a subset of MX and at the time of writing that subset does not include battery optimization, for more information see the TC2x feature matrix.

Figure 2: Whitelisting an application via EMDK (requires MX 7.0)


Background Optimizations

The background optimizations introduced in Android Nougat are detailed on Google’s Android developer portal.  There are probably no specific changes to be made to your application at this stage, but it is worth noting that these ‘N’ changes are laying the foundation for the upcoming background optimization features happening in ‘O,’ which have a greater potential effect on applications.  It is too early to offer recommendations on developing apps for Zebra devices running Oreo, but should you wish to update your app in line with the advice Google is giving for consumer apps, you can start doing that now. Changes such as making use of the JobScheduler or GCMnetworkManager APIs have been possible since Lollipop, but Nougat enhances the capability of JobScheduler and starts to introduce some restrictions on specific broadcast intents.


Data Saver

Android Nougat introduced a Data Saver feature that blocks background data usage and signals foreground apps to use less data where possible.  On Zebra devices, most use-cases revolve around wanting an app to have access to a data connection if required for business-critical actions. It is therefore unlikely the device administrator will want to enable “data saver” on Enterprise devices.


Remember, data saver only affects WAN devices, so if a device does not have a cellular connection (e.g. TC20 or TC) the option will not be available.  No specific MX feature is available to enable or disable data saver, so it is recommended that you ensure device users do not have access to the settings app to avoid undesired throttling of the data connection.


Quick Settings Tile API

Android Nougat introduced a new API to allow applications to add icons to the quick settings tiles (i.e. those icons shown when you swipe down from the top of the screen), which are commonly used to quickly enable or disable system properties such as Wi-Fi, Bluetooth and Airplane mode.


You certainly could take advantage of this on Zebra devices; the screenshots below show a sample app I modified from another blog:



Quick Settings Tile APIQuick Settings Tile API
Test application that displays the Zebra logo as a quick setting tileClicking the quick setting tile invokes the owner app’s TileService.  In this case, I just launch the owner app. However, Android documentation specifically states you should not use quick setting tiles as application launchers(!)



Just because it can be done does not necessarily mean it is a good idea to do it on an enterprise device.  There is no way to automatically provision the quick setting tile. After app installation, the user (or administrator) is required to perform the following steps:

  • Pull down notification shade
  • Click “edit” (pen)
  • Scroll down to the unused tiles and drag the required tile into the main tray
  • Exit from the edit screen


It is far more likely that an administrator would want to prevent the user from accessing the notification shade as it is often undesirable to give the end user the ability to disable Wi-Fi or Bluetooth on the device since this could prevent them from doing their job.  There are currently no plans to provide granular control over the tile window to allow some tiles but disallow others. So for the vast majority of customers, the new Tile API is not a good fit for their enterprise use-cases.

There are many ways for an administrator to prevent the user from pulling down the notification shade: Enterprise Android devices can use lock task mode; Enterprise Browser supports the <SetStatusBarDisable> configuration setting, and MX exposes the capability through the UI manager.


Chrome update also updates the WebView

In previous versions of Android, applications making use of the WebView would receive updates to that WebView on GMS devices via the PlayStore with the ‘System WebView’ package. In Android Nougat, this has changed so applications using the WebView component have that component updated as the Chrome application is updated, and the ‘System WebView’ package is no longer applicable.


This affects Enterprise Browser (EB) on GMS devices, the rendering engine used by EB will update in line with any Chrome updates on the device.  Compare the following screenshots taken of both Chrome and EB as Chrome is updated:



Chrome running on a TC20 out of the box.  The pre-installed version of Chrome is 58Chrome running after receiving the latest available update from the Play Store
Enterprise Browser running on a newly reset TC20.  Note how the Chrome version in the user agent matches that reported by Chrome (58)Enterprise Browser running after updating the Chrome application on the device, the version still matches that reported by Chrome (60 at the time of writing)


There are some new Nougat features under ‘Developer options’ that you might find useful:


On GMS devices, you can choose the WebView implementation.  If you have Chrome Beta or Chrome Canary installed on your device, you can effectively test your WebView based application (e.g. Enterprise Browser) with an upcoming version of the rendering engine, avoiding unexpected rendering issues as you update your production devices with Chrome stable.


The Multiprocess WebView option also is available. This is something Google might enable in the future, but right now the company is just looking for community feedback.


The Android 7.0 change documentation states “Javascript run before page load: Starting with apps targeting Android 7.0, the Javascript context will be reset when a new page is loaded…”  Whilst it sounds as though this could have potential effects on Enterprise Browser’s DOM injection feature, it does not and the feature continues to behave as expected.


Android Enterprise – Device Owner

The official Google documentation for Nougat will refer to Android Enterprise features as ‘Android for Work’ (AFW).  The term AFW is no longer actively used by Google, so you will not see it used in Zebra documentation either. But the functionality being described remains the same; it is those features of Android that exist to satisfy enterprise use-cases.


The Android enterprise features changed for Nougat represent an incremental improvement over what was available in Marshmallow.  The documented updates to the DevicePolicyManager API are only a small part of the overall Android Enterprise story however: the entire solution depends on EMM compatibility, support for Zebra value adds and an upgrade path for existing customers from a Device Administrator to Device Owner mode.  It is outside the scope of this document to describe exactly which changes Zebra is making in Nougat to support an Android enterprise solution. I recommend you check other available Zebra documentation on this topic when available.


As a developer, the likelihood is you are not developing a Device Policy Controller application, so will not be interested in updates to the DevicePolicyManager APIs (such developers will typically be working very closely with Zebra to ensure maximum compatibility).  You are most likely to be affected by the move to Android Enterprise in other ways:

  • By using managed configurations to control your application’s configuration you can gain automatic benefits of server exposure via an EMM and the automatic configuration of those settings that goes along with that.  Existing techniques of configuring your app will still be possible e.g. via a file on the device but you will not have all the benefits of managed configurations.  For examples of managed configurations, I suggest you check out Google’s ‘Application Restrictions’ sample.  Application restrictions are the former name for managed configurations.
  • Managed android devices can be locked down through LockTask Mode.  Your application may find itself in an environment where only it is allowed to interact with the user, i.e. the user cannot escape from your app to configure some setting like disabling battery optimization.  If your application depends on another app somehow, e.g. by launching it through startActivity, then you will need to work with your device administrator to ensure both applications are whitelisted to run.
  • Interaction between your application and the Zebra device through EMDK will not change, the existing ProfileManager interface will remain in place and continue to function.


App Shortcuts

App shortcuts are a new feature added to Android Nougat that allow an application to expose common actions to the user that are accessed by long-pressing the icon on the launcher.

App shortcuts are supported by many Google apps available on GMS devices such as Gmail or Hangouts (see screenshot) as well as possibly being supported by a number of 3rd party apps.  If you are using these 1st or 3rd party apps, you might conceivably see a productivity gain as workers can now more quickly access frequent tasks.


No apps released by Zebra currently support app shortcuts.  Although supported by the default launcher on Zebra Nougat devices, app shortcuts are not supported by Enterprise Home Screen (EHS) so will not be available there even with apps that expose them in the default launcher.

The App shortcuts introduced in Nougat are a completely different concept to Enterprise Browser shortcuts, as explained at that product's techdocs page.


Image Keyboard Support & additional Emoji

Although Zebra devices support the new Image Keyboard support and additional Emoji added in Android Nougat, the recommendation for the best possible keyboard experience is to use Enterprise Keyboard (EKB).  EKB is a stand-alone product by Zebra that can be post-loaded onto the device. It features specific consideration for enterprise data entry such as remappable and custom keys and layouts, scanner integration and a colour scheme designed for easy viewing indoors and out.  EKB does support emojis, but priority is given to enterprise use-cases rather than ensuring complete compatibility with the latest Unicode emoji standards.



Android version 7.x sees Zebra devices starting to ship with MX version 7.0.

Some of the new features in MX 7.0+ are:

  • Battery optimization add and remove apps
  • BT silent pairing
  • Bug report Intent and Screenshot control
  • Wi-Fi 802.11ac and 802.11n configuration

For more information on MX 7.0+ please refer to the techdocs page.  More recently MX 7.1 has been made available which devices have already started to incorporate into their image.


Devices running Android Nougat also will start by shipping with DataWedge API 6.5 or 6.6, which provides a fully featured “zero code” capability for interacting with the device scanning hardware via intents.  For more information on the DataWedge API see the DW techdocs page, which also details how to determine your installed version


Bear in mind that both MX and DataWedge can only be updated through a full OS update.

This is the second in a series of blog posts looking at the considerations around adopting a GMS deployment in the enterprise.  Each post features a tl;dr along with recommendations.  For other posts in this series please see the links below:


Google are open about the type of data they collect on Android, why they collect that data and how that data is used.  The actual details of the privacy policy are available from and is written to be understandable. Note that there are a number of international versions of this policy that you may be directed to, for example the US and UK policies but the differences are lingual and regional rather than affecting the actual policy wording, for example the US “cell towers” are changed to UK “mobile towers”.   Google also have a “terms of service” and both policies are Google-wide meaning they are written to cover any method for accessing Google’s services e.g. Chromebook, desktop search or Chrome on iOS therefore not all the policy information is immediately applicable to Android.


Collected information includes but is not limited to: Hardware model, Android version, device UUID, mobile network, search queries, telephone logs, IP addresses, device crash information and system activity.


As Google states, “this data will be used to improve Google’s products and services for everyone” but frequently we find our enterprise customers err on the cautious side and would rather disable Google’s data acquisition entirely.  Techniques for disabling data gathering are discussed later but the extent of the privacy policy and TOS are not unique to Google; as more enterprises embrace public cloud and hybrid cloud models in their infrastructure the bigger picture of information sharing should be considered in light of the general trend toward being more accepting of cloud computing.


Executive Summary (TL;DR)

  • It is possible to prevent devices from communicating back to Google’s servers and the most reliable way to achieve this is through network configuration. Options do exist on Android devices and within Android applications to disable analytics but many of these options require manual intervention to disable.
  • The extent of the privacy policy and terms of service are not unique to Android or Google and many enterprises are embracing hybrid or public cloud models which have similar policies.
  • There is not just one type of analytics.  The device OS itself sends analytics, system applications (e.g. Chrome or Maps) send their own analytics and Firebase analytics (owned by Google) is a hugely popular analytics engine used by 3rd party applications.  To truly prevent any analytics going through Google’s servers you will need to address all of these vectors.


Google analytics

In order to use Google services, a user or device administrator are required to agree to Google’s privacy policy and terms of service.


This section discusses some of the ways you can prevent your data being shared with Google and there are two broad techniques to achieve this:

  1. Stop the device from reporting analytics to Google by preventing network access.
  2. Turn off analytics via the device and application settings


Note that you can click ‘Don’t add this account now’ during the set-up wizard rather than agree to Google’s terms of service.  Clicking ‘Don’t add this account now’ does not prevent your device from communicating back to Google as you still implicitly agree to the privacy policy through just using Google services. By not adding a Google account to the device, any information being gathered cannot be associated with a unique user but you will lose any functionality that depends on that account e.g. GSuite, Gmail, Drive, reset protection and many others.


Let us dive into each of these approaches to prevent data being shared with Google:


1) Stop the device from reporting analytics by preventing network access

The simplest, most obvious way to avoid Android devices ‘phoning home’ to Google is to prevent them from having external network access.  This makes sense for a large number of enterprise customers whose devices are deployed within the 4 walls and only have access to the company network; it is not required to give users internet access on the device to perform their job so the network administrator can deny external access.


By preventing devices from reaching the wider internet you will experience a degradation of features but will still have more features than a non-GMS device.  An oft used example to illustrate this is the location APIs: a GMS device with external internet connection is able to take full advantage of location services e.g. to create a Geofence around a particular location. If that same GMS device is prevented from accessing the external internet it can still use location services for actions that do not require internet access, for example determining the current activity of the device user (running, walking, driving).  On a non-GMS device, the location services are not available at all and the developer has to depend solely on the earlier location manager APIs whose use Google no longer recommends where alternatives exist.


If you wish to be more controlled over which addresses to block to prevent Android from ‘phoning home’ there is no authoritative list and the most reliable way is to prevent your device from accessing any of the IP addresses under Google’s ASN, 15169.  ASN 15169 consists of a long list of IP v4 and v6 addresses but external tools exist that can make the job easier for network administrators e.g. using you could create an IP list as and download that list by adding &api=1 to the end of the URL.  These external tools come without any endorsement from Zebra but just be aware that they do exist.


In terms of ports, again there is no authoritative list of all ports an Android device will use to connect to Google servers, the best information available only exists for the Firebase Cloud Message (FCM) service, which states ports: 5228, 5229 and 5230 are used by that tool.  Interestingly the FCM documentation also advises opening up all IP blocks listed under Google’s ASN in order to just support cloud messaging.


Looking at this the other way, the opposite is also true: if you wish to take full advantage of the google services such as enhanced location, application updates via the Play Store or Gmail then it is required to accept outgoing connections to all IP addresses contained in ASN 15169 as well as open ports 5228, 5229 and 5230 if you wish to take advantage of FCM.


2) Turn off analytics via the device & app settings

If preventing your device from having internet access to Google’s servers is not an option for you, perhaps because you require some of the added services that GMS offers then you may wish to disable data collection on the device by modifying the appropriate settings.  There is not a single master switch for turning off all analytics data and there are several classes of application which will be sending data:

  1. The Android system sends information back to Google such as battery level, app usage, app crash statistics and network connectivity.
  2. Google developed system applications pre-installed on Android such as the keyboard, Chrome and Maps send their own analytics to Google.
    1. A further distinction can be made for this application analytics data as it may or may not be associated with a Google account.  Consider the maps example, you can use Maps without a Google account and your location data is available to Google, if you then sign into Maps with your Google account that location data can be (optionally) stored as a history associated with your account.
  3. Any Android developer can integrate Firebase analytics (which is owned by Google) into their native Android application, the getting started guide is here.  So, if you have a specific concern about Google then bear in mind that it is a hugely popular application analytics platform for many 3rd party applications.


Analytics sent from the Android system

The Android system analytics can be configured as part of the start-up wizard (SUW) (see screenshot above, “Help improve your Android experience”) and will default to true, i.e. system analytics will be enabled.


You will not see this start-up wizard screen if you provision your device as a managed Android device (i.e. setup as a device owner).  In my tests the diagnostic data option is disabled by default for managed Android devices but since there are many ways to configure managed devices I recommend you test with your particular deployment.


You can manually modify or check the value of this setting at any time by following the instructions at, i.e. go to Settings --> Google --> (Menu) --> Usage & diagnostics and slide to ‘Off’ to disable analytics.  This settings screen also contains information about what diagnostics are being captured and the link to ‘Find out more’ will take you to the answer URL just given.


Analytics sent from Google developed, preinstalled applications

Google have a number of preinstalled applications on GMS devices that they explicitly call out as having additional privacy considerations in their privacy documentation, here.  Note that some of these applications depend on being associated with a Google account in order to have privacy implications (for clarity the Google account required for analytics to be captured is an account in the @gmail.* domain and not a managed Play account).  The list below is not exhaustive or comprehensive and if you plan on using a Google application or service it is recommended to review the privacy documentation for that application; the aim of the table is to explain how to address some of the common privacy concerns.


Note that some of the applications described below expose managed configurations, these require managed devices as well as an EMM that supports them.  You may consider disabling any system application that gives you privacy concerns and this will be covered in a later post, there is also an earlier blog on the subject available which does not provide any recommendations.


ApplicationPrivacy considerations
Google Search

Google searches can be performed in a number of ways, either through the browser (Chrome) at or via the Google app.


Using the browser, the Google page will attempt to acquire your location via the HTML5 location API. The prompt presented to the user can be overridden if you are using a managed Android device since Chrome exposes a managed configuration to specify the default Geolocation settings. Regardless of the Geolocation API setting however, an approximate location can be determined from the device IP, though that ability is not specific to Google.  Much of Google Search’s analytics capabilities are tied to signing in with a Google account i.e. search history and browsing activity.  You can limit the amount of data gathered by not signing in with a Google account and further limit the association of search activity with the device by frequently clearing cookies or browsing in Incognito mode.  Chrome exposes managed configurations for disabling all cookies and forcing sessions to use incognito mode so managed Android devices are able to take advantage of these features.

If you do choose to sign into a Google account you can opt out of Chrome browsing history and activity as part of the account activity controls.


Google Now can also be enabled from the Google Search application after signing into your Google account.

Google Now provides personalized information in the form of cards based on data already known by Google.  Android Marshmallow introduced ‘Now on Tap’ where by pressing the home button a context sensitive search is made based on the text content of the current screen.  Now on Tap represents an additional privacy consideration since it is parsing the foreground app’s text and can be disabled in the settings UI under Settings --> Google --> Search --> Screen search

but at the time of writing cannot be disabled remotely by EMM; if you wish to avoid these privacy implications then it is best to prevent the user from signing in with a Google account.

GmailThe Gmail application itself can be used as a mail client for a variety of mail providers.  Email from providers such as Outlook or Yahoo will not be subject to Google’s scanning (though the degree of scanning from that external provider is outside the scope of this document).  Using a Google account (in the @gmail.* domain) will mean Google will automatically determine ads which may be of interest to you by scanning your email and combining that information with other information associated with your Google account.  You can opt-out of Google scanning your mail for advertising purposes in your account settings however Google will still scan your mail for anti-spam reasons.
YouTubeYouTube can be used both with and without a Google account.  Without a Google account YouTube is still subject to Google’s privacy policy so your watch history could conceivably be shared with Google but all the official documentation implies analytics are only gathered for views associated with Google accounts.  There are a number of controls and limitations you can apply for YouTube from your Google account settings.
HangoutsThe Hangouts application gets the majority of its functionality from being associated with a Google account. Without an account you are limited to SMS communication on WAN devices only.  If the Hangouts application is associated with a Google account the message history will be backed up to Google but this can be turned off in the application settings.
Google Maps

Google Maps will work perfectly well without a Google account as long as your device location settings are turned on, you even get access to traffic, satellite imagery and ‘place’ information.  Google maps gets its location (i.e. the blue dot) from one of the location providers available on the device, I go into this more in a previous blog and in an upcoming post in this series about GMS but briefly, even if location services are not available on the device Google maps will still be able to determine location through GPS or scanning nearby WiFi APs.  If you want to obtain a location which has been determined without accessing Google’s servers then turn off WiFi / Bluetooth scanning and ensure the location mode is set to ‘GPS only’.  Devices without a GPS chip such as the TC51 will need to rely on non-Google solutions such as BLE beacons to determine their position without reliance on Google.


If you do access Google Maps whilst signed into a Google account you get access to a wealth of additional functionality such as location history, saved places, customised flight info, calendar entries and the ability to contribute photos of places, all of which can be customised or deleted from your account settings.

Google Chrome

On launching Google Chrome for the first time you will be asked if you want to share usage statistics and crash reports with Google.

This is specific to Chrome and you can disable it within the application at any time by launching Chrome --> (Menu) --> Settings --> Privacy --> “Usage and crash reports”, as explained here but there is no managed configuration to change this so it must be done manually.

Other privacy features of Chrome include:

  • ‘Safe Browsing’ which can be enabled or disabled via a managed configuration and provides protection against phishing
  • ‘Security incidents’ which allows Chrome to detect unwanted software.
  • ‘Enable network prediction’ allows prefetching and prerendering of web pages and can be controlled by a managed configuration.
  • Managed configuration settings exist to default to ‘Incognito mode’ and reset cookies on each session to force a more private browsing experience on the end user.

Note that Chrome also has its own terms of service and privacy notice.


By associating a Google account with Chrome your browsing history and bookmarks are synced but these can be deleted via your Google account settings.

Google+Google+ is not functional without associating it with a Google account
Google CalendarGoogle Calendar is not functional without associating it with a Google account
Google PlayGoogle Play requires a Google account to function and is covered in a future post in this series on GMS.
Google DriveGoogle Drive is not functional without associating it with a Google account
Google Keyboard

GMS devices ship with an updated Google keyboard compared with AOSP and the GMS keyboard would like to share some anonymized data with Google:

You can disable this on all Android versions, for example on Marshmallow you can update this via the Settings UI here: (Settings --> Languages & Input --> Google Keyboard --> Advanced --> Share usage statistics / Share snippets) and on Nougat the setting is here: (Settings --> Languages & Input --> Virtual keyboard --> Gboard --> Advanced --> Share usage statistics / Share snippits).  In either case, it is not possible to prevent the dialog from displaying to the user the first time.


Zebra’s own Enterprise Keyboard can be used as an alternative input method for the majority of customers and provisioned as the default IME during staging.

Google Photos

Google Photos can be used without a Google account but functionality is limited.  More pertinent to privacy is the exif data associated with the photos you take: when you launch the camera application you will be prompted to ‘Remember photo locations?’ but it is not possible to alter this setting after it is set.  (This is particular to the Camera app settings so may change in the future).

Associating Google Photos with a Google account will enable photos to back up your data to Google’s servers, including exif data.

The only way to prevent backing up once a Google account has been associated is to rely on the user manually selecting the correct options in the presented dialog, see screenshot.


There are a variety of ways to disable the camera entirely so the user is not able to take photos and you can do this via most EMMs and through Zebra’s StageNow tool.

Google DocsGoogle docs are not preinstalled so strictly should not be in this list but if added to a device without a Google account (e.g. deployed via EMM) at the time of writing the application will not launch.
Google KeepGoogle Keep is not preinstalled but if added to a device without a Google account (e.g. deployed via EMM) the application will not run without a Google account.


Analytics from 3rd party applications using Google as their analytics provider

Firebase analytics is a very popular analytics platform from Google for Android and other operating systems.  You will find many 3rd party applications will use Firebase analytics so a logical question would be whether you can disable Firebase analytics using the same setting described earlier which disables Android analytics, i.e. Settings --> Google --> (Menu) --> Usage & diagnostics and slide to ‘Off’.  The answer is ‘no’, there is no way in software to disable a 3rd party application’s analytics unless an option is explicitly exposed by that application; the fallback is to prevent the application from communicating with the Firebase backend, as explained at for Firebase, i.e. disable access to ports 5228, 5229 & 5230.  If the 3rd party application uses an analytics engine other than Firebase then the instructions would differ depending on the provider.



If you wish to prevent the Android OS as well as applications running on your device from providing analytics to Google the most robust way to achieve this is though network configuration, either:

  • By preventing external access entirely or
  • Prohibiting access to Google’s servers via a VPN or firewall.


Settings exist to turn off analytics but there are some difficulties to this approach:

  • Separate settings exist for the device and system applications.  It can be challenging to manage the number of settings and ensure none are missed.
  • Many settings require manual intervention (at the time of writing) therefore making it more time-consuming to stage & provision devices
  • 3rd party applications making use of Firebase analytics may choose to not expose an option to disable analytics, though they must state that analytics are being gathered in that app’s privacy statement


This blog details the process required to create a NFC pairing tag for most Bluetooth devices in order to allow tap to pair without any additional software i.e. using the integrated Android tap and pair functionality. This has been tested on various Zebra Android devices using KitKat OS onwards (including Nougat). The utilities required to create the pairing barcode are included in the file set which can be deployed onto any Zebra NFC-capable Android with a preconfigured Internet connection by scanning the StageNow barcodes below and also attached to this post.  The StageNow exported profile is also available at : .


This has currently been tested for pairing with the following Zebra hardware :

  1.       Zebra MZ/iMZ printers - need a new tag to replace the integrated tag since that has a proprietary format
  2.       RFD8500 - should be configured to accept pairing silently in order to avoid the requirement to press the trigger to complete the pairing
  3.       CS4070 – enable simple pairing in the config.ini file via changing the line below:




  1.       RS6000 – the embedded NFC tag in the RS6000 is already in the correct format for this pairing i.e. to just tap to pair on a Zebra device.



  1.      Pair target Bluetooth device manually
  2.      Run the supplied Bluetooth Device Info app to display the MAC address for the paired device:


    3.   Click the device address to copy the MAC address to the clipboard

    4.   Run NFC TagWriter

    5.   Select MyDatasets and click on the import icon on the top menubar as circled below:



6.    Select and hold the zebra.twdb file as shown below:



7.   Sample tag will now be available for edit via click and hold on the tag entry and then select Copy and Edit from the resulting menu:



8.    Edit the name/MAC address as shown below. The required MAC address can be clearing the current address and then click and hold to paste the new address (copied via the Bluetooth Device Info utility). Device class should be left to default i.e. ‘Not Set’. Click Done when edit is finished.




9.    Click modified tag entry and select Write to write to a NFC tag. Uncheck the ‘confirm overwrite’ option and approach the required NFC tag to write the new contents. Apply NFC tag to target Bluetooth device. Check that device is powered on and in pairing mode (this is default for Zebra printers i.e. pairing is enabled when the device is powered on and it is not already paired with another device.


10.   Make sure that target device is unpaired via Bluetooth Settings menu and that NFC is enabled. Press Home button to return to Android launcher. Read NFC tag and you should see a small toast message to indicate pairing has started and optionally , a popup asking for the PIN entry :



11.   Pairing completes as expected and the device is usable for printing  etc. Note that for some devices (e.g. CS4070) it may be necessary to manually press the device name in the Bluetooth list on the Android device in order to complete the connection and pairing process.


12.   On older devices such as the TC55 , you may see a spurious error message below but the pairing will have completed as expected so this can be ignored.


Recently Google released Android Studio 3.0 to it's "Canary & Dev stable channel"and comes with some really awesome features as discussed in this blog post, but before you fired up your EMDK for Android environment and start using it, you will want to follow the directions below for getting your EMDK dev environment setup correctly.


Step 1: Install EMDK 6.6

There are no special instructions on running the EMDK Installer, so go ahead and download it from our support portal and follow the setup instructions found on Techdocs.


Step 2: Download Android Studio 3.0

Head on over to and follow Google's instructions for install and setup of Android Studio 3.0 Preview


Step 3: Get the Android SDK Folder

First, get the Android SDK folder being used by looking at: Android Studio >> File >> Settings >> Appearance & Behavior >> System settings >> Android SDK


Then, after you noted down the SDK folder, close Android Studio.


Step 4: Copy SDK Add-Ons

From EMDK installed folder (eg: C:\Program Files (x86)\Symbol EMDK for Android\v6.6\Integrator\add-ons), copy all add-ons to Android SDK add-ons folder (eg: C:\Users\<Your user name>\AppData\Local\Android\Sdk\Add-ons).



Step 5: Copy Plug-ins

From EMDK installed folder (Eg: C:\Program Files (x86)\Symbol EMDK for Android\v6.3\Integrator\plugins\IntelliJ IDEA), copy “com.symbol.emdk.wizard.intellijIdea” folder to Android Studio installed folder (eg: C:\Beta releases\android-studio preview\plugins).


That's it! - Fire up Android Studio and you should be all set.

KRACK (Key Reinstallation Attacks) is a security vulnerability that targets a key step in the Wi-Fi authentication protocol to break security encryption. These vulnerabilities could enable a proximate attacker (within Wi-Fi range of both the client device and the access point) to access and tamper with Wi-Fi packets over connections that are protected by WPA/WPA2 encryption.

Zebra takes security seriously and recommends that customers update to the latest BSP and accept monthly patches to minimize security risk.

KRACK may affect computers, mobile phones, and other IoT devices running both Android and Windows operating systems. If your device supports Wi-Fi, it is most likely affected.

Please check the KRACK Attack Security Vulnerability Update for availability of patches for specific Zebra devices.

The Link-OS printer operating system builds that address the Key Reinstallation Attack are now available on the Support and Downloads site.

View more information on the Zebra LifeGuard™ for Android™ Program or download updates.

The instructions below and attached utility show how the LifeGuard patch version can be accessed in the SOTI MobiControl console which allows tracking of which patch version is applied to devices under SOTI management. Note that not all Zebra Android devices report the patch version but it should work on all devices running Lollipop or later OS builds.


Note : this utility is unsupported i.e. use at your own risk


1.       Install and run GetPatchVer.apk. This will write the patchver.ini file in the root of the internal sdcard each time it is run.


2.      In MobiControl console , right click on the target device to access menu and then select Advanced Settings/Custom Data

3.      Click Override Settings Inherited from Parent Group and select Enable Custom Data Configuration – Click New to create new custom data collection rule



4.        Enter name and Build Expression as shown below




5.    Once custom data rule is defined, force device to reconnect and custom data should appear in Information panel as shown below


This is the first in a series of blog posts looking at the considerations around adopting a GMS deployment in the enterprise.  Each post features a summary along with recommendations.  For other posts in this series please see the links below:


The Google Play Store can be used to install and manage the applications on your Android device.  For unmanaged devices it coexists alongside other techniques for application management including Zebra's value-added MX layer, which may be used standalone or as part of your EMM / MDM solution. For managed devices we see the Play Store taking a more central role as the app distribution and installation paradigm, with concepts such as the Play Store for Work integrating more tightly with EMM solutions.


As the Play Store gains traction in the enterprise a common question is how to prevent unattended updates? For applications deployed via the Play Store, how can my Enterprise ensure it is on a known baseline or how can I avoid my validated and tested device configuration from changing unpredictably in the field.  There is of course an argument to be made for allowing unattended updates however for the sake of brevity, this document assumes a desire to prevent automatic updates.  Application deployments which do not rely on the Play Store are outside the scope of this document but the advice here will be equally applicable to both managed and unmanaged devices.


This information is true at the time of writing (November 2017), but as Google continues to focus on enterprise use cases additional recommendations may be made in the future. Some of the techniques described here are proprietary to Zebra hardware but the general principles will be the same throughout the Android ecosystem.


Executive Summary

  • Disabling the Play Store entirely is a reliable way of ensuring no user or system applications get updated in the field.  The down side is that this approach lacks the ability to control individual applications as it is an all-or-nothing solution. StageNow barcodes are attached to this document to enable and disable the Play Store.
  • Play Store automatic updates can be reliably turned off via a Play Store setting however it requires manual interaction to adjust two settings.  Firstly, the automatic updates themselves must be disabled from the play store and secondly, the Play Store must be blocked from presenting notifications which prompt the end user to install available updates manually.
  • Whilst it is possible to prevent a specific application from being updated by disabling the app, the obvious side effect is that the app is no longer available to the end user.


Types of update

There are multiple types of update that an Android device is subject to:

  • User applications are those apps which are installed on the device after it is received from the factory.
  • System applications can mean different things in different contexts, technically Zebra services and apps like DataWedge or StageNow are installed as System apps but since they are not installed via the Play Store, they can be considered distinct from the System apps provided by Google such as Maps, Chrome, Gmail etc.
  • Play Services ( are available via the Play Store ( but are not considered a user or system application per se.  Play Services underpin the majority of GMS functionality such as user authentication, location services, user accounts and more and are subject to different update restrictions.  Play Services are not covered in detail in this blog apart from the effect of disabling the Play Store.
  • Device updates are updates to the entire OS which also includes security patches.  Device updates are outside of the scope of this document.


Techniques to prevent an application from automatically updating

  The following table shows the different techniques which can be used to prevent Play Store applications from automatically updating:


Disable the application you do not wish to update.There are multiple ways to disable applications, some of which effect whether the application will be automatically updated and these techniques are discussed in the next section.  Both the MX AppManager and MX AccessManager can be used on Zebra devices to disable applications with differing levels of control.
Disable the Play Store

Disabling the Play Store can be achieved via the MX AppManager and will prevent all automatic user and system application updates.  This is an all-or-nothing solution and applications cannot be selectively updated; to update any Play Store application it is necessary to first re-enable the Store.



This technique will work equally well on managed and unmanaged Android devices.



Since Google Play Services relies on the Play Store to update, disabling the Play Store will also prevent Google Play Services from updating.

Change the Play Store setting for automatic updates (Global setting).


This applies to both user and system applications.


Note that Google reserve the right in their Terms of Service to override this setting to fix critical security vulnerabilities.

The global Play Store setting is (Play Store) --> (Menu) --> Settings --> Auto-update apps

Applications will only automatically update if configured to do so however this must currently be configured manually since there is no Staging or EMM API to adjust this setting.


If you disable automatic updates, an additional UI component in the Play Store suggests end users turn it back on:

The user is also nagged through a notification from the Play Store to perform the update manually:

The user can then perform the update directly from the notification.  There is no setting to specifically prevent this notification from being shown, it is therefore necessary to block all notifications from the Play Store app to prevent a manual update initiated by the end user.

Change the Play Store setting for automatic updates (application specific setting).


This applies to both user and system applications.

The application specific setting is (Play Store) --> My Apps --> (Select App) --> (Menu) --> Auto-update check

In common with the global setting, if updates are available the end user is presented with a notification prompting them to manually update the application.  An additional confirmation dialog is shown when the user updates an application manually that is configured to not allow auto-updates.  This confirmation dialog is unique to this scenario and is not shown if automatic updates are disabled globally:


Techniques for disabling applications

There are numerous techniques for disabling user or system applications, summarised in the table below:



Package manager shell:

adb shell pm disable <app name>
Disabling an application via the Package Manager shell command is only available on rooted devices and therefore will not be discussed in this blog.

Manually disable the app from the app info screen by pressing the ‘DISABLE’ button

The disable button will only appear for system apps so this technique is not applicable for user applications.


Applications disabled in this manner will NOT automatically update regardless of whether the Play Store is configured for automatic updates.
MX ApplicationManager.  Via the AppManager’s “Action” command an application can be enabled or disabled,

Will work for both System and User applications but is only supported on Zebra devices.

MX is accessible through an SDK or via Zebra’s StageNow tool.

The Play Store itself can be disabled via this technique.


Applications disabled with the AppManager will NOT automatically update regardless of whether the Play Store is configured to auto-update applications.  If the end user has access to the Play Store application, they are given the option to manually ‘Enable’ the app from the Play Store UI:

Enabling an application previously disabled by the AppManager undoes the effects of AppManager; the application reappears in the launcher and is once again subject to automatic updates.


This technique will also prevent the end user from using the application.
MX AccessManager.  The AccessManager’s whitelist functionality will only enable those user applications which have been whitelisted, with all other user applications being disabled.

Will only work for user applications, not system applications meaning this technique cannot be used to disable the Play Store.


Applications disabled with the AccessManager will NOT automatically update regardless of whether the Play Store is configured to auto-update applications.  If the end user has access to the Play Store application, they are given the option to manually ‘Enable’ the app from the Play Store UI:

Enabling an application previously disabled by the AccessManager does not undo the effect of AccessManager whitelisting and the app will not appear in the launcher, in contrast to the AppManager technique described previously.


An application enabled in this manner will now appear in the list of pending updates in the Play Store however it will not be automatically updated and attempting a manual update will lead to a generic error:

To avoid confusion, tools like Zebra's Enterprise Home Screen can be used to prevent the user from accessing the Play Store, if appropriate.


This technique will also prevent the end user from using the application.

On Managed Android devices in Device Owner (DO) mode several system applications may be disabled by default (e.g. Google Photos, Google Maps etc.)

Whether or not these system apps are disabled will depend on your method of provisioning as it can be configured.  Your EMM is able to re-enable system apps by calling a client-side API.


Exactly which system applications are disabled will depend on how the Operating System was built and may be customized by the OEM but the Play Store and Play Services will always remain enabled.


System applications disabled in this manner will not appear to the user or show as installed in the Play Store app so are not be subject to automatic updates.

On managed Android devices running API level 24 or higher, the EMM or DO can suspend packages via the setPackagesSuspended API

Suspended packages will still be shown to the user but will be grayed out and attempting to click on the icon will present the user with a DO branded message box indicating that the operation is not allowed.


Both system apps and user apps can be suspended however suspension has no effect on whether or not the application is updated. If the Play Store is configured for automatic updates then suspended apps will be updated alongside their non-suspended counterparts.


Recommended approaches to prevent applications from automatically updating


RecommendationConditions / Implications
Disable the Play Store ( via the MX AppManager

Will prevent all user and system apps from updating but it is not possible to selectively specify which apps are subject to updates, it is an all-or-nothing solution.  There is a distinction and often a confusion between the Play Store and the Play Services, disabling the former can be achieved without negatively impacting the functionality of the OS or system apps, in stark contrast to the latter.


StageNow barcode to disable the Play Store


StageNow barcode to enable the Play Store


The two barcodes above (also available as attachments to this document) can be used to enable or disable the Play Store with Stage Now.


Note that disabling the Play Store will also prevent Google Play Services from updating.

Disable application updates from the Play Store [(Play Store) --> (Menu) --> Settings --> Auto-update apps]


Block notifications from the Play Store.


Prevent end users from accessing the Play Store to change the setting

Requires additional provisioning steps to:

  1. Configure the Play store setting, since it cannot be a changed via EMM
  2. Block notifications from the Play Store to avoid the user being prompted to perform a manual update.

At the time of writing, both of these steps can only be performed manually.


There are numerous ways to prevent users from accessing the Play Store e.g. Zebra’s Enterprise Home Screen (EHS).  This leaves the Play Store itself available if required e.g. for remote installation of applications on managed android devices or allowing critical updates to be pushed by Google.

The MX AccessManager can be used to prevent updates to applications which will not be used by your end user.

This could save on bandwidth as non-essential apps would not be updated.


Of all the techniques discussed to disable applications, the MX AccessManager provides the most complete solution as it cannot be circumvented from the Play Store and is easily configurable from StageNow or supported EMMs.

BlueBorne, Heartbleed, Stagefright. The list goes on. Android gets a lot of negative publicity around security vulnerabilities. And Android is a large target with nearly 85% of the worldwide smartphone OS market share according to IDC, May 2017.


IBM’s 2017 Ponemon Cost of Data Breach Study revealed the average cost of a data breach is $3.62 Million, and companies are having larger breaches than in the past, averaging more than 24,000 records.


Corporations have a lot on the line with any device used as part of their business operations. So is Android really an Enterprise Ready Operating System?


The reality is that many of the headline-grabbing vulnerabilities are identified through Android-sponsored bounty programs with no actual exploitation in the real world.


Source: Google Safety Net Data; Masterkey data collected  from 11/15/2012 to 8/15/2013 and previously published at VirusBulletin 2013. Fake ID data collected data collected from 11/15/2012 to 12/11/2014 and previously published at the RSA Conference 2015.  Stagefright data current through May 2016.


Android has responded to the security challenges by making significant changes, starting particularly in Lollipop, to make a very secure operating system. Features like sandboxes & permissions, TrustZone Services, and Isolated Processes provide more Application Isolation. There is more comprehensive Device Management via administrative APIs and profiles. The OS now checks Device Integrity via Full Disk Encryption, mandatory for Android devices M and newer and encrypted at factory for the first boot. Verified Boot ensures OS image is not corrupted to prevent against malicious accidental OS changes.


Apps are still one of the areas that provide the most risk by opening access to a device so Android created SafetyNet Verify Apps which scans for Potentially Harmful Applications (PHAs) in Playstore on Device and third party app stores. Through this program over 1.4 billion devices are protected with 790 million device scans per day, and 6 billion apps checked per day. The result is that in 2016 less than 0.05% of devices that use Playstore have a Potentially Harmful App (PHA)

Source: Android Security 2016 Year In Review, March 2017


Google even proactively notifies developers of vulnerabilities resulting in over 275,000 apps improved in 2016.

As mentioned above, to improve Application Security Google has the Android Security Rewards Program with hundreds of active researchers who have been paid over $1 million in the last 12 months.


Google has also built the Managed Play Store, aka Enterprise Play Store. Administrators can configure Play Store on devices with only authorized applications from public or private Play Store or even local hosting.


Google regularly provides security updates to close the vulnerabilities in the Android Operating System, but attackers quickly exploit new vulnerabilities. As a trusted partner, Zebra gets early access to security patches and can prepare patches often before the vulnerabilities are made public. Google has moved to a 30-day security patch cycle, we are following this approach as well.


According to Google 15% of devices are still running KitKat and 29% on Lollipop. How does a 2-3-year consumer product life-cycle line up with an Enterprise life-cycle of 5 years? How can a business know their devices will continue to receive updates?


This is where the Zebra LifeGuard™ for Android™program comes in. LifeGuard provides extended security support, predictable periodic security updates and legacy OS security support when transitioning to a newer OS. Frequent updates will enhance your security and LifeGuard makes them easy to install at your discretion, either locally, or remotely via Enterprise Mobility Management (EMM).


There is no such thing as a completely secure solution, but Zebra and Android are working together to reduce the risks Enterprises must face. Three key areas of focus include

  • Prevention: If harmful applications cannot execute, they can do no harm. Control access to settings and whitelist/blacklist for the minimum require application set.
  • Detection: Zebra provides detection features to detect if vulnerability has occurred and take corrective action
  • Security Updates: Zebra works closely with Google to keep up with new security vulnerabilities in a timely manner. Plan to deploy regular security updates.


For more details on Zebra Security visit the LifeGuard™ for Android™ page, the Zebra Developer Portal, or watch a session from Zebra APPFORUM on Android Security.


Android provides a host of resources at the Android Security Center and the Android Security 2016 Year in review white paper.

One of the most common requests from developers is how to get started with Android development for Zebra devices. This post is designed to point people in the right direction.


Google has created several great resources for those that are brand new to Android development:


Zebra has similarly made a resource library to teach Android Developers how to build apps for Zebra mobile computers


The purpose of this utility is to display the Electronic Serial Number (ESN) of a Zebra Android device in the title bar of EHS. This allows the user to identify the device for the purposes of problem reporting etc. The utility works by patching the existing enterprisehomescreen.xml file with the ESN , replacing the Title Bar text (which by default is ‘Enterprise Home Screen’) with the ESN. The utility can be autorun by EHS during initial load so that the ESN is visible immediately the device boots up to the EHS launcher as shown in the screenshot below:





To demonstrate this in action, the attached StageNow centralised profile (rem_ehs2dot6_esn.pdf , original exported profile also attached) will download and install EHS together with the utility on any Zebra Android device with a pre-configured internet connection.


To install the utility manually, follow these steps:

  1. 1.      Download and install the attached GetESN.apk utility
  2. 2.       Edit your EHS config file enterprisehomescreen.xml (which needs to be located in /enterprise/usr) file to include the following in the auto launch section:


                <application delay="500" package="com.ih.getesn" activity="com.ih.getesn.main"/>


  1. 3.       Install EHS – utility should run during initial start of EHS and show the ESN in the title bar.


Please note that this is an unofficial utility and therefore unsupported i.e. use at your own risk .

The latest versions

As I'm writing the latest Zebra's EMDK for Android is v6.6, supporting KitKat, Lollipop and Marshmallow devices. All the documentation is available on TechDocs, and from there you can find all the samples and their source code on GitHub, under the Zebra organization.

Here you can find the latest version of the samples:

The older sample

Sample for older version of Zebra's EMDK for Android are still available on github but under a different organization: Developer Zebra.

Here you can find:

Plus you can find the ADT version of the sample:

A note on the sample

All these sample repositories are build in the same way. The master branch contains only a README file and there's a branch for every sample, PLUS a branch with all the sample that is the one that I usually clone using the command:

git clone -b AllSamples <Repository to clone>



edit for layout and typos.

BlueBorne is an attack vector that exploits Bluetooth connections to target and control devices.

Zebra takes security seriously and recommends that customers update to the latest BSP and accept monthly patches to minimize security risk.

BlueBorne may affect computers, mobile phones, and other IoT devices running both Android and Windows operating systems. (WinCE and Windows Embedded Hand Held devices are not affected.)

Patches for BlueBorne are available today.  Please check the bulletin and the site for specific device availability.

In response to the September Android Security Bulletin Zebra has addressed security vulnerabilities affecting eleven Zebra Android devices running Kit Kat (K), Lollipop (L), and Marshmallow (M) through patches as part of the Zebra LifeGuard™ for Android™ program.


According the the Android Security Bulletin:

The most severe of these issues is a critical severity vulnerability in media framework that could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

We have had no reports of active customer exploitation or abuse of these newly reported issues. Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

Impacted devices include ET50 L, ET55 L, MC18L, MC32 L, TC51 M, TC56 M, TC70 KK and L, TC70x M, TC75 KK and L, TC75x M, TC8000 KK.


Device updates are an important way to keep your Android devices secure and running at their full potential. All customers are encouraged to accept these updates to their devices.


Read more about the issues addressed or download the updates at

In response to the August Android Security Bulletin Zebra has addressed security vulnerabilities affecting eleven Zebra Android devices running Kit Kat, Lollipop, and Marshmallow through patches as part of the Zebra LifeGuard™ for Android™ program.


The highest severity update is a critical security vulnerability in media framework that could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process.

Impacted devices include ET50 L, ET55 L, MC67 KK, MC92 KK, TC51 M, TC56 M, TC70 L, TC70x M, TC75 L, TC75x M, TC8000 L.


Read more about the issues addressed or download the updates at

Working in Android Studio you can notice that every project contains a file with at least a couple of properties containing the path for Android SDK and Android NDK.

Android Studio populates this information when it creates the project based on the ANDROID_HOME environment variable. If this variable is not present in your system Android Studio will find the correct path in other ways, but having ANDROID_HOME setup correctly is a really good idea, see the note at the end of this short post.

Given that I usually have in my build.gradle file a reference to Zebra's EMDK, look like a good idea to use sdk.dir instead than hardcoding the path (like I've done for a too much long time) given that the EMDK resides in Android SDK's add-ons folder.

So, my gradle files now includes:

Properties properties = new Properties()
def sdkDir = properties.getProperty('sdk.dir')

so that I can the use the sdkDir variable like:

provided fileTree(include: ['com.symbol.emdk.jar'], dir: sdkDir+'/add-ons/addon-symbol_emdk-symbol-23/libs/') 

Much cleaner and nice :-)



Is usually not a good idea to include in your revision system the file because this contains information... "local"... to your machine.

Imagine that you're sharing a project with a colleague or with a remote CI build server. In this case everybody will have the Android SDK (and the Zebra's EMDK that resides in the SDK add-ons) in a different folder.

The best option in this case is to avoid to share the file and have the ANDROID_HOME environment variable correctly setup so that the build works correctly on every machine.


If is not available, Gradle will use ANDROID_HOME automatically.

If is available, Gradle will use this file having a wrong sdk.dir set and fail.



I got some enquiry to provide a complete gradle file to understand where to do the pasting.

Here’s one sample file:


Screen Shot 2017-09-21 at 11.20.40.png


I've a better formatting on the original post on my website if you need it.

Filter Blog

By date:
By tag: