BLOCKERS: переписан по факту (B-1 не подтверждён, B-2 — нет DebugResponse в RESPONSE_MAP, B-3 — очки на другом WiFi)
This commit is contained in:
+68
-45
@@ -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 подтверждён в конце ночной сессии).
|
||||
|
||||
Reference in New Issue
Block a user