Recommendations Developing for Zebra Android Devices

Darryn Campbell -
6 MIN READ
738
2

...and some common questions on the developer portal

We receive a lot of questions on the developer portal that are variations on a similar theme, so I thought it made sense to bring together answers to the most common questions as well as some more general advice that new or even experienced developers might find helpful

1. Keep your devices up to date

There are two types of device update, full images and LifeGuard updates & both can contain both new features and bug fixes.

All updates are available from the Zebra download portal to those with support contracts.  Select “Mobile Computers” to access updates for our Android devices.  Each device will have its own product page, e.g. the page for MC9300 is here.  This page contains all documentation and utilities available for the device but the “Operating System” section lists the available images for the product.

Instructions to update your device are available in the corresponding release notes for each image; those customers using EMMs will be able to deliver these images via their EMM or through adb for small deployments or individual unit testing.

  • It is always recommended to be on the latest monthly LifeGuard (LG) patch as they contain the latest features, bug fixes & security enhancements.
  • Updates & LG patches may contain new versions of DataWedge, MX or other utilities present on the BSP; see the update release notes for the version(s) contained therein.
  • It IS possible to switch between an AOSP and GMS image, where the AOSP image exists for your device, though an Enterprise Reset may be required.  See the corresponding release notes.
  • It IS possible to update your device OS to a newer Android letter, but it is important to be aware of any Android changes that could affect your application e.g. new background restrictions..

 

2. Don’t automatically assume you need to use the EMDK SDK

Most developers will assume that to integrate with the device scanner they will need to use an SDK for the purpose (which Zebra call the EMDK, ‘Enterprise Mobility Development Kit’).  An alternative approach is to use DataWedge to integrate scanning capabilities into your application which for 90% of developers will be a lot easier in both the short and long term. 

The DataWedge service takes all the complexity of integrating with the hardware scanner away from you, providing a simple Intent (or keystroke) based interface.  For more information on DataWedge see the about page and sample apps.

datawedge_logo.png

 

3. Use the Samples

The samples available on Zebra’s techdocs site provide examples of best programming practice as well as great jumping off points for your own development:

 

4. The EMDK IDE plugin is only designed to be used where applications need to perform device configuration

There are EMDK plugins for both Android Studio (JetBrains) and Visual Studio which provide an EMDK menu in your IDE of choice, the primary feature of which is a Profile Manager (EMDK for Android doc | EMDK for Xamarin doc). 

profile manager.png
  • You ONLY need to use the EMDK plugin if your application needs to perform some kind of device control as it provides access to Zebra’s MX capability allowing you to perform functions that require elevated privileges such as setting the clock or installing certificates.
  • You do NOT need to use the EMDK plugin if all your application is doing is scanning or printing (for example), it is sufficient to use the EMDK SDK from gradle (bintray) or nuget for these purposes.

 

5. There are two developer websites and most developers will need to use both

The Zebra developer experience is separated into two separate websites:

  • Developer.zebra.com provides a forum to ask questions, read blogs & articles (like this one) and get information on developer events like Zebra’s AppForum
  • Techdocs.zebra.com details product APIs, gives samples and provides the documentation and developer guides for all our developer tools.

The developer portal and techdocs cover all forms of Zebra development including RFID and Printing (not just Android) but like any rule there are exceptions: APIs and documentation for our Savanna Data Services are available solely from the developer portal

Common questions:

Q: The scanner does not work when my app is in the background

Q: I have problems switching between applications that both use the scanner

Only a single application can control the scanner via the EMDK at any one time, therefore if two applications on the same device wish to share the scanner then the first application MUST first release the scanner before the second application can acquire it.  This can be seen in the BarcodeSample1 source code in onPause() where:

Failure to release the scanner in this way will mean other apps on the device will be unable to scan, regardless of whether those apps are using the EMDK or DataWedge for scanning.

I would strongly recommend any organization wishing to deploy multiple applications to their devices which perform scanning consider using DataWedge.  DataWedge handles the application switching automatically, so you do not have to worry about releasing and acquiring the scanner.  This is especially true if you have special cases like scanning when your app is in the background or using Bluetooth scanners; if this applies to you then you should read my separate article on targeting multiple applications.

 

Q: How can multiple activities in the same application both share the scanner?

Zebra’s own Peter Arcuri did an excellent article on this question a little while back and the information is still relevant today: https://developer.zebra.com/blog/emdk-android-multi-activity-app.  Again, although Peter’s article addresses how to achieve this with EMDK many developers may find it much simpler to use DataWedge to achieve the same.

 

Q: I am setting the scanner configuration, but it is not taking effect

If you are calling the EMDK ScannerConfig setConfig() method you should make sure you are doing so when the scanner itself is IDLE.  You can monitor the state of the scanner in the ScannerStatus callback. 

BarcodeSample1 shows how to do this with Android (though the principle is the same in Xamarin).  The setDecoders() method is only called in the onStatus() callback when the IDLE status is reported.

Developers using DataWedge to control the scanner do not have to worry about monitoring the status of the scanner and DW will ensure the configuration defined in the active profile is applied automatically.

 

Q: The DataWedge API SET_CONFIG is not working

There are a LOT of settings that can be configured in the scanner, literally hundreds and for this reason the call to DataWedge’s SET_CONFIG Intent API can trip up some developers, especially with the nested bundle structures.

The best advice I give to developers is to take a known, working sample and just modify it rather than trying to start from scratch.  Some examples from both Zebra and myself are below, though note those samples from my own personal github do not come with any kind of guarantee or warranty:

 

profile

Darryn Campbell

Please Register or Login to post a reply

2 Replies

R Ray Powell

As I know, Zebra offers two variants of android running on their devices, GMS or non-GMS (Google Mobility Services). In either case you will have access to all the standard Android APIs but on GMS devices you also have access to the full range of Google Play Services. You can develop an application that runs on both Zebra and non-Zebra devices, the only complication is the scanning SDK (EMDK) ( geometry dash lite) will need to be specified in your gradle file in rather than as an add-in. The version(s) of Android supported on Zebra devices vary depending on the device type, most of the devices right now are running Lollipop or Marshmallow. Not all devices support GPS (since some are targeted for indoor use-cases like warehouses) so make sure your device supports that.

R Ray Powell

As I know, Zebra offers two variants of android running on their devices, GMS or non-GMS (Google Mobility Services). In either case you will have access to all the standard Android APIs but on GMS devices you also have access to the full range of Google Play Services.