いまさらAndroid端末にすばやくWiFiで接続する

なんとなく面倒なのでスクリプトで。

USBで接続のあと #5555 で待たせて再起動する。

「restart」なので、kill-server → start-server は不要。


adb tcpip 5555

IPアドレスをコマンドラインから取得。


ip="$(adb shell ip route | awk '{print $9}')"

そのIPにWiFi接続。


adb connect $ip



 

まとめ

ついでに、開発時には邪魔なスリープもOFFに。


adb shell svc power stayon true

How to prevent an android device from entering sleep (via adb command shell) - Stack Overflow

connect_via_wifi.sh


#!/bin/sh

adb tcpip 5555

sleep 1

ip="$(adb shell ip route | awk '{print $9}')"

adb connect $ip

adb shell svc power stayon true

adb devices -l

端末内 adbd の TCPモード(#5555)が起動している限り再接続が可能。

なので、USB接続なしの状態でも

IPの目処つけて 「adb connect」 でどうぞ。


~ $ adb devices
List of devices attached

~ $ get-oui -v
Renaming ieee-oui.txt to ieee-oui.txt.bak
Fetching OUI data from http://standards-oui.ieee.org/oui/oui.txt
Fetched 4084734 bytes
Opening output file ieee-oui.txt
25968 OUI entries written to file ieee-oui.txt

~ $ sudo arp-scan -l
Interface: en0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.1	8a:af:ec:9c:91:08	BUFFALO.INC
192.168.0.2	dc:23:76:3d:9b:75	HTC Corporation
192.168.0.3	d0:27:82:f5:e8:2a	AzureWave Technology Inc.
192.168.0.8	8c:85:00:14:89:d1	Murata Manufacturing Co., Ltd.
192.168.0.4	a2:37:e3:12:9a:88	HTC Corporation
192.168.0.6	33:28:6d:29:7b:72	Google, Inc.

~ $ adb connect 192.168.0.4
connected to 192.168.0.4:5555

~ $ adb devices
List of devices attached
192.168.0.4:5555	device

初回の、USBケーブルなしでTCPモードを起動できないのはセキュリティ絡みでか。

ADBオーバーネットワークでWiFiで複数端末を一括接続する

Android Devices Being Shipped with TCP Port 5555 Enabled - DEV Community 👩‍💻👨‍💻

@ObsoleteCoroutinesApi とは「様子見」?

Coroutine で Channel 辺りをウロウロと。

あれ?

This declaration is experimental and its usage should be marked with '@kotlinx.coroutines.ObsoleteCoroutinesApi' or '@UseExperimental(kotlinx.coroutines.ObsoleteCoroutinesApi::class)'

調べてみる。

From the point of usage `ObsoleteCoroutinesApi` is just like experimental. The different is in intent. When API is experimental it might change or might graduate as is. For obsolete API we already know that there are problems with designs that will force us to deprecated this API in the future when we have a better replacement.

Right now there is no replacement for channel operations, so you have no choice but continue using them. However, we plan to replace them with mechanism based on lazy/cold streams (#254) in the future, which will get you much better performance.

What is the recommended approach for @ObsoleteCoroutinesApi #632

Google翻訳で。

使用の観点からObsoleteCoroutinesApiは実験的なようです。 違いは意図しています。 APIが実験的なものである場合、それは変更されるか、またはそのまま卒業するかもしれません。 時代遅れのAPIについては、より良い代替品があるときに将来的にこのAPIを非推奨にするような設計上の問題があることはすでにわかっています。

今のところチャンネル操作に代わるものはないので、あなたには選択肢がないがそれらを使い続けることができる。 ただし、将来的にはレイジー/コールドストリーム（＃254）に基づくメカニズムに置き換える予定です。これにより、パフォーマンスが大幅に向上します。

まとめ


@ExperimentalCoroutinesApi

→ 将来的には、変更される or そのまま。




@ObsoleteCoroutinesApi

→ 設計上の問題がある。

→ 今現在、代替えはない。

→ 将来的には非推奨。

アンダースコアがついてるのはそゆこと?


_events.consumeEach {

チャンネル周りは、今は「様子見」がいいのでしょうね。

Google「音声文字変換」アプリを試す



「スピード」と「精度」がどんなものなのか。

音声文字変換 - Google Play のアプリ

ホリエモンのトークで試してみます。





うん。十分使えると思います。

自宅でネットがつながらない時の連絡先と話し方

ネットが繋がらなくなっとき。

「サポートに電話しよう。」などと考えます。

面倒くさい謎の説明を受けた挙げ句、たらい回しにされることが多いですよね。

電話するにも、電話番号がたくさんあったり、

プロバイダなのかメーカーなのか、とか。

実際、たらい回されて、しつこく電話して解決した私が少し思うことを書いてみたいと思います。

 

問題位置の把握

パソコンやスマートフォンに到達する前のどこで問題が起きてるか。

切り分けが大事になります。

モデムとルーターのランプから判別しましょう。

POWER(電源)
LINK(物理的接続)
ACT(通信状況)
ALARM(機器異常警告)

順番に確認していきます、

「POWER」はすべてONであるか。

「LINK」はすべてONか。

たぶん、ここは、フツーの家電感覚で確認できます。

電源スイッチか配線を疑いましょう。

「ACT」ランプは、通信の状況に合わせて、

不定期に点滅

するのが正常です。

正常な場合。



光モデムの場合、問題が、VDSL側(壁側)かLAN側か、をランプで明快に確認できます。

今回、私の場合、「VDSL LINK/ACT」のランプが、「定期的な点滅」だったので、上流であるそこを疑いました。

連絡先は、「NTT東日本」です。

サポートセンターの方に、ランプの確認のあと、

「ケーブル端子の抜き差し」

をするように言われたあと、1分ほど待っていたら正常な元気なランプの点滅が始まり、ネット利用ができるようになりました。

 

まとめ

今回学んだ問い合わせのコツとしては、

「上流から問い合わせていく」

ということです。

もし、プロバイダやルーターメーカーから電話していたら、もっと復旧に時間がかかったと思います。

その時は会話の中心を

「ランプの状態」

にするとスムーズに話が進みます。

Homebrew を 1.9 から 新 2.0 に更新する方法

macOS用のパッケージマネージャ「Homebrew」の最新版となる「Homebrew 2.0」正式版がリリースされました。

macOS用パッケージマネージャ「Homebrew 2.0」リリース。LinuxとWSL（Windows Subsystem for Linux）にも正式対応 － Publickey

2.0.0 — Homebrew

やってみます。



ん?

なぜか上がってるけど。

そして、

brew cleanup

これだけ?