I'm fighting the known bug in Android that a blocked USB read thread cannot be unblocked - period. Nothing unblocks it; not closing the underlying object (as is typical with sockets), not using NIO and calling FileChannel.close (which sends an exception to the blocked thread), nothing. So I'm stuck crafting up some sort of workaround that tolerates this bug in Android.
The biggest problem is that since the thread won't die, it retains a reference to the underlying FileInputStream object (or the FileChannel object, or whatever you're using). Because that object still exists, you cannot reassociate with the connected USB device. You get the well-known "could not open /dev/usb_accessory" message of despair.
So... since the thread cannot be killed nor interrupted externally, and since it won't wake up on its own to release the object, I'm wondering when such a blocked thread and its associate resources are cleaned up by the operating system. In most OS's the thread would be part of the overall process, and when that process is terminated all threads and objects would get cleaned up at the same time - thus finally releasing the USB connection so something else can associate with it. But experiments suggest that the thread or object may live beyond the process. How, and in what context, I don't know, but so far I'm still getting that "could not open /dev/usb_accessory" message even after the previous process has been terminated (!?!).
So... what finally cleans up everything associated with a process, including all of its threads and instanced objects? How do I "clean the slate" so a new process has a fresh shot at associating with /dev/usb_accessory?
Thanks!