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

**Обходной путь (уже работает):**
```bash
# Через 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 подтверждён в конце ночной сессии).