01
Можно ли обновить Li One обычной флешкой?
Флешка может быть только носителем в сервисном сценарии. Она не заменяет проверку версии, структуру TargetPackage.zip, корректный meta.json, staged-доставку и запуск штатного OTA-обработчика.
OTA-обновление Li One
Li Auto One / Li One
OTA и TargetPackage
NOA внутри main-пакета
актуализировано 03.06.2026
OTA-обновление Li One: как устроена установка прошивки и что проверяет сервис
OTA в Li One — это не «один zip-файл с прошивкой», а управляемый конвейер: облачная мета-информация, проверка текущей версии блока, сборка правильного пакета, staged-доставка, проверка подписей и запуск штатного установщика. Эта статья собрана по последним заметкам из репозитория LiONE и переведена в безопасный для клиента формат.
Главное правило: пакет обновления должен соответствовать текущей VFS-версии блока. Если baseVersion в метаданных не совпадает с реальным состоянием HU, установка может распаковаться и пройти часть проверок, но завершится ошибкой System update failed.
1. Коротко: что подтверждено
OTA-клиент
Системное обновление HU обслуживает com.tsdl.car.ota. Он связан с OEM cloud, локальным UI и Android A/B update_engine.
Пакет
Рабочий контейнер — TargetPackage.zip. В нём есть meta.json и главный inner-zip, имя которого строго берётся из метаданных.
Версия
baseVersion должен совпадать с текущей VFS-версией блока. Нельзя ставить full/delta от другой базы или модели.
NOA
Для delta-сценария NOA может скачиваться отдельно, но в итоговом сервисном пакете он должен лежать внутри main inner-zip.
| Объект | Что делает | Практический вывод |
|---|---|---|
| HU System OTA | Обновляет головное устройство и связанные компоненты через штатный OTA pipeline | Нужна точная мета-информация и корректная структура пакета |
| DOta | Отдельный peripheral-OTA для Modem, ISP, SE | Не путать с системным OTA HU; это другой сервис |
| UDS-доставка | Сервисный канал записи готового пакета в штатный слот установки | Используется в мастерской как контролируемый путь, не как пользовательская инструкция |
| Android A/B | Применяет системный payload с переключением слотов | Снижает риск для системного обновления, но не отменяет проверки совместимости |
2. Архитектура OTA в Li One
Снаружи это выглядит как обычное обновление в меню автомобиля. Внутри участвуют облако, IoT-сервис, системный OTA-клиент, локальное состояние, кэш пакетов, Android update_engine и отдельные обработчики ECU.
Схема. Полный путь OTA-команды
Статья описывает сервисную логику. Низкоуровневые команды, ключи и параметры запуска не публикуются в клиентском интерфейсе.
Почему нельзя просто положить файл: штатный UI смотрит не только на наличие прошивки. Ему нужны согласованные meta.json, состояние OTA-клиента, корректный FSM-контекст и подтверждённая совместимость версии.
3. Формат TargetPackage.zip
Последние проверки уточнили структуру пакета. В сервисном сценарии outer-контейнер содержит meta.json и главный файл
Схема. Два уровня архива и что внутри них лежит
| Элемент | Назначение | Что проверяем |
|---|---|---|
meta.json |
Описание всего обновления: модель, base/target version, список ECU, подписи, digest | Заполненность обязательных полей и совпадение версии базы |
|
Главный архив с HU/ECU-компонентами | Имя байт-в-байт совпадает с метаданными, digest сходится |
| Full-пакет | Содержит полный набор компонентов для указанной базы | Большой размер, самодостаточность, модель и база совпадают |
| Delta-пакет | Содержит только изменившиеся компоненты | Отдельные крупные ECU, например NOA, должны быть корректно добавлены в main |
4. NOA: главный нюанс последней выкладки
В последней версии заметок отдельно зафиксирована ошибка, которая раньше приводила к частичному обновлению: NOA-компонент был добавлен на верхний уровень outer-архива. Для USB-assist/UDS-сценария это неверно. OtaApp сначала извлекает outer-пакет, а затем обрабатывает именно main inner-zip. Поэтому NOA должен быть entry внутри main.
Схема. Неправильное и правильное размещение NOA
Практический вывод для сервиса: перед установкой мы проверяем не только наличие NOA-файла, но и слой архива, точное имя файла из ecuFileInfoList[NOA], размер и digest. Это защищает от ситуации, когда HU обновляется, а NOA остаётся не обновлённым.
5. Состояния OTA и почему важен порядок
OTA-клиент хранит не только данные в базе, но и сериализованное состояние state machine. Поэтому ручная подмена одного признака «готово к обновлению» не является корректным запуском. Рабочий сценарий должен привести OtaApp к согласованному состоянию: пакет, метаданные, кэш, проверки и запуск установки должны соответствовать друг другу.
Схема. Упрощённая state machine штатного OTA
6. Как выглядит сервисный сценарий LiONE
Для клиента это не набор технических команд, а управляемая процедура. Задача сервиса — определить точное состояние блока, подготовить совместимый пакет, провести установку в безопасном окне и проверить результат после перезагрузки.
01
Диагностика блока
Снимаем текущую VFS-версию, модель, состояние HU, доступность питания, свободное место и базовые признаки готовности.
02
Подбор OTA-пакета
Сверяем baseVersion, targetVersion, модель, тип пакета full/delta, список ECU и наличие дополнительных компонентов.
03
Сборка TargetPackage
Формируем meta.json + main inner-zip, добавляем NOA в правильный слой, проверяем размеры и контрольные суммы.
04
Сервисная доставка
Передаём пакет в штатный слот установки через диагностический сервисный канал, не ломая права и структуру Android-разделов.
05
Установка и контроль
Запускаем штатный установщик, ждём завершения, фиксируем видимый результат, проверяем версии и работу функций после перезагрузки.
Схема. Сервисный поток без лишних действий клиента
7. Что обязательно проверяется перед установкой
| Проверка | Зачем нужна | Если пропустить |
|---|---|---|
| Текущая VFS-версия | Подбор правильного baseVersion | Обновление может закончиться System update failed |
| Модель и серия блока | Исключает пакет от другой аппаратной конфигурации | Риск несовместимого ECU-набора |
| Digest и подписи | Подтверждает целостность расшифрованного main-файла и ECU | Установщик остановится на проверке |
| NOA внутри main | Штатный обработчик распознаёт NOA только на правильном уровне | NOA не обновится, даже если часть HU/ECU пройдёт |
| Свободное место и питание | Пакет распаковывается и проверяется до flash-этапа | Риск прерывания на середине процедуры |
| Условия автомобиля | Парковка, EPB, двери, окна, заряд, температура и сетевые условия входят в precondition | OtaService может отказаться от установки |
Что делаем
- Сверяем текущую версию блока перед подбором OTA.
- Используем метаданные пакета как источник истины по именам и digest.
- Проверяем структуру архива до запуска установки.
- Фиксируем результат после перезагрузки и повторно читаем версии.
Что не делаем
- Не ставим пакет от другой базовой версии «на удачу».
- Не публикуем клиенту низкоуровневые команды прошивки.
- Не считаем наличие zip-файла достаточным условием для OTA.
- Не размещаем NOA верхним уровнем рядом с main-пакетом.
8. FAQ
Собрали частые вопросы по OTA в отдельные карточки: вопрос теперь визуально отделён от ответа, а технически важные места вынесены в акцентные блоки.
02
Почему нельзя взять самый свежий пакет и поставить его всем?
OTA-пакет привязан к текущей версии блока. Delta-пакет строится для конкретной пары baseVersion → targetVersion, а full-пакет тоже должен соответствовать модели и исходной базе. Если база не совпадает, штатный установщик останавливает процесс.
03
Чем full-пакет отличается от delta-пакета?
Full-пакет крупнее и содержит полный набор компонентов для заданной базы. Delta-пакет меньше и содержит только изменившиеся части. Поэтому отдельные крупные компоненты, например NOA, требуют дополнительной проверки и правильной укладки внутрь main inner-zip.
04
Что такое NOA и почему вокруг него столько условий?
NOA — отдельный крупный компонент ассистента движения. В delta-сценарии он может не лежать в основном скачанном main-файле. Для сервисного USB/UDS-flow его нужно вложить внутрь main inner-zip с точным именем из метаданных.
05
Что будет, если NOA положить рядом с main-пакетом?
Для актуального сервисного сценария это неверный слой архива. OtaApp сначала извлекает outer-пакет, а затем обрабатывает именно main inner-zip. Top-level NOA может оказаться распакованным не туда, и обновление NOA завершится ошибкой.
06
Почему в статье нет команд запуска прошивки?
Это клиентская статья, а не инструкция для случайного ручного запуска. Низкоуровневые диагностические команды, ключи, адреса и параметры запуска относятся к сервисной зоне. Ошибка в версии, пакете или условиях автомобиля может привести к отказу установки.
07
Нужен ли интернет в автомобиле?
Для штатного облачного OTA интернет нужен для получения метаданных, скачивания пакетов и синхронизации статуса. В сервисном сценарии часть подготовки может выполняться заранее, но состояние блока, версия, пакет и результат всё равно проверяются.
08
Сколько времени занимает обновление?
Точное время зависит от размера пакета, типа full/delta, набора ECU и условий автомобиля. Сервис закладывает отдельное окно на диагностику, подготовку пакета, передачу, проверку, установку, перезагрузку и контроль версий после запуска.
09
Можно ли пользоваться автомобилем во время установки?
Нет. OTA-процедура требует безопасных условий: автомобиль должен быть припаркован, питание и заряд должны быть достаточными, двери и окна — в корректном состоянии, а установка после старта не должна прерываться.
10
Это то же самое, что активации, AppStore или SE?
Нет. OTA HU, AppStore, SE/DOta и активационные работы — разные подсистемы. Они могут пересекаться в диагностике, но обновляются и проверяются по разным правилам.
11
Есть ли откат?
Android A/B снижает риск для системного обновления, но не делает процедуру полностью обратимой для всех ECU и периферийных компонентов. Поэтому перед установкой важны диагностика, корректный пакет и контроль условий автомобиля.
Вывод: безопасное OTA-обновление Li One — это инженерная процедура, а не подбор архива по названию. В LiONE мы проверяем совместимость пакета, структуру TargetPackage, слой NOA, контрольные суммы и состояние автомобиля до запуска установки.