---
name: telegramwatch-wear-os-plan
description: "TelegramWatch — Telegram-клиент для Galaxy Watch Ultra. Подход (TDLib + Compose for Wear OS), отброшенные ветки, текущий статус."
metadata: 
  node_type: memory
  type: project
  originSessionId: 80dc2fd3-590d-4bea-bfd3-273ca9d44e37
---

Цель — собственное Telegram-приложение для **Samsung Galaxy Watch Ultra** (Wear OS 5, API 34), работающее независимо от телефона (Wi-Fi/LTE-eSIM).

**Why:** Пользователь хочет полноценный мессенджер на часах — текст, голос, в перспективе звонки. Не companion к телефону.

**How to apply:** В будущих сессиях про TelegramWatch — проверять текущий статус в этом memory и в task list. Не повторять отброшенные подходы.

### Принятый подход (2026-05-20)
**TDLib (C++ библиотека Telegram) + Compose for Wear OS UI с нуля.**

Не форк DrKLO/Telegram — у него ~500k строк UI на кастомных View, не Compose, и 2000+ файлов native кода (libyuv/libvpx/breakpad/rlottie/ffmpeg). Из всего этого Wear OS клиенту нужен только MTProto-слой (tgnet) — и эту же роль ровно играет TDLib, который собирается чисто на ARM Mac.

### Отброшенные ветки
- **Полноценная сборка DrKLO/Telegram на ARM Mac** — не собирается ни с одним NDK (r21 через Rosetta падает libc++abi crash; r25 ломает libvpx ASM target; r26 ломает libyuv GAS-директивы). Telegram-разработчики собирают только в Docker на Linux x86_64. Папка `~/Разработки/TelegramWatch/Telegram/` оставлена как референс для tgnet/MTProto-кода.
- **api_id/hash с my.telegram.org** — у пользователя не получается зарегистрировать. Для dev используем встроенные test-creds `APP_ID=4 / APP_HASH=014b35b6184100b085b0d0572f9b5103` (лимит ~5-20 msg/день на отправку, получение не лимитировано). К вопросу вернуться перед публикацией.

### Авторизация
QR-логин — на часах нет камеры, поэтому часы **показывают** QR, юзер сканит из основного TG-приложения на телефоне. Обычный phone+SMS невозможен без камеры/eSIM.

### Текущий статус (2026-05-20)
- ✅ Wear OS pipeline работает: ComposeStarter → APK → AVD GalaxyWatchUltra → Hello World
- ✅ Все toolchain настройки на месте (см. [[android-dev-setup-macos-tahoe]])
- ✅ **TDLib собран** в `~/Разработки/TelegramWatch/td/example/android/tdlib/`:
  - `libs/{arm64-v8a,armeabi-v7a,x86,x86_64}/libtdjni.so` (~21MB каждый)
  - `java/org/drinkless/tdlib/{Client.java,TdApi.java}` (TdApi 4.7MB исходник)
  - Собрано NDK 26.3 + OpenSSL 1.1.1w (через build-openssl.sh + build-tdlib.sh)
- ✅ **TDLib интегрирован в wear-app**, smoke-test проходит:
  - libtdjni.so (arm64-v8a only) → `wear-app/app/src/main/jniLibs/arm64-v8a/`
  - Client.java + TdApi.java → `wear-app/app/src/main/java/org/drinkless/tdlib/`
  - APK 33MB, на эмуляторе видим: "TDLib OK (2 entities)" (вызов `Client.execute(TdApi.GetTextEntities("@username #tag"))`)
- ✅ **QR-логин работает на Test DC** (task #14): TdLibAuthManager.kt + AuthScreen.kt + ZXing 3.5.3 для QR-генерации. Полный flow проходит: WaitTdlibParameters → WaitPhoneNumber → WaitOtherDeviceConfirmation → QR рендерится на круглом экране.
- ⚠️ **Важно про QR на production DC:** test creds `APP_ID=4` дают `API_ID_PUBLISHED_FLOOD` при `RequestQrCodeAuthentication` на prod DC. Telegram блокирует QR-логин для всех публично известных API ID. Решение: либо получить свой api_id, либо использовать `useTestDc=true` (тестовая среда — для разработки UI достаточно). Сейчас стоит `useTestDc=true` в [TdLibAuthManager.kt](Разработки/TelegramWatch/wear-app/app/src/main/java/com/example/android/wearable/composestarter/tdlib/TdLibAuthManager.kt).
- 🟡 **#15 частично:** ChatList UI готов в [AuthScreen.kt](Разработки/TelegramWatch/wear-app/app/src/main/java/com/example/android/wearable/composestarter/presentation/AuthScreen.kt), TdLibAuthManager кэширует чаты через UpdateNewChat/Title/LastMessage handlers, StateFlow связан. Не пройден до Ready — нужен либо api_id для prod DC, либо разобраться почему **phone-flow на test DC висит на `setAuthenticationPhoneNumber`** (несколько минут без ответа от Telegram). QR-flow на test DC работает, но скан невозможен (стандартный TG-клиент не подключается к test DC). Phone-flow код пробован с `+9996631234`/code `33333` (DC ID 3) и `+9996636437` — оба зависают.
- 🔑 **api_id ОФИЦИАЛЬНЫЙ БЛОКЕР для продолжения разработки.** Эмпирически (2026-05-20) подтверждено что test creds APP_ID=4 заблокированы Telegram'ом ПОЛНОСТЬЮ на production DC: и QR, и phone-flow с реальным +7-номером возвращают `API_ID_PUBLISHED_FLOOD`. Это не специфика QR — это general ban на публичных test creds. На test DC работает только QR, но обычный TG-клиент к нему не подключается (он на prod DC). Юзер сказал "подумаю позже" про получение api_id.
- Код в [TdLibAuthManager.kt](Разработки/TelegramWatch/wear-app/app/src/main/java/com/example/android/wearable/composestarter/tdlib/TdLibAuthManager.kt) подготовлен к быстрому переключению: установить `USE_PHONE_FLOW=true` + заполнить `PHONE_FOR_LOGIN` (когда будет api_id, поменять `apiId/apiHash` тоже). UI для CodeInput (SMS) и password (2FA) уже готов в AuthScreen.kt. Текущее состояние app — рендерит QR на test DC.

### Tooling, которое уже было использовано
- `brew install cmake php` — для TDLib build scripts (php требует retry из-за openldap SSL fail)
- TDLib build-openssl.sh: ~5-15 min, собирает OpenSSL для 4 ABI
- TDLib build-tdlib.sh: ~30-60 min, ~10k C++ файлов × 4 ABI

### Реалистичный срок
5–8 месяцев на одного разработчика с базовым Android-опытом до полнофункционального MVP (текст + голос + базовые звонки). Stickers/video/stories/secret chats — позже, не критично на старте.

### Galaxy Watch Ultra hardware
- Wear OS 5 (API 34), One UI Watch 6
- Wi-Fi (есть), Bluetooth-tethering к телефону (зависимость), LTE eSIM (опция — нужна для настоящей независимости вне Wi-Fi)
- 47mm круглый экран (~1.5"), AVD profile `wearos_xl_round`

См. [[android-dev-setup-macos-tahoe]] для всех setup-gotchas.
