Android USBアクセサリから読むと、ENODEV IOExceptionがスローされる

Question

AndroidのUSBアクセサリAPIを実装して、携帯電話をLinuxのラップトップに接続できるようにして、電話機をUSBアクセサリモードにします。アクセサリーにアクセスしてそれを開いて、それに書き込むことができます。私のコードは、the documentationの例とほとんど同じです。主な違いは、私は別々の読み書きメソッドを使用しており、ネイティブコードからJNI経由でそれらにアクセスしていることです。

ここで興味深いところです。 2〜2回の読み取り/書き込みが正常に終了すると、ラップトップからのバルク転送書き込みによってタイムアウトエラーが発生し、AndroidのUSBアクセサリへの読み込み呼び出しで、ENODEVエラーコードでIOExceptionがスローされます。これはまだケーブルが接続されているため、UsbManagerにはまだアクセサリが一覧表示されていますが、まだアクセス権があります。

私が読んだループに100msのスリープを入れると、問題は基本的に消えてしまうことが分かりました（ただし、それはまだ起こりますが）。そこに眠るのは恐ろしいクルーだけではありませんが、それは私のアプリに耐え難い待ち時間をもたらします。睡眠時間が短いほど、睡眠時間が10msのところで効果がない場所へのハックの効果は小さくなります。

バルク転送を使用してリアルタイムデータを約20〜30kbpsで転送しますが（バルク転送ではそれほどリアルタイムではありません）、転送サイズは約20で50〜800バイトです-30Hz。それはUSBの限界かもしれませんか？私はそれに多くの経験がないので、基本的にはネットワークソケットと同じように扱っています。小さなメッセージをキューに入れて、あまり頻繁ではないが大きな転送で一緒に送信すべきですか？小さい、高い周波数のバルク転送に問題はありますか？私はこれを見ていきますが、私は基本的にここでストローを握っています。

ハードウェア：

• ラップトップは、Ubuntuの10.04を実行しているとのlibusb 1.0.0を使用しています。
• 携帯電話はGalaxy Nexus Sの実行中Android 4.1.2です。

Answer 1

私はまだ何が起こっているのか理解できませんが、ダブルバッファリング方式を実装することで問題は解決しました。

私は、フルスピードで読んでいるJava Android AppがENODEVの問題に問題がないことを発見しました。これは、Java Native Interfaceが私の問題の根幹であったという結論に至りました。

以前は、JNIからポーリング方式で呼ばれたメソッドから直接UsbAccessoryを読み込んでいました。ネイティブコードからJavaへの移行やJavaからネイティブAndroidカーネルへの移行に関する何かが、明らかにすべてのことを心配しました。

私の修正は、Javaのみのスレッド（JNI呼び出しなし）からUsbAccessoryを読み書きし、そのデータをJNIによって呼び出されたメソッドから読み書きすることでした。

魅力的なように見えます。アクセサリー側で非常に一貫してタイムアウトを送信する前に、そして最後に上記で概説したようにAndroid側でIOExeceptionを送信する前に、タイムアウトは発生せず、IOExceptionも発生しませんでした。私はまだその行動を起こすのはちょっと不思議ですが、JNI Kung-fuが強いことを理解する必要があると思います。