rayneo-vm/BLOCKERS.md

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 + логам):

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 сломается, потому что новый адрес мы узнать не сможем.

Обходной путь (уже работает):

# Через 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-проверка после восстановления общей сети «O2 5».

Что доказано работающим на очках:

• MediaProjection получается без диалога (PROJECT_MEDIA: allow уже стоит с ночи).
• AudioPlaybackCapture стартует, читает PCM: GlassesAudioCapture: capture: bytes=... rms=....
• 440 Гц TestTone → RMS=5674 (теория ~5657). Реальный звук захвачен, не тишина.
• Динамик очков мутится (STREAM_MUSIC: mute).
• Поток PCM по 4 КБ фреймам идёт в Channel<ByteArray>(capacity=16), готов к WebSocket.
• TCP-порт 8081 на очках (192.168.76.248:8081/vm-audio) отвечает с телефона.

Что не проверено вживую: воспроизведение на телефоне. AudioPlaybackManager код опубликован, но не вызван (controller.setAudioMode(ON_PHONE) никто не дёрнул). UI-переключатель на телефоне готов, но нажать его можно только с руки (в этой сессии PhoneDebugReceiver я не реализовал, broadcast дропается HONOR).

Известный race-condition: MainActivity.handledTick при двойном requestProjection с коротким интервалом пересоздаёт projection → AudioRecord.read -2. Не блокирует нормальную работу (UI нажимается один раз → один tick), но при отладке DEBUG_AUDIO_PIPE после уже активного захвата ломает capture. Чиню при случае.

Следующий шаг: нажать в UI телефона переключатель «Звук на телефоне» — должно зазвучать. Если нет — проверить adb -s AXGL024B05001337 logcat -s AudioPlaybackManager:V.

---

B-4 · Финал: гашение экрана обязательно в конце

По ночным правилам — на завершении всех задач ИЛИ при невозможности продолжать — выполняется:

adb -s A06B4AB933C4103 shell input keyevent 223

и проверка mWakefulness=Dozing/Asleep. Если не работает — через ScreenControl (Канал 1) / Shizuku SET_SCREEN.

Статус: выполнено (mWakefulness=Dozing подтверждён в конце ночной сессии).