ADB в Li One
ADB в Li One: почему обычная активация через USB не работает
Ранние проверки показывали, что проблема ADB в Li One связана с USB-role: контроллер 6a00000.ssusb по умолчанию уходит в host, а для ADB нужен режим peripheral/device. Последний reverse-анализ уточнил картину: переключение USB-role действительно работает, но само по себе оно не даёт ADB на фронтальном Type-C.
Текущий вывод: ADB через штатный фронтальный Type-C в Li One нельзя считать рабочим сервисным путём. Есть два независимых блокера: физическая разводка USB через внутренний hub и заглушенный /system/bin/adbd. Поэтому задача больше не формулируется как «включить ADB одной настройкой».
1. Что изменилось после последнего reverse-анализа
В актуальной ветке проекта main данные по USB и ADB сведены в документ docs/reverse-engineering/docs/hu-reverse/usb-topology.md. Он меняет акцент статьи: sys.usb.mode остаётся важной частью диагностики, но уже не является достаточным условием для появления ADB на ПК.
| Раньше предполагали | Сейчас подтверждено | Практический смысл |
|---|---|---|
| ADB есть, но мешает host-режим USB | Host/device переключение есть, но оно не выводит ADB на штатный Type-C | Нельзя обещать клиенту «активацию ADB через кабель» как штатный результат |
| Фронтальный порт может быть подходящим для ADB | Фронтальные USB-A и Type-C висят за внутренним hub на 6a00000.ssusb |
В peripheral-режиме сигнал от контроллера не проходит обратно через hub к разъёму |
adbd запускается и должен обслуживать ADB |
/system/bin/adbd на исследованной прошивке фактически является заглушкой |
Даже при правильной USB-конфигурации некому обслуживать ADB-протокол |
| ADB-флип может повлиять на связь с приборкой/TI | TI-кластер и модем находятся на другом контроллере 7600000.hsusb |
Переключение sys.usb.mode безопасно для связи HU ↔ TI, но ADB всё равно не появляется |
2. USB-топология Li One
На Snapdragon msm8996/S820A в головном устройстве задействованы два USB-контроллера. Они похожи по происхождению, но разведены на разные физические узлы автомобиля.
6a00000.ssusbDual-role контроллер. По умолчанию работает как host, переключается в peripheral через sys.usb.mode=0. К нему привязан внутренний hub, через который идут фронтальные USB-A и Type-C в подлокотнике.
7600000.hsusbHost-only линия, на которой находятся TI-кластер и LTE-модем. Она не переключается обычным sys.usb.mode и не является пользовательским Type-C портом.
Важное уточнение: кнопка USB host/device в DeveloperActivity и тесты VehicleEOL действительно управляют 6a00000.ssusb. Но это управление происходит до внутреннего hub. В device-режиме hub перестаёт быть прозрачным путём до внешнего разъёма.
Схема упрощает физическую разводку: ключевой момент в том, что пользовательский порт не является прямым device-выходом PHY.
3. Два блокера ADB через Type-C
Фронтальные USB-разъёмы подключены через внутренний hub. Когда
6a00000.ssusb переводится в peripheral, hub не становится обратным «проводом» до ПК. На проверках Windows не видел даже события подключения USB-устройства, то есть проблема не в драйвере и не в VID/PID.
В исследованной OR14-прошивке
/system/bin/adbd не содержит полноценной логики ADB-daemon. Состояние init.svc.adbd=running может формально быть правдой, но это не означает, что процесс обслуживает FunctionFS, TCP-порт или ADB-транспорт.
Что теперь считаем некорректным обещанием: «подключим ноутбук к Type-C, включим ADB и получим shell». Для Li One это не подтверждённый сервисный путь. Он ломается и на физическом уровне, и на уровне бинарника adbd.
| Действие | Почему не решает задачу |
|---|---|
persist.sys.usb.config=adb или diag,adb |
Создаёт ожидание gadget-функций, но не исправляет физический hub и не заменяет заглушенный adbd |
service.adb.tcp.port=5555 |
Бесполезно, если нет полноценного daemon, который читает это свойство и поднимает ADB-over-TCP |
Переключение sys.usb.mode=0 |
Контроллер переключается, но внешний Type-C всё равно не получает рабочий device-сигнал |
Патч init / замена adbd |
На штатной системе упирается в AVB/цепочку загрузки и не является обычной клиентской процедурой |
4. Что реально использовать вместо классического ADB
Для сервисной работы с блоком Li One мы больше не считаем USB-ADB основным направлением. Практические сценарии надо строить вокруг доступных сервисных каналов и заранее понимать, какую задачу нужно решить: диагностика, установка ПО, восстановление активации, проверка SE/cloud-auth или работа с OTA.
Заменяет большую часть бытовых задач ADB: диагностика, чтение состояния, файловые и прикладные операции в рамках доступных прав. Это основной безопасный путь для клиентского сервиса.
Подходит для инженерной диагностики загрузки и низкоуровневого анализа. Это стендовая работа с блоком, а не процедура «подключить USB-кабель к машине».
Свежие выкладки по обходу экрана активации относятся к DMS-флагам и агенту. Это отдельная задача восстановления доступа к интерфейсу, а не способ включить ADB.
Новые reverse-данные по eSE, cloud-auth, AppStore и OTA важны для восстановления облачных сервисов и установки ПО, но они не отменяют вывод по USB-ADB.
5. Рекомендованный сервисный порядок работ
Если нужна установка приложения, диагностика логов или восстановление интерфейса, не надо начинать с ADB. Для каждой задачи есть более реалистичный сервисный путь.
Если агент установлен и отвечает, он закрывает большую часть задач, ради которых обычно пытаются получить ADB shell.
Переключение
sys.usb.mode полезно для диагностики топологии, но его нельзя считать доказательством будущего ADB-доступа.
Замена
adbd, правка boot/system и попытки обхода AVB относятся к инженерному стенду и требуют резервных копий, программатора и понятного отката.
Если проблема связана не с ADB, а с облачной авторизацией, AppStore или сервисами Li, нужно диагностировать Secure Element и состояние регистрации блока.
Практический вывод для клиента: услуга должна описываться не как «активация ADB», а как диагностика и сервисный доступ к блоку Li One с подбором рабочего канала: агент, аппаратная диагностика, восстановление активации, SE/cloud-auth или программная установка.
6. Ограничения и корректные ожидания
- ADB через штатный Type-C не подтверждён. Наоборот, текущая reverse-сводка объясняет, почему он не появляется.
- USB host/device toggle не вреден для TI-кластера, потому что кластер находится на другом контроллере, но это не делает toggle рабочим ADB-решением.
- VehicleEOL и DeveloperActivity полезны для диагностики, но не обходят физическую разводку и заглушенный
adbd. - Работа с boot/system/AVB — не клиентская настройка. Это отдельная инженерная процедура с риском bootloop.
- SE/eSE влияет на облачную авторизацию, но не является причиной отсутствия ADB по USB.
7. Какие материалы легли в основу актуализации
Статья обновлена по данным ветки main репозитория LiONE на 03.06.2026. Для публичной версии оставлены только выводы, полезные владельцу и сервису; низкоуровневые эксплуатационные детали намеренно не раскрываются.
| Материал | Что изменил в понимании |
|---|---|
hu-reverse/usb-topology.md |
Доказал два блокера ADB: hub на фронтальном USB и заглушенный adbd |
hu-reverse/README.md |
Зафиксировал USB-топологию как текущий источник истины по HU reverse |
howto_activation_bypass_guest_permission.md |
Разделил тему обхода экрана активации и тему ADB: это разные сервисные задачи |
se-chip-pinout.md |
Уточнил роль eSE в cloud-auth и AppStore, но не в появлении ADB |
appstore-iot-install-reverse-2026-06-02.md |
Показал альтернативные пути установки ПО без классического ADB |
FAQ: частые вопросы по ADB в Li One
Можно ли сейчас включить ADB через обычный USB-кабель?
По текущим данным — нет. Фронтальный Type-C не даёт рабочий путь до device-сигнала, а штатный adbd в исследованной прошивке не является полноценным ADB-daemon.
Значит, старый вывод про sys.usb.mode был неверным?
Не совсем. Переключение sys.usb.mode действительно управляет 6a00000.ssusb. Неверным было ожидание, что этого достаточно для ADB на внешнем Type-C.
Переключение USB-role может сломать связь с приборкой?
Актуальная топология показывает, что TI-кластер находится на другом контроллере 7600000.hsusb. Поэтому сам ADB-флип на 6a00000.ssusb не должен рвать связь HU ↔ TI.
Что тогда использовать для диагностики?
Для большинства задач используется сервисный агент LiONE и профильные сервисные процедуры. Для инженерного стенда возможны аппаратные каналы диагностики, но это отдельная работа с блоком и рисками.
Activation bypass — это замена ADB?
Нет. Обход экрана активации решает другую задачу: вернуть доступ к интерфейсу и локальным DMS-флагам. Он не создаёт ADB-порт на USB.
SE/eSE как-то связано с ADB?
Напрямую нет. eSE важен для cloud-auth, AppStore и некоторых облачных функций. Отсутствие ADB по USB объясняется USB-разводкой и состоянием adbd.
Нужна диагностика блока Li One?
Мы проверяем не «магическую активацию ADB», а реальную задачу: доступ к сервисному агенту, состояние активации, USB-топологию, SE/cloud-auth, установку ПО, логи и восстановление работоспособности блока.
Работы выполняются поэтапно: диагностика → выбор безопасного канала → фиксация состояния → выполнение операции → проверка результата и план отката.