Unable to cleanly close USB accessory FileInputStream on android 2.3.4

http://code.google.com/p/android/issues/detail?id=20545

 

I am using HTC Sensation and Google API Addon 10 to make use of the USB accessory functionality.

I am using the HTC sensation as the USB peripheral and my own custom device is the USB host.

My experience is with the current implementation on 2.3.4, 
I am not sure if the problem exists in android 3.1 (API 12) as I have no device to test there.

When using a USB accessory, I am able to enumerate the accessory and open its FileDescriptor. 
I can then open the FileInputStream and FileOutputStream to read and write data to the USB host device, 
just like explained in the (very limited) documentation.

The issue comes when I wish to exit my task/service which is currently communicating with the USB accessory.
Specifically, when reading from the device using usbFileInputStream.read(buffer); 
this call blocks until data is sent from the USB accessory to the android device.

When my program is in the process of shutting down, there is no way (I have found) 
to force the call to FileInputStream.read(byte[]) to terminate early 
(even throwing an IOException would be nice). 

The call to FileInputStream.read(byte[]) ONLY unblocks under the following conditions:

1. The USB host is disconnected from the Android device. 
FileInputStream.read(byte[]) throws an IOException.

2. The USB host sends one or more bytes to the Android device. 
FileInputStream.read(byte[]) returns with the correct number of bytes read.

I expect that closing the file streams and the underlying ParcelFileDescriptor object 
would cause the FileInputStream.read(byte[]) call to unblock and throw an IOException.

The only workaround I have found is to ensure the android accessory continuously sends USB traffic to the android device.

Is there much hope in getting a fix for this issue in the Google API Addon library?

Thanks,

- Wayne

I can confirm the same behavior on a Motorola Xoom running 3.2.1. 
Closing the ParcelFileDescriptor and FileInputStream does not cause the blocking read(byte[]) function to throw an IOException. 

The stream processing thread hangs unless one of the alternatives mentioned by Wayne is employed.

Confirmation of same problem on a HTC Desire Bravo with Gingerbread 2.3.7. 
It seems that it isn't a "bug" per say but intrinsic to the fact that we must use FileInputStream 
(which according to documentation has a close() method that does nothing, unfortunately). Or is it?

Same problem on Acer A100 with ics 4.0.3. 
Moreover, if reading operation goes from another thread, 
Thread.interrupt does not causes it to throw ClosedByInterruptException, 
as javadoc says it should do. This causes ghost threads to appear.