Frequently Asked Questions

EMDK for Android 13.0

About the FAQ

This page presents some of the most commonly asked questions submitted to Zebra customer support by Zebra customers and partners along with brief answers and links to relevant documentation.

Q: Why did the scanner stop working when switching apps?

A: For proper operation of scanning apps on a device, control of scanning hardware must be programmatically released when the app quits or goes to the background. When a scanning app takes control of any device scanner, other apps on the device are blocked from all device scanning resources. Learn how to prevent these failures in the Barcode Scanning Guide.

Why doesn't my app work on devices running Android 11?

A: Due to package visibility restrictions imposed by Android 11 (API 30), EMDK apps targeting A-11 must include the following <queries> element in their AndroidManifest.xml file:

  
  <queries>
     ...
     <package android:name="com.symbol.emdk.emdkservice" />
     ...
  </queries>

Apps targeting API 29 (or earlier) have no such restriction; no change to the <queries> element is required.

Q: Should I use DataWedge or EMDK for my app?

A: DataWedge provides a quick and easy way to add scanning capabilities to an existing app, and Zebra recommends evaluating the use of DataWedge before building or modifying an app for scanning with EMDK. DataWedge comes preinstalled on all Zebra devices, accepts input from scanners, imagers, cameras, mag-stripe readers, RFID and other peripherals, can infinitely manipulate the acquired data and outputs it as keystrokes, intent payload or over an IP connection. All functions of DataWedge can be controlled programmatically through Android intents. See the DataWedge vs. EMDK feature comparison chart for more information.

Q: Why don't my KitKat and/or Lollipop apps work with Nougat and/or Oreo?

NOTE: EMDK for Android 7.4 (and higher) no longer targets devices running Nougat.

A: Due to the many advancements in newer Android versions, some older apps require modification to run properly on newer flavors. Among the common causes of incompatibility of older apps relate to changes in background processing implemented mainly to optimize battery life.

When developing an app, Android developers should specify in the app manifest a target API along with minimum and maximum Android API levels. This maps the app to specific Android OS versions to run on. For example, if API level 23 is specified as the target level, it indicates that the app is intended to run on Android 6.0 (Marshmallow) and can prevent attempts to run the app on incompatible versions.

Helpful links:

Q: Zebra APIs appear to offer limited fault tolerance. How can my app adapt to this?

A: Retry the API command or gracefully exit the app. The exception handling code snippet below also might be helpful:

catch (ScannerException ex)
{
    Log.d("EMDK Exception","" + ex.getStackTrace());

    // Check if the failure is recoverable within the application
    if (ex.getResult() == ScannerResults.FAILURE ||
            ex.getResult() == ScannerResults.SCANNER_NOT_ENABLED ||
            ex.getResult() == ScannerResults.SCANNER_NOT_CONNECTED ||
            ex.getResult() == ScannerResults.INVALID_OBJECT ||
            ex.getResult() == ScannerResults.NO_DATA_LISTENER)
    {
        // Decide what actions can be taken as per the business logic
    }

    // Check if the failure is not recoverable within the application
    if (ex.getResult() == ScannerResults.SCANNER_IN_USE ||
            ex.getResult() == ScannerResults.FEATURE_NOT_SUPPORTED ||
            ex.getResult() == ScannerResults.SCANNER_NOT_SUPPORTED ||
            ex.getResult() == ScannerResults.SCANNER_INIT_FAILURE )
    {
        // Decide what actions can be taken as per the business logic
    }
}

Q: Why do my apps display Application Not Responding (ANR) messages so often?

A: ANR errors occur when the main UI thread of an app is blocked for a long period of time; the exact timeout period varies by Android version. To avoid ANRs during drawn-out sections of an app, a good coding practice is to code long-term tasks into background or worker threads instead of using the app's main thread.

Helpful links:

Also See