Windows上のWSLからRedmi Pad SE 8.7へADB接続し、Drogger Androidアプリの実機試験を行う環境を対象とする。Windows再起動やWSL停止で連続試験が中断された場合は、本書の順序どおりに復旧する。
この環境では、USB機器を直接扱えないWSL版ADBではなく、WindowsがUSB接続しているタブレットを認識できるWindows版ADBをWSLから呼び出す。WSL版とWindows版のADBサーバーを同時に起動すると、TCP 5037番ポートが競合するため混在させない。
WSLからWindows PowerShellを呼び出す。
POWERSHELL=/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
"$POWERSHELL" -NoProfile -Command \
"Get-PnpDevice -PresentOnly | Where-Object { \$_.FriendlyName -match 'Android|ADB|Xiaomi|Redmi|Pad' } | Format-Table -AutoSize Status,Class,FriendlyName,InstanceId"
Redmi Pad SE 8.7がOKで表示されれば、タブレットのUSB接続とWindows側ドライバーは認識されている。表示されない場合は、次を順に行う。
/dev/bus/usbがWSLに無いことだけでは、タブレット故障やUSBデバッグOFFとは判断しない。本環境ではWindows版ADBを使うため、WSLからUSBデバイスが直接見えなくてもよい。
Windows版ADBのパスを取得する。
ADB_WIN="$(wslpath -u "$("$POWERSHELL" -NoProfile -Command '(Get-Command adb.exe).Source' | tr -d '\r')")"
printf '%s\n' "$ADB_WIN"
空の場合は、WindowsにAndroid Platform Toolsが導入されているか確認する。
試験が動いていないことを確認してから、WSL版ADBと残留したWindows版ADBを停止し、Windows版サーバーを1個だけ起動する。
adb kill-server 2>/dev/null || true
"$POWERSHELL" -NoProfile -Command \
"Get-Process adb -ErrorAction SilentlyContinue | Stop-Process -Force; Start-Sleep -Seconds 1; & (Get-Command adb.exe).Source start-server"
この操作は実行中のADB logcatも停止する。既存の試験プロセスが生きている場合は、先に出力ディレクトリと状態を確認する。
"$ADB_WIN" devices -l
状態ごとの対処:
| 表示 | 対処 |
|---|---|
device |
認証済み。次へ進む |
unauthorized |
タブレットで「このパソコンから常に許可する」を選び、「許可」を押す |
| 一覧が空 | ケーブルを抜き差しし、再実行する |
offline |
Windows版ADBを停止・再起動し、必要ならケーブルを抜き差しする |
一覧表示だけでなく、短いshell通信も確認する。
"$ADB_WIN" shell echo ok
"$ADB_WIN" shell getprop ro.product.model
devicesではdeviceなのにshellが戻らない場合、タイムアウトしたADBクライアントが残留している可能性がある。手順2のWindows版ADB全停止・再起動をもう一度行う。診断用のadb nodaemon serverは、調査後に残さない。
capture_long_run.shは開始時にlogcatバッファをクリアする。再試験を始める前に、端末のリングバッファへ残っているログを固定パスへ退避する。
RECOVERY_DIR=session_logs/android-long-run/recovery-$(date +%Y%m%dT%H%M%S)
mkdir -p "$RECOVERY_DIR"
"$ADB_WIN" logcat -d -v threadtime > "$RECOVERY_DIR/logcat-after-reboot.log"
wc -l -c "$RECOVERY_DIR/logcat-after-reboot.log"
リングバッファには直近分しか残らないため、旧試験全体を復元できるとは限らない。救出できた範囲とファイルサイズをIssueへ記録する。
ADB="$ADB_WIN" tools/android/check_android_baseline.sh --markdown
9項目すべてがPASSであることを確認する。あわせて実機画面で次を確認する。
FAILがある状態で連続試験を再開しない。
再起動後に探しやすい固定名を使い、可能なら--durationで終了時刻を明示する。
OUT_DIR=session_logs/android-long-run/issue18-retry-$(date +%Y%m%d)
ADB="$ADB_WIN" tools/android/capture_long_run.sh \
--out-dir "$OUT_DIR" \
--snapshot-interval 300 \
--duration 18000
上記は5時間で終了する。WSLを終了するとキャプチャも止まるため、試験中はWindowsをスリープ・再起動せず、WSLを終了しない。
開始直後に別端末から次を確認する。
wc -l -c "$OUT_DIR/logcat.log" "$OUT_DIR/snapshots.tsv"
tail -3 "$OUT_DIR/snapshots.tsv"
試験終了後は要約する。
tools/android/summarize_long_run.sh "$OUT_DIR/logcat.log" "$OUT_DIR/snapshots.tsv"
WSLの起動時刻はWindows本体の起動時刻ではない。WSL uptimeからWindows再起動時刻を推定しない。
Windows本体の最終起動時刻:
"$POWERSHELL" -NoProfile -Command \
"Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime,LocalDateTime | Format-List"
主なイベントID:
| ID | 意味 |
|---|---|
| 1074 | プロセスまたはユーザーが要求した計画済み再起動。Message内のプロセス名と理由を確認する |
| 6006 | Event Logサービスの正常停止 |
| 12 / 6005 | OS/Event Logの起動 |
| 41 | 正常なシャットダウンを経ない電源断・クラッシュ |
| 6008 | 予期しないシャットダウン |
直近の計画済み再起動を確認する。
"$POWERSHELL" -NoProfile -Command \
"Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074; StartTime=(Get-Date).AddDays(-7)} | Sort-Object TimeCreated | Select-Object -Last 10 | Format-List TimeCreated,ProviderName,Message"
2026-07-15のIssue #18中断時は、09:26 JSTをWindows再起動時刻とする当初推定は誤りだった。実際には20:29〜20:32 JSTにMoUsoCoreWorker.exeとTrustedInstaller.exeがSYSTEM権限でWindows Updateの計画済み再起動を要求し、正常に2回再起動していた。09:26は翌朝のWSL起動時刻だった。クラッシュや試験手順による再起動の証拠は無かった。
OKadb devices -lがdeviceadb shell echo okが完了OUT_DIRと明示的な--durationで再開