I have recently gotten access to a TC55 KitKat device and am working on making our TC55 JellyBean app compatible. I have hit a bit of a snag.

Summary
 

The KitKat device does not return to its idle state
I cannot cancel a pending read.
EMDK runtime upgrade 3.1.32 did not actually install 3.1.32.

Setup
 
I am testing on two devices, one TC55BH-JC11EE JellyBean running Android 4.1.2, build 140220-SI-1800EN-01.74-15442J-4.1.2-user, with some version of EMDK service 3.0-U1 that I have forgotten and neglected to write down, and one TC55BH-KJ11ES running Android 4.4.3, build 150422-SI-1800EN-02.52.02-23257-4.4.3-user, with EMDK service 3.1.19.
 
I develop with Android Studio on Ubuntu Linux, and have had no trouble doing so for the several months I have worked on this app (although I humbly request that you please provide a manual installation option -- the current Windows+IDE-only installation is painful).
 
I don't know if the issue I'm describing here is caused by KitKat, the EMDK service, or the hardware, but for simplicity's sake I will refer to the devices as JB respectively KK.
 
Detailed description
 
On JB, everything works as expected.
 
When configured to use the hardware trigger, either implicitly or via TriggerType#HARD, everything works as expected for both JB and KK. In this case, the scanner will report these states in #onStatus, irrespective of whether any data was read before the trigger was relased (that is, it doesn't matter if #onData gets called): IDLE > WAITING > SCANNING > IDLE.
 
However, I am developing an app with the specific purpose of using TriggerType#SOFT_ALWAYS. Here, when no data is scanned (beam times out/trigger is released), the states reported for JB and KK are #IDLE > SCANNING > IDLE.
 
For JB, this is also true when data is scanned, but for KK the states reported are IDLE > SCANNING.
 
At this point, the hard trigger is a no-op. In the meantime, with TriggerType#SOFT_ONCE the behaviour is similar except that the hard trigger will work afterwards.

KK never returns to IDLE.
 
It appears the scanner believes it is still waiting for a read. #isReadPending() returns true even after the subsequent call to #onData, and for the entire remaining lifetime of that enabled scanner object.
 
I attempted to work around this by calling #cancelRead(), but that appeared to have no effect whatsoever. I have tried calling it irrespective of the result of #isReadPending(); inside and outside of #onData; immediately before #read and after several minutes of idle time. For all intents and purposes, #cancelRead() seems to be a no-op.
 
I then discovered that activity life-cycle management seemed to work as intended, and that pausing and restoring the activity also restored the scanner, with the soft trigger, to working order. This allowed for commencing another read, at which point the scanner would again become stuck in its read mode.
 
The scanner is operated almost entirely on a background thread, but moving method calls to the main thread did not seem to have any effect.

Work-around
 
When commencing a new read, if #isReadPending() returns true, I now mimic the activity life-cycle by calling #disable() followed by #enable() before finally calling #read(). This seems to solve the immediate problem and is therefore a sufficient work-around, but it can't be how things are supposed to work. I have scoured the documentation but found nothing that indicates that anything related should have changed.
 
Cons:

There is a small but visible delay of variable length from triggering the read till the beam becomes visible. This does not affect our operation but it is distracting.
#enable() and #disable() can fail spectacularly. In very limited testing, we have not yet experienced stability issues, but in general I am uncomfortable with the nature of the solution.
Unknown how this impacts battery life relative to alternative solutions.

 
EMDK 3.1 runtime upgrade oddity
 
I don't know if this is related.
 
I downloaded EMDK 3.1 from the downloads page and installed it on a Windows machine. In addition to the EMDK 3.1 runtimes, this included the EmdkOSUpdateApp_v3.1.32.apk file; I transferred everything to the machine I develop on.
 
I have tried building the app for both the 3.0 and 3.1 runtimes, with no change from the above.
 
I have tried installing the above mentioned runtime update, which I expected to install 3.1.32; on KK it installed 3.1.31 and on JB it installed 3.1.22, and I don't know if this is intentional. Again, no build combination exhibited behaviour different from above.