諸悪の根源は、default.propの設定値であり、
ro.secure=1
ro.allow.mock.location=1
ro.debuggable=0
persist.service.adb.enable=0
を
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
に変更すると幸せになれるという。
しかし、default.propを直接書き換えても再起動すると変更前に巻き戻る。
bootイメージに内包されているdefault.propが再展開されるから。
つまり、bootイメージを取得しアンパックしてdefault.propを編集してパックして。。
ここに記載されていることをやれば出来るのですが、まー面倒くさいの何の。リンクの真珠スクリプトとか切れてるから巡回して掻き集めたり、今の開発はwin機でしているので、linux機での作業発生とかね(cygれば良いのだけど)
結果的には、wifi経由でのブリッジは行えたのですが、有線で5555ポート開放を仕込むようなダメなところありで改善すべき。美しくない。
有線で仕込んでいない場合の挙動は
(端末起動直後)
>SET ADBHOST={IPアドレス}
>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
てな具合で、デバイス列挙が皆無。それにしても、persist.service.adb.enable=1なのに、adbdはデバイス起動時点で生きていないのか？
これは、adbd起動時に5555番から奇数番でデバイスエミュレータ接続しに行った結果、接続するものがないという状況らしい。因みに、kill-server->start-serverしてからのadb devicesでも同じ結果。
ということは？5555開けて待機しているデバイスエミュレータがいないこと(いつどこで起動するのか不明)がそもそもの問題であり、adb tcpipやadb connect使うのは、その問題原因を調べてからにしよう。USB接続時のデバイスエミュレータは、adb tcpipやadb connect使うと消え去るため、USBで再接続してもデバイス列挙が皆無になる(その時のシェルにはADBHOSTは未設定にしてある)現象も解せないし。やはり、その5555受けの彼らがポイントになる気がする。
というか。
と、いうか。
もう、おとなしくUSBデバッグしておけという話ですね。
そうですね。
にしても、外資系はここら辺、苦労もせずにスイスイですよねぇ、ググってるとそう思える。
ガラスマめ、愛い奴。
有線で仕込んでいない場合の挙動は
(端末起動直後)
>SET ADBHOST={IPアドレス}
>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
てな具合で、デバイス列挙が皆無。それにしても、persist.service.adb.enable=1なのに、adbdはデバイス起動時点で生きていないのか？
これは、adbd起動時に5555番から奇数番でデバイスエミュレータ接続しに行った結果、接続するものがないという状況らしい。因みに、kill-server->start-serverしてからのadb devicesでも同じ結果。
ということは？5555開けて待機しているデバイスエミュレータがいないこと(いつどこで起動するのか不明)がそもそもの問題であり、adb tcpipやadb connect使うのは、その問題原因を調べてからにしよう。USB接続時のデバイスエミュレータは、adb tcpipやadb connect使うと消え去るため、USBで再接続してもデバイス列挙が皆無になる(その時のシェルにはADBHOSTは未設定にしてある)現象も解せないし。やはり、その5555受けの彼らがポイントになる気がする。
というか。
と、いうか。
もう、おとなしくUSBデバッグしておけという話ですね。
そうですね。
にしても、外資系はここら辺、苦労もせずにスイスイですよねぇ、ググってるとそう思える。
ガラスマめ、愛い奴。
