ブライアンさん、考えられる回避策の 1 つは、VM ホストも ADB ホストにすることです。次に、VM クライアントを TCP / IP 経由で接続するだけです。その設定の一般的な考え方は次のとおりです。
- ホスト マシンに Android SDK をインストールします。を含む platform-tools パッケージのみが必要です
adb
。
- VM クライアントが Android デバイスの所有権を取得することを許可しないでください。そのため、VirtualBox USB フィルター ルールを無効にします。また、デバイスを取り外して再接続しても問題はありません。
- VM クライアントから、 を実行します
adb kill-server
。tskill adb
確実にしてください。実行中の Eclipse のインスタンスがある場合は、実際にはバックグラウンドで起動するため、最初にそれらをシャットダウンする必要がadb
あります。このステップをスキップしないでください。
ホストから、 を実行しadb devices
ます。すべてがうまくいけば (そうあるべきです)、デバイスがリストに表示されます。次のようになります (ポート番号に注意してください。マングリングはご容赦ください)。
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
015d2994ed200409 device
この時点で、ホストにはポート 5037 で実行されている ADB サーバーが必要です。これは、VM クライアントから を実行して確認telnet 10.0.2.2 5037
でき10.0.2.2
ます5037
。
ここで、ホストから VM クライアントにポートを転送するか、ADB をホストの IP:port に直接接続する必要があります。あなたが私のような人なら、ADBHOST 変数と ANDROID_ADB_SERVER_PORT 変数の文書化が不十分で、簡単に失敗することに気付くでしょう。このため、ssh
VM クライアントからの単純なポート フォワーディング (おそらく Cygwin 経由) を検討してください。
autossh -nNL5037:localhost:5037 -oExitOnForwardFailure=yes 10.0.2.2
最後に、adb devices
VM クライアントから実行します。「デーモンが実行されていません」と表示された場合は、ポート フォワーディングが失敗していることを意味します。それ以外の場合は、デバイスが表示され、終日 logcat を実行できるはずです。特筆すべき点の 1 つはadb
、もちろん実際にデバッグ ブリッジを使用している場合を除いて、VM クライアントでデーモンを実行しないことです。
リモート マシンに接続されているネットワーク経由のデバイスをデバッグするために、同様のメカニズムを使用しましたが、うまく機能しました。