結論から書くと、<a href="https://unknownplace.org/blog/2019/10/23/v4l2loopback/">前回</a>書いたv4l2loopbackと<a href="https://play.google.com/store/apps/details?id=com.pas.webcam&amp;hl=en_US">IP Webcam</a>というAndroidアプリを組みあわせればいける。
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/48953456078/in/datetaken/" title="2019-10-24-114609_683x549_scrot"><img src="https://live.staticflickr.com/65535/48953456078_1314c4ab25_z.jpg" width="640" height="514" alt="2019-10-24-114609_683x549_scrot"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>

IP Webcamの使い方はいまのところまだよくわかってないが、Start serverすると、 <code>http://ip:8080/video</code> <a class="footref" href="#fn1" id="r1">[1]</a> で、mjpegストリームが取れるっぽいので、
<pre><code class="sh">ffmpeg -i http://ip:8080/video -f v4l2 -pix_fmt yuv420p /dev/video0</code></pre>

とかで流しこんでやればokぽい。 <code>-pix_fmt</code> はないとエラーが出たので適当に付けて回避したものなのでもっと良い指定があるやもしれず。
日本で使っていたカメラや、ノートPCのそれより全然良いので、もはやこれで良いなぁ。
あと、この方法だと、静止画流しこんだり、デスクトップキャプチャを流しこんだり、本来カメラしか使えないところでもいろいろ応用ができるのもよさそう。
<aside class="footdef">
<a href="#r1">[1]</a> ipって書いてるところはスマホのIP。念のため。
</aside>

Pixel3をwebcamとして使う

Windows上でAndroidアプリを開発するとき、普通の人、というかWindowsに慣れている人は、普通にWindows上で開発すればいい案件なのだが、自分にとってはLinuxの世界で開発できたほうがいろいろ都合がよいので、WSL2上で開発をしている。
Android Studioや、<a href="https://github.com/jhen0409/react-native-debugger">react-native-debugger</a>といったツールたちは、WSL2+X Server (X410) という環境でも問題なく動く。
しかし問題はAndroidエミュレータを、WSL2上でうごかすことが現状ではできないのだ。<a class="footref" href="#fn1" id="r1">[1]</a>
それで、いままでうまい方法がよくわからなかったので、WSL2上でつくったapkを、Windowsのほうのadbで <code>adb install</code> して実機なりエミュレータにいれる、というかなりめんどくさいことをしていた。
ただ、通常ほとんどの開発がReact Nativeでのものだったため、ネイティブのほうの実装を変更することはあまりなく、一度apkを実機orエミュレータにインストールさえしてしまえばapkを入れなおす必要はないので、あまり問題にはなっていなかった。
ただ最近はReact Nativeばかり書いていて、何年もネイティブ開発をしていないという状況がつづいてしまっているので、ネイティブのほうのキャッチアップもしておかないとな〜という気持ちがたかまってきていて、Holiday projectとしていま仕事で書いてるわりとでかめのアプリをネイティブで再実装する、というのをはじめていて、そうなるってくるとこのいびつな開発環境だとつらすぎるので、ようやく重い腰をあげて、なにか良い方法はないかしらべはじめた。

<h3>TL;DR:</h3>
Windowsの <code>5037</code> ポートをWSL2へreverse port forward。(WLS2上で 127.0.0.1:5037 がWindowsの5037につながるように、という意味)

<h3>前準備</h3>
Windowsのほうにもadbが必要なのでAndroid Studioをいれておく。どのみちエミュレータをそっちで動かすので入れるとは思うが。

<h3>ポートフォワード</h3>
adbのhelpコマンドを良くみてみると
<pre><code class="text">-H name of adb server host [default=localhost]
-P port of adb server [default=5037]</code></pre>

という部分があって、他のホストのadb serverを使えそうな記述がある。しかし、adbは <code>127.0.0.1:5037</code> にbindしてしまうので、実質そのままでは他のホストにつなぐことはできない。<a class="footref" href="#fn2" id="r2">[2]</a>
なのでポートフォワードしてみることにした。方法はいろいろあるが、自分の場合はWSL1の環境もあるので、WSL1から
<pre><code class="sh">ssh -R 5037:127.0.0.1:5037 127.0.0.1</code></pre>

としている。127.0.0.1に接続していてなんのこっちゃという感じだが、Windowsホストの22番ポートはWSL2ホストにforwardされるようにしているのでこれでWSL2につながるのである。そうしてない人は接続先をWSL2のアドレスにする必要あり。
あと、これをする前にWSL2上でadb serverがうごいている場合はあらかじめ <code>adb kill-server</code> しておく、またWindowsのほうでは <code>adb start-server</code> しておく必要がある。<a class="footref" href="#fn3" id="r3">[3]</a>
この状態で、WSL2上で <code>adb devices</code> とかしてみると、Windowsのほうに繋っているエミュレータや実機が普通に見えるようになっているはず。adb shellや、adb installなどもWindowsから操作するのとおなじことがWSL2からおこなえるようになる。便利!
いままでこの環境だとうまく使えなかった<a href="https://fbflipper.com/">Flipper</a>もちゃんと(WSL2サイドで)動くようになってうれしいかぎり。

<h3>余談</h3>
とまぁ、最終的には実際5037を転送するだけでよかったのだが、最初はリモートのAndroidエミュレータに繋ぐ方法、みたいな検索ワードで調べていたのでまったく答えにたどりつけず、ハマりにハマってかなりの時間をとかしてしまった。あと、Flipperを起動するとadb serverが自動で起動されてしまうことに気付かず、 <code>kill-server</code> してるのになぜか終了できない!(pidがかわってうまれかわってくる)、みたいになってWSL2上のadb serverがとめられなくなったりもした。pstreeでみてみてもsystemdが親にみえるため、Flipperが原因だとはなかなか気が付けなかった。
とはいえ最終的につかえるようになったので、時間をかけたうえに「なんの成果も!! 得られませんでした!!」となる最悪の自体はさけられたのでよしとしよう。
<aside class="footdef">
<a href="#r1">[1]</a> intel CPUの人はできるかもしれない。AMDのCPUではまだ<a href="https://techcommunity.microsoft.com/t5/virtualization/amd-nested-virtualization-support/ba-p/1434841">nested virtualizationが一般向けには降りてきていない</a>ので使えないっぽい 
<a href="#r2">[2]</a> <code>-a</code> というオプションが <code>listen on all network interfaces, not just localhost</code> と書いてあるけどこれつけて <code>start-server</code> しても127.0.0.1にbindされていた😅
<a href="#r3">[3]</a> たぶんデフォルトの状態だとAndroidエミュレータを起動するだけでadb serverもたちあがるようになってるので実際はwindowsのほうで明示的にadb serverを上げることはあまりないかもしれない 
</aside>

WSL2のadbからWindowsのAndroid Emulatorを使う

TLDR: <a href="https://unknownplace.org/blog/2019/01/24/grive/">Google Drive経由で同期していた</a>orgファイルなどの同期を<a href="https://syncthing.net/">Syncthing</a>を使うように変更したら劇的に便利になった、という話。
最近はorg-modeを使いたおしている<a class="footref" href="#fn1" id="r1">[1]</a>のだが、いままではorgファイルの同期をGoogle Drive経由でやっていた。
これにいろいろ不満あった:
<ol>
<li>grive2がちょいちょい動かなくなる</li>
<li>grive2がちょくちょくビルドできなくなる or OAuth認証ができなくなる</li>
<li>Androidとの同期が微妙</li>
</ol>

1は、Google Driveへの同期ツールとしてgrive2というのを使っているのだが、このgrive2がたまーにうごかなくなることがある。
これはほとんどの場合、ArchLinuxでgrive2は公式パッケージには入っておらずAURになっているがboostに依存している、というのが原因。boostが更新されてもAURであるgrive2はそのまま再ビルドされないままになってしまい、結果libraryが読めなくなってうごかなくなる。
2は、ビルドできなくなるのはArchLinuxが新しすぎるパッケージを採用しすぎるのが原因なきがするが、最近も<a href="https://github.com/vitalif/grive2/issues/370">最新のgrepが入ってるとビルドできない</a>、みたいなのがあってこまった。OAuthのほうはよくわからないが(Googleのポリシー周り？)、しばらく新規認証できなくて新しいPCを同期対象にできなかったりもあった。
3はAndroidはGoogleケータイだしネイティブでGoogle Drive同期できるのでは？ みたいに思うかもしれませんが、実際のファイルとして同期しようとするとサードパーティツールをつかわないとできないのですね。<a href="https://play.google.com/store/apps/details?id=com.ttxapps.drivesync">Autosync for Google Drive</a>というのを使っていたが、これは無料だと1時間に1回しか同期してくれないのであった。
有料でもそんなに高くないのだけど、1,2の理由からGoogle Driveでのファイル同期は微妙だなという思いがあって購入しないままいまにいたる。
Androidでのorgの編集は
<ul>
<li>出先でなにかおもいついたことをinboxにメモ(あとでPC上でグルーミング)</li>
<li>習慣をやったよ、とマークする</li>
</ul>

だけなので、基本的に1時間syncでも問題がないというのもあった。
そんな感じでgriveをちょいちょい直して使う、みたいなことをしていたのだが、grepが原因でビルドできなくなったのをきっかけにもうこんなんやってられーん、という感じになってしまい重い腰をあげてなんとかしようとしてみた。
日常使っている端末(PC, Mac, Android)でいいかんじでファイル同期ができるものを探したところ、Syncthingがよさそうに思ったのでとりあえず評価してみた。<a class="footref" href="#fn2" id="r2">[2]</a>
結果、問題もなくはないが、同期の速度は爆速だし、Androidのバッテリー消費もそんなにわるくなってないように見えるし、体感としてはとてもよい。なにより、ふと気付いたらうごかなくなってる、みたいなgriveにあった不安さもないのが最高。
というわけでorgファイル以外もSyncthingをつかって同期するようになって、いまではこんな感じに。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52658627437/in/datetaken-public/" title="My Syncthing sync flow"><img src="https://live.staticflickr.com/65535/52658627437_8133943baf_k.jpg" width="2048" height="901" alt="My Syncthing sync flow"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

<ul>
<li>orgファイル同期</li>
<li>Pixel 7とPixel 3の写真同期</li>
<li>一部ソースコードをLinuxとMacで同期</li>
</ul>

orgファイルの同期、PC/Mac間ではそこまで使い勝手に差はないが、やはりモバイルでした変更が即座にPCに反映されるのはあたりまえだけど便利だった。キッチンでコーヒーいれているときに思いついたことをinboxにいれて仕事部屋にもどってきても、その変更はまだきてない、みたいなことがなくなった。
Pixel 7と3の写真同期はまぁ単純にGoogle Photosの容量をケチってPixel 3経由でアップするようにする用。
ソースコード同期がやってみたら意外にも便利で手放せなくなった。
具体的には <code>~/dev/src/sync</code> 以下が自動で同期されるようにした。基本的に進行中のprojectのソースコードを置いておく。 同期しないディレクトリも指定できるので、RustのtargetディレクトリとかNodeのnode_modulesディレクトリとかはsyncしないようにもできる。便利!
これによってキリの悪いところで作業が中断してレポジトリにpushできていなくても、そのままの状態を他の端末で再開できるようになってかなり快適になった。
ただ、問題がないわけではなくて、以下のような問題があった:
<ol>
<li>Google Driveとはちがってバックアップがない</li>
<li>Hyper-VのNATを超えられない</li>
<li>Androidアプリが止まってることがある</li>
</ol>

1は上の図にもあるように、Windowsにもorgファイルをread onlyでコピーされるようにして、そこをGoogle Driveでバックアップする、というような運用にした。Windowsでやるのはgriveをつかいたくなかったからです。
このようにread onlyかread/writeかというような同期方法を選べるのも良いポイント。Pixel間の写真同期はあえてread/writeにしていて、こうするとPixel 3のほうのPhotoアプリでCleanup spacesするとPixel 7のほうも消えてくれて楽。
2は、自分のHyper-V VMのネットワークはNATを使って外に出ているのだが、このNATをSyncthingがうまくあつかえない模様。
Sync対象が外からみて同じグローバルIPを持っているとおなじLANにいる想定でうごいてしまうのか(?)、うまくおたがいをさがせなくなってしまう。
これは常時VPNを張っておくことで解決できた。PC/Macはもともと<a href="https://www.zerotier.com/">zerotier</a>を使ってつながっていたので、そこにAndroidも追加する形。
3は、めったにないのだが、ごくまれにAndroidアプリが止まっていることがある。再起動したタイミングとかなのかな？
まぁとにかく動作中は通知領域にアイコンがでるので、止まってる場合そのアイコンが消えているのでわりとすぐに気が付けるので良いのだけど、
ほんとはつねに通知領域にでているのはウザいので消してしまいたいのだが、そうすると止まっていることに気が付けないので消すに消せなくなっている…。これはちょっと残念ポイント。
そんなわけで良い点ばかりではないものの、トータルではとても良いものです。おすすめ。
<aside class="footdef">
<a href="#r1">[1]</a> <a href="https://unknownplace.org/blog/2021/05/06/org-protocol-wsl-subsystemd/">ここ</a>で書いた家族との共有以外はすべてorg-modeでやるように戻ってしまっている 
<a href="#r2">[2]</a> Syncthingは公式にはiOSに対応していないので、iOSで使いたい人は注意されたし。サードパーティ製はいくつかある模様 
</aside>

2023

2021

2019