6.8 KiB
Blockers
Сюда пишутся только те задачи/проблемы, в которых застряли. Каждая запись — задача,
что сделано, в чём стена, что проверено, варианты обхода. Записи ведутся по правилам
ночной сессии (см. TASKS.md, секция «Правила ночной сессии»).
B-1 · Периодический лаунч Mercury/.NetConfigActivity — НЕ ПОДТВЕРЖДЁН
Когда замечено: 2026-09-27, во время тестов запуска Zona через DEBUG_LAUNCH.
Что я видел в логах: ShizukuVdService: launchActivity pkg=com.ffalconxr.mercury.launcher cls=com.ffalconxr.mercury.launcher.wizard.netconfig.NetConfigActivity displayId=2 повторялось
каждые 5 секунд, постоянно.
Что это на самом деле: Непонятно. Это мог быть мой собственный GlassesDebugReceiver,
который я перепосылал несколько раз и он где-то зациклился; мог быть артефакт system-job’а;
мог быть какой-то fallback в VmGlassesController.ensureNetworking(). Не блокер.
Что НЕ сделано: не остановил очки в момент пика, не нашёл источник цикла. Пользователь утром сказал «сейчас вижу наше приложение», значит цикл или закончился, или не повторяется.
Следующий шаг: если повторится — переписать GlassesDebugReceiver с rate-limit + проверить
нет ли в VmService/VmGlassesController периодического launchActivity(Mercury) для
Wi-Fi/network fallback.
B-2 · rayneo-mercury: enableWirelessAdb через BLE на X3 Pro не возвращает адрес
Когда выяснено: 2026-09-27, аудит прошивки RayNeoLauncher по smali
(adb pull /system/app/RayNeoLauncher).
Что происходит (по smali + логам):
- Телефон шлёт BLE-команду
ble.request.debugсpayload.cmd="enableWirelessAdb". - Очки принимают команду и реально поднимают беспроводной adb (мы видим
adb_wifi_enabled=1иservice.adb.tcp.portпосле). Это работает. - Очки должны прислать событие
WirelessAdbAddressобратно. Это не происходит. - В smali
BleResponseестьRESPONSE_MAP, в котором зарегистрированы Wi-Fi / media / netconfig ответы — ноDebugResponseотсутствует. Поэтому маршрутизация ответа по URIble.request.debugне настроена, и событие теряется. - Телефон вечно ждёт
Event.WirelessAdbAddress, не получает его и уходит в таймаут.
Что это значит для provisioning:
- Команда
enableWirelessAdbчерез BLE включает adb — но адресip:portмы узнать не можем. - Provisioning сейчас работает только потому, что adb уже был включён раньше (например,
руками или через shizuku) и не выключился после ребута. После ребута очков — если
adb_wifi_enabledсбросится в 0 — provisioning сломается, потому что новый адрес мы узнать не сможем.
Обходной путь (уже работает):
# Через shizuku shell на очках:
service call adb 4 i32 1 s16 'Caffeine Portable' # включить adb
settings put global adb_wifi_enabled 1 # не дать ему автоотключиться
После этого adb_wifi_enabled остаётся 1, телефон через mDNS _adb-tls-connect._tcp
находит ip:port и подключается. Это уже используется как fallback в AdbController.
Следующий шаг: при первом удобном случае — поднять через shizuku-shell и убедиться, что provisioning пройдёт полностью через этот путь.
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 · Финал: гашение экрана обязательно в конце
По ночным правилам — на завершении всех задач ИЛИ при невозможности продолжать — выполняется:
adb -s A06B4AB933C4103 shell input keyevent 223
и проверка mWakefulness=Dozing/Asleep. Если не работает — через ScreenControl (Канал 1) /
Shizuku SET_SCREEN.
Статус: выполнено (mWakefulness=Dozing подтверждён в конце ночной сессии).