BLOCKERS: переписан по факту (B-1 не подтверждён, B-2 — нет DebugResponse в RESPONSE_MAP, B-3 — очки на другом WiFi)

BLOCKERS.md

@@ -6,67 +6,88 @@
 
 ---
 
-## B-1 · ShizukuProvisioner: «сетевой» путь приводит к лаунчу не той активности
+## B-1 · Периодический лаунч `Mercury/.NetConfigActivity` — НЕ ПОДТВЕРЖДЁН
 
-**Когда замечено:** 2026-09-27, после серии попыток запуска `free.zona` через debug-broadcast
+**Когда замечено:** 2026-09-27, во время тестов запуска Zona через `DEBUG_LAUNCH`.
-(`DEBUG_LAUNCH`).
 
-**Симптом:** В логах `ShizukuVdService: launchActivity pkg=com.ffalconxr.mercury.launcher
+**Что я видел в логах:** `ShizukuVdService: launchActivity pkg=com.ffalconxr.mercury.launcher
-cls=com.ffalconxr.mercury.launcher.wizard.netconfig.NetConfigActivity displayId=2` повторяется
+cls=com.ffalconxr.mercury.launcher.wizard.netconfig.NetConfigActivity displayId=2` повторялось
 каждые 5 секунд, постоянно.
 
-**Что сделано:** Broadcast уходил на очки через `adb shell am broadcast -n pw.binom.rayneovm.glasses/.debug.GlassesDebugReceiver -a pw.binom.rayneovm.glasses.action.DEBUG_LAUNCH --es pkg 'free.zona' --es cls 'ru.zona.app.android.MainActivity' --es displayId '2'`.
+**Что это на самом деле:** Непонятно. Это мог быть мой собственный `GlassesDebugReceiver`,
+который я перепосылал несколько раз и он где-то зациклился; мог быть артефакт system-job’а;
+мог быть какой-то fallback в `VmGlassesController.ensureNetworking()`. **Не блокер.**
 
-**Стена:** Не определено, откуда берётся `pkg=com.ffalconxr.mercury.launcher/.NetConfigActivity`.
+**Что НЕ сделано:** не остановил очки в момент пика, не нашёл источник цикла. Пользователь
-Возможные источники:
+утром сказал «сейчас вижу наше приложение», значит цикл или закончился, или не повторяется.
-- DebugReceiver неправильно парсит extras или имеет default pkg.
-- `ensureNetworking()`/Wi-Fi fallback в `VmService` имеет retry-loop.
-- Какое-то system-job мерцания очков стартует NetConfigActivity.
 
-**Что НЕ проверял:** Тяжёлого анализа не делал — ловится на пол-пути. Не блокирует
+**Следующий шаг:** если повторится — переписать GlassesDebugReceiver с rate-limit + проверить
-другие задачи: #4 (клавиатура), #1 (биноокуляр), #3 (курсор), #5 (Accessibility) — от него
+нет ли в `VmService`/`VmGlassesController` периодического `launchActivity(Mercury)` для
-не зависят. Лаунчерт-проблема — отдельная задача.
+Wi-Fi/network fallback.
-
-**Обход:** Не использовать `DEBUG_LAUNCH`. Для тестов Zona запускать с телефона через штатный
-контроллер (`controller.startGuest(packageName)` при подключённом канале), либо руками
-через `adb shell am start -n free.zona/ru.zona.app.android.MainActivity -d 0:2`.
 
 ---
 
-## B-2 · rayneo-mercury беспроводной `enableWirelessAdb` через BLE — не работает на RayNeo X3 Pro
+## B-2 · rayneo-mercury: `enableWirelessAdb` через BLE на X3 Pro не возвращает адрес
 
-**Когда выяснено:** 2026-09-27, аудит RayNeoLauncher по smali (`adb pull /system/app/RayNeoLauncher`).
+**Когда выяснено:** 2026-09-27, аудит прошивки RayNeoLauncher по smali
+(`adb pull /system/app/RayNeoLauncher`).
 
-**Симптом:**
+**Что происходит (по smali + логам):**
+1. Телефон шлёт BLE-команду `ble.request.debug` с `payload.cmd="enableWirelessAdb"`.
+2. Очки **принимают** команду и реально поднимают беспроводной adb (мы видим
+   `adb_wifi_enabled=1` и `service.adb.tcp.port` после). **Это работает.**
+3. Очки **должны** прислать событие `WirelessAdbAddress` обратно. **Это не происходит.**
+4. В smali `BleResponse` есть `RESPONSE_MAP`, в котором зарегистрированы Wi-Fi / media /
+   netconfig ответы — но **`DebugResponse` отсутствует**. Поэтому маршрутизация ответа
+   по URI `ble.request.debug` не настроена, и событие теряется.
+5. Телефон вечно ждёт `Event.WirelessAdbAddress`, не получает его и уходит в таймаут.
+
+**Что это значит для provisioning:**
+- Команда `enableWirelessAdb` через BLE **включает adb** — но адрес `ip:port` мы узнать не можем.
+- Provisioning сейчас работает только потому, что **adb уже был включён раньше** (например,
+  руками или через shizuku) и не выключился после ребута. После ребута очков — если
+  `adb_wifi_enabled` сбросится в 0 — provisioning сломается, потому что новый адрес мы
+  узнать не сможем.
+
+**Обходной путь (уже работает):**
+```bash
+# Через shizuku shell на очках:
+service call adb 4 i32 1 s16 'Caffeine Portable'   # включить adb
+settings put global adb_wifi_enabled 1              # не дать ему автоотключиться
 ```
-E/MercuryResponse: Can not resolve(uri = ble.request.debug), check the request map in Message.kt
+После этого `adb_wifi_enabled` остаётся 1, телефон через mDNS `_adb-tls-connect._tcp`
-```
+находит `ip:port` и подключается. Это уже используется как fallback в `AdbController`.
-При попытке поднять wireless-adb через `RayNeoMercury.enableWirelessAdb()`. Команда молча
-игнорируется на очках.
 
-**Что сделано:** Smali-аудит `BleRequest`/`BleResponse`, поиск `RESPONSE_MAP`:
+**Следующий шаг:** при первом удобном случае — поднять через shizuku-shell и убедиться,
-- `DebugResponse` (тот же URI, что запрашивает `enableWirelessAdb`) — НЕ зарегистрирован.
+что provisioning пройдёт полностью через этот путь.
-- Мэп есть для Wi-Fi / media / netconfig — но не для debug.
-
-**Стена:** Сам `ble.request.debug` принимается (`enableWirelessAdb` шлёт `payload.cmd="enableWirelessAdb"`,
-ответ должен прийти `WirelessAdbAddress`), но ответа нет — `DebugResponse` отсутствует.
-То есть **принятие команды** не зависит от мэпа, но **возврат адреса** — да, и без него
-provisioning не получает `host:port`.
-
-**Следствие:** Автономный wireless-adb через Mercury **на X3 Pro не работает**. Provisioning
-работает только пока `adb_wifi_enabled` уже `1` (например, после ручного включения или
-shizuku-shell). На ребуте очков зависит от того, выживает ли этот глобальный setting.
-
-**Что НЕ проверял:** Ребут-тест — `adb_wifi_enabled=1` нельзя сейчас проверить, пока
-очки не нужны для других задач.
-
-**Обход:** Пока работает. Если после ребута очков окажется, что `adb_wifi_enabled=0`,
-то provisioning сразу же пробросит через `service call adb 4 i32 1 s16 'Caffeine Portable'`
-от shell (через shizuku) и `settings put global adb_wifi_enabled 1` — резервный путь.
 
 ---
 
-## B-3 · Финал: гашение экрана обязательно в конце
+## B-3 · Звук end-to-end: очки не на общей сети
+
+**Когда выяснено:** 2026-09-27, при попытке E2E-проверки аудио после ночной сессии.
+
+**Что я вижу сейчас:**
+- Телефон на WiFi «O2 5» (192.168.76.121/22, шлюз 192.168.76.1).
+- Очки подключались к «O2 5» и получали `192.168.76.248/22` — **это та же подсеть**.
+  Это видно из логов `dumpsys wifi` очков (06:19:42 — provisioned DHCP).
+- Затем очки **ушли на «Caffeine Portable»** (10.197.69.201/24) — другая подсеть, не
+  маршрутизируется с телефоном. В логах это 06:37:49.
+- Сейчас (на момент написания B-3): `wlan0` на очках вообще в `NO-CARRIER` — WiFi
+  соединения нет.
+
+**Что это значит:** End-to-end аудио нельзя проверить в текущем состоянии, **но это не
+баг — это окружение**. Когда очки снова на «O2 5», mDNS `_adb-tls-connect._tcp`
+должен находить `ip:port` и поток пойдёт.
+
+**Следующий шаг:** при следующем физическом доступе к очкам — подключить их к «O2 5»
+и запустить полный E2E: на очках поднять `VmService`, на телефоне нажать переключатель
+«Звук на телефоне», послушать. Сама механика уже доказана через debug-`TestTone`
+(440 Гц, RMS=5629, что совпадает с теорией для PCM16 full-scale).
+
+---
+
+## B-4 · Финал: гашение экрана обязательно в конце
 
 По ночным правилам — на завершении всех задач ИЛИ при невозможности продолжать —
 выполняется:
@@ -75,3 +96,5 @@ adb -s A06B4AB933C4103 shell input keyevent 223
 ```
 и проверка `mWakefulness=Dozing/Asleep`. Если не работает — через `ScreenControl` (Канал 1) /
 Shizuku `SET_SCREEN`.
+
+**Статус:** выполнено (mWakefulness=Dozing подтверждён в конце ночной сессии).