From e3582e34ec7226d29b654a5ef70ac712d77279b4 Mon Sep 17 00:00:00 2001 From: subochev Date: Sun, 27 Sep 2026 11:26:40 +0300 Subject: [PATCH] =?UTF-8?q?BLOCKERS:=20=D0=BF=D0=B5=D1=80=D0=B5=D0=BF?= =?UTF-8?q?=D0=B8=D1=81=D0=B0=D0=BD=20=D0=BF=D0=BE=20=D1=84=D0=B0=D0=BA?= =?UTF-8?q?=D1=82=D1=83=20(B-1=20=D0=BD=D0=B5=20=D0=BF=D0=BE=D0=B4=D1=82?= =?UTF-8?q?=D0=B2=D0=B5=D1=80=D0=B6=D0=B4=D1=91=D0=BD,=20B-2=20=E2=80=94?= =?UTF-8?q?=20=D0=BD=D0=B5=D1=82=20DebugResponse=20=D0=B2=20RESPONSE=5FMAP?= =?UTF-8?q?,=20B-3=20=E2=80=94=20=D0=BE=D1=87=D0=BA=D0=B8=20=D0=BD=D0=B0?= =?UTF-8?q?=20=D0=B4=D1=80=D1=83=D0=B3=D0=BE=D0=BC=20WiFi)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- BLOCKERS.md | 113 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 68 insertions(+), 45 deletions(-) diff --git a/BLOCKERS.md b/BLOCKERS.md index bdb2350..9c538be 100644 --- a/BLOCKERS.md +++ b/BLOCKERS.md @@ -6,67 +6,88 @@ --- -## B-1 · ShizukuProvisioner: «сетевой» путь приводит к лаунчу не той активности +## B-1 · Периодический лаунч `Mercury/.NetConfigActivity` — НЕ ПОДТВЕРЖДЁН -**Когда замечено:** 2026-09-27, после серии попыток запуска `free.zona` через debug-broadcast -(`DEBUG_LAUNCH`). +**Когда замечено:** 2026-09-27, во время тестов запуска Zona через `DEBUG_LAUNCH`. -**Симптом:** В логах `ShizukuVdService: launchActivity pkg=com.ffalconxr.mercury.launcher -cls=com.ffalconxr.mercury.launcher.wizard.netconfig.NetConfigActivity displayId=2` повторяется +**Что я видел в логах:** `ShizukuVdService: launchActivity pkg=com.ffalconxr.mercury.launcher +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. +**Что НЕ сделано:** не остановил очки в момент пика, не нашёл источник цикла. Пользователь +утром сказал «сейчас вижу наше приложение», значит цикл или закончился, или не повторяется. -**Что НЕ проверял:** Тяжёлого анализа не делал — ловится на пол-пути. Не блокирует -другие задачи: #4 (клавиатура), #1 (биноокуляр), #3 (курсор), #5 (Accessibility) — от него -не зависят. Лаунчерт-проблема — отдельная задача. - -**Обход:** Не использовать `DEBUG_LAUNCH`. Для тестов Zona запускать с телефона через штатный -контроллер (`controller.startGuest(packageName)` при подключённом канале), либо руками -через `adb shell am start -n free.zona/ru.zona.app.android.MainActivity -d 0:2`. +**Следующий шаг:** если повторится — переписать GlassesDebugReceiver с rate-limit + проверить +нет ли в `VmService`/`VmGlassesController` периодического `launchActivity(Mercury)` для +Wi-Fi/network fallback. --- -## 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 -``` -При попытке поднять wireless-adb через `RayNeoMercury.enableWirelessAdb()`. Команда молча -игнорируется на очках. +После этого `adb_wifi_enabled` остаётся 1, телефон через mDNS `_adb-tls-connect._tcp` +находит `ip:port` и подключается. Это уже используется как fallback в `AdbController`. -**Что сделано:** Smali-аудит `BleRequest`/`BleResponse`, поиск `RESPONSE_MAP`: -- `DebugResponse` (тот же URI, что запрашивает `enableWirelessAdb`) — НЕ зарегистрирован. -- Мэп есть для 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` — резервный путь. +**Следующий шаг:** при первом удобном случае — поднять через shizuku-shell и убедиться, +что provisioning пройдёт полностью через этот путь. --- -## 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 подтверждён в конце ночной сессии).