Initially I was going to suggest that there may be another application loaded and had the scanner locked from being used. But then you mentioned that you need a few reboots to clear things out. Check to see what apps may be loaded at startup. Otherwise it sounds like a possible hardware problem (unless you say it happens on multiple devices).
Also the latest version of EMDK For Android is 6.0 - be sure to run the device update APK that comes with the installation in order to update the EMDK service on the device.
I'm trying out EMDK version 6.0 for Android to see if this makes a difference. Thanks for the tip!
We have the exact same problem over here. We are able to reproduce it fairly good. We currently use 20 devices (TC55). All devices running Kitkat have this problem. Here are some of our conclusions:
- The software runs without problems on Jellybean. After upgrade to Kitkat, or on new devices with Kitkat preinstalled the problem is there.
- Version of EMDK does not matter. We tried all versions from 3.1 to 6.3.
- The problem is triggered when the app is put in the background, for example when touching the home button. At that moment even datawedge does not function any more. When the app is back in the foreground, there is no red beam when you try to scan. The problem happens in about 50% of the cases when this is tried.
- If the device is connected to a computer via usb, the problem does not occur. Even if you disconnect the usb, the problem stays away. When the device is shut down completely, and restarted, the problem can be reproduced.
Not being able to reproduce this with usb connected makes it difficult to troubleshoot as it is not possible to do real time debugging. It appears to me that this is not a problem in the app because there are enough cases that it works fine, for instance in Jellybean.
Have more people seen this problem? Even more important: is there a solutions. Users are complaining, and they are right.
The problem can be reproduced with the code sample BarcodeSample1 from this website.
I'll try to reproduce this. Just one question:
Are you using EMDK for Android (Java) or EMDK for Xamarin? Both have a BarcodeSample1, e.g. GitHub - Zebra/samples-emdkforxamarin-2_2 at BarcodeSample1
Thanks for helping.
I was using EMDK for Android, this one: Barcode APIs - Zebra Technologies Techdocs
Steps to reproduce:
- Switch off the device.
- Disconnect from usb cable.
- Boot device and start app.
- Select continuous and press start.
- Bring app to the background, for instance by pushing bottom right button. And bring back to the foreground. Repeat this until error occurs.
The status field will show: EMDK closed unexpectedly! Please close and restart the application. I.e. the onClosed method is called. Restarting the application does not help. Only a reboot of the device resolves this error state.
I managed to reproduce it several times using the sample code. But it took me some time. Please have a look at the attached patch. If you will apply that, it will be a lot easier.
MainActivity.patch.zip 773 bytes
Unfortunately I was unable to reproduce the issue but it is interesting that you say it is more likely to occur after applying the patch. I did speak with the Scanning team a while back who said there was a potential issue with the BarcodeSample1, specifically around calling enable() on the scanner when it is not in an IDLE state. They gave me some fixes which I worked into a proof of concept for a completely unrelated piece of work.
Can you try GitHub - darryncampbell/EMDKAsLibrary: Proof of concept demonstration to wrap the EMDK in an Android ARchive ? That is essentially the BarcodeSample1 implementation with the fixes applied. It should just compile. If you have no problems with that application then we'll know it is some issue with how BarcodeSample1 is handling the scanner on your device. I should stress that that application is not endorsed by Zebra, it's just a proof of concept.
Did you use a device running Kitkat?
I tried your version of the example, with the patch applied, but no luck. It took me 3 times minimizing the app, then the errror occured.
A word about the patch: The only thing that changed is that some code moved from onResume to onStart, and from onPause to onStop. Which has significant impact on the problem. But I need it this way for my application. I don't see any technical reason why it should not work this way.
The error is triggered while stopping the EMDK-mode, i.e. while executing the onPause or onStop method. It appears like a race condition to me.
I have attached the patched version of MainActvitiy. Maybe you could give it another try? And rememeber, if you connect the device to usb at any time, the error does not occur until power down. Also when you start the datawedgde app, and close it again, no error. Wierd.
MainActivity.java 23.0 K
Yes, my device is KitKat. With your updated MainActivity.java file I was able to reproduce the issue once this morning however it was only once out of numerous tries.
I saw a different issue on my device, although the laser would emit it would not decode the barcodes so I set about trying to solve that in the hopes there is a similar root cause.
A couple of observations:
* After you call cancelRead() in your deInitScanner() which in turn is called via your onStop() method the scanner status changes to IDLE. As a result a scanner.read() is being performed on a scanner object in an unexpected state (line 330). Adding bContinuousMode=false to the top of your onStop() method alleviates this.
* You have the same code in your onDestroy() method as you do in your onStop() method, you only need it in your onStop() method, though admittedly you might expect the scanner to be resilient to duplicated calls but I removed it just to be sure.
The above two changes (probably mostly the first one) resolve my laser decode issue. You do have to hit 'Start' every time you re-launch the app in order to scan.
If not, it may be some issue with your device configuration that is exaggerating the issue (happening on 20 devices would eliminate it being a problem with a single device) and you may need to raise a support ticket to proceed further.
I've put bContinuousMode=false as the first line in onStop() and removed the onDestroy() part. Still no luck. See attached screenshot.
The device configuration is very basic. It happens both on GMS and non-GMS devices. I will raise a support ticket. Thanks a lot for your help.
I opened a support ticket 3 weeks ago. It is still in progress.
I have some additional information about this issue. I generated RxLogs while reproducing this issue. When the problem starts, these lines are logged:
02-21 08:51:05.064 2242 2242 W System.err: android.os.DeadObjectException
02-21 08:51:05.064 2242 2242 W System.err: at android.os.BinderProxy.transact(Native Method)
02-21 08:51:05.064 2242 2242 W System.err: at com.symbol.emdk.emdkservice.IEMDKService$Stub$Proxy.scnCancelRead(IEMDKService.java:2797)
02-21 08:51:05.064 2242 2242 W System.err: at com.symbol.emdk.barcode.Scanner.cancelRead(Scanner.java:564)
02-21 08:51:05.064 2242 2242 W System.err: at com.symbol.barcodesample1.MainActivity.deInitScanner(MainActivity.java:646)
02-21 08:51:05.064 2242 2242 W System.err: at com.symbol.barcodesample1.MainActivity.onStop(MainActivity.java:187)
Any clues about hte cause or resolution?
1 of 1 people found this helpful
com.symbol.emdk.barcode.Scanner.cancelRead(Scanner.java:564) is checking whether the underlying scanning (Android) service is connected and if not, throwing a generic failure exception which is what is causing the logs. Why the service is no longer connected I could not say and support would be best placed to answer. Have support been able to reproduce the issue?
Thanks for your answer.
Unfortunately they have not been able to reproduce it yet. I hope they will.
In our case, it seems that all the losing the laser issues have involved the ITScriptNet software itself. For each control, the control can be configured to receive input via the keyboard, scanner, or both. So in our case, the cursor would be in focus of a control that was setup to receive input via the scanner, but the laser wouldn't appear. So far, all of these cases have been resolved with updates to the ITScriptNet software itself, which is built using Xamarin. So far, we haven't identified any laser loss outside the ITScriptNet software.