Обновить приложение на одном ТСД можно вручную. Когда ту же работу нужно повторить на остальных терминалах, приходится искать устройства, выяснять версии, менять настройки и проверять результат. После выдачи сотрудникам к этому добавляется помощь на расстоянии: человек сообщает, что «ничего не работает», а администратору ещё предстоит понять, что происходит на экране.
Система управления мобильными устройствами, MDM (Mobile Device Management), позволяет выполнять эти действия из одной консоли, но его возможности зависят от прав Android и связи с каждым устройством.
Разберём на примере MDM Клеверенс весь путь: подготовку ТСД, установку рабочего приложения, подключение базы и помощь сотруднику. По дороге выясним, почему видимый в консоли терминал может не подключаться к складскому серверу и чем отправленная команда отличается от выполненной.
Складская операция и обслуживание терминала
Приложение на ТСД помогает сотруднику принять поставку, подобрать товар или провести инвентаризацию. Но у самого рабочего места есть отдельное состояние: версия приложения, подключение к сети, заряд, разрешения Android и доступные пользователю функции.
Сбой может возникнуть на любом из этих уровней. Сообщение «не получается работать» само по себе не объясняет, недоступен ли сервер, не завершилась ли установка приложения или сотрудник оказался в другом окне.
MDM добавляет средства обслуживания устройства. В MDM Клеверенс администратор работает через веб-консоль, а на Android-ТСД установлен агент. Сервер передаёт команды, агент выполняет доступные действия и возвращает результат. В списке устройств видны полученные сведения о модели, версии MDM, заряде и связи. Для разбора конкретной ситуации есть карточка терминала и история операций.
Это разделяет два вопроса: что сотрудник делает с товаром и в каком состоянии находится его инструмент.
Установка APK и полное управление дают разные возможности
У Android есть собственные правила доступа к устройству. MDM работает в их рамках.
На уже используемый терминал можно установить приложение и предоставить ему пользовательские разрешения. Но часть команд при этом останется недоступной или потребует подтверждения на экране ТСД.
Для полного управления при подготовке нового или сброшенного терминала Android может назначить агент владельцем устройства, Device Owner. Этот режим нужен, например, для тихой установки приложений и системных ограничений. Само скачивание и установка APK такой статус не создают.
Отсюда следует практическое различие между подготовкой новой партии и подключением уже работающего парка. В первом случае режим управления можно заложить в процедуру выдачи. Во втором сначала нужно выяснить, какие полномочия агент действительно получил на каждом устройстве.
Поддержка Android 7.0 и новее также не означает одинаковое поведение всех терминалов. Доступность действий зависит от модели, прошивки, режима управления и разрешений. При получении новой партии стоит сверить прошивку с уже проверенными ТСД. Проверка на одном устройстве подтверждает работу именно этой конфигурации, а не всего парка с похожим названием модели.
Что подготовить до сканирования QR-кода
Для новой партии ТСД работу начинают с профиля. В нём задают нужные настройки, в том числе Wi-Fi, а в мастере добавления устройства выбирают этот профиль и получают QR-код регистрации. На новом или сброшенном терминале код считывает системный сканер первичной настройки Android.
Здесь легко перепутать наличие настроек и возможность ими воспользоваться. В QR может быть указана нужная сеть, но точка доступа должна работать, а ТСД должен видеть её и иметь доступ к адресу MDM. Если сеть недоступна, подготовленный профиль не поможет скачать агент и завершить регистрацию. Сначала проверяют соединение, затем повторяют подключение.
QR-код регистрации предназначен для одного ТСД и действует 10 минут. После успешной регистрации консоль показывает следующий код. Изменение сохранённого профиля не переписывает уже выданный QR: для новой настройки нужно обновить код.
Если системный сканер регистрации не открывается, предусмотрен другой путь: подготовка через USB рядом с Windows-ПК. В консоли скачивают пакет подключения и выполняют USB-инструкцию для устройства. Отсутствие QR-мастера само по себе ещё не означает, что терминал нельзя подключить к MDM.
После регистрации остаются разрешения на самом устройстве. На одной прошивке потребуется подтвердить работу в фоне, на другой добавятся дополнительные действия. Отдельно проверяют специальные возможности для удалённого ввода и доступ к нужным папкам. Поэтому этап подготовки заканчивается проверкой фактического режима управления и доступных действий в карточке ТСД.
Как проверить выполнение команды
В интерфейсе администратор выбирает действие и устройство. Между этим моментом и изменением на ТСД остаются доставка команды, её обработка и ответ агента.
Действие может ожидать связи, требовать участия сотрудника или завершиться ошибкой. Поэтому запись об отправке нельзя использовать как доказательство успешного обновления.
История устройства позволяет восстановить последовательность: действие оператора, доставка, ответ ТСД и итог. Для операции на нескольких устройствах ответы раскрываются отдельно. Успех на одном терминале не подменяет результаты остальных.
Например, если приложение не обновилось из-за ошибки проверки файла, повторная отправка той же команды не объяснит причину. Сначала нужно проверить выбранную версию и файл. История помогает перейти от жалобы сотрудника к конкретному этапу операции.
Каталог приложений и профиль ещё нужно применить
В MDM Клеверенс загрузка приложения в каталог и его установка разделены. В каталоге хранятся версии, а установка запускается отдельным действием для выбранных ТСД. Обновление самого MDM-агента тоже выделено в отдельную операцию.
Аналогично устроены профили. Профиль объединяет поддерживаемые настройки Wi-Fi, звука, яркости, сна, ограничений и рабочего приложения. Сохранение профиля не меняет терминалы: его нужно назначить выбранным устройствам.
Такую механику удобно использовать для проверки изменений на небольшой группе. Теги позволяют выделить тестовую партию, применить настройки или установить приложение, а затем посмотреть ответы устройств. Распространять изменение дальше имеет смысл после проверки результата на реальных ТСД.
У разъездных сотрудников есть ещё одно условие: подходящий момент для обновления. Курьерский ТСД может весь день находиться у водителя. Удалённая установка избавляет от необходимости приносить его администратору, но момент запуска всё равно нужно согласовать с работой сотрудника. Практический порядок здесь простой: дождаться завершения операции, проверить связь, отправить обновление и получить результат. Наличие устройства в сети само по себе не означает, что оно свободно.
Отдельно стоит проверить киоск. Обычный запуск рабочего приложения и системное ограничение выхода из него дают разный результат. Киоск удерживает терминал в рабочем приложении там, где Android предоставляет необходимые права. Успешный запуск приложения сам по себе не доказывает, что ограничения применились.
От установки приложения к подключению базы
Для рабочего места со «Складом 15» установка APK ещё не завершает подготовку. Клиенту нужно подключиться к своей базе Mobile SMARTS. В MDM для этого есть отдельное действие: администратор выбирает установленный клиент и передаёт ему прямой адрес базы.
Дальше ответственность переходит к клиенту на ТСД. Именно он обращается по адресу, проверяет HTTPS-сертификат, проходит авторизацию и загружает базу. MDM к серверу этой базы не подключается. Результат «Ссылка передана приложению» подтверждает передачу адреса, а не успешное соединение.
Это объясняет вполне конкретную ситуацию: ТСД виден в облачном MDM, приложение на него устанавливается, удалённый экран работает, но складская база не открывается. Связь с облаком не даёт устройству доступ к внутреннему адресу сервера в другой сети. Нужно проверить маршрут от ТСД до базы, а не повторять установку APK.
Для этого действия нужен полностью управляемый ТСД, совместимый клиент с поддержкой диплинка и актуальные сведения об установленных приложениях. Даже после передачи адреса могут остаться запросы первого запуска или вход пользователя. Проверка подготовки заканчивается в самом рабочем приложении: нужная база действительно открылась.
Разрешения для просмотра экрана и удалённого ввода
Удалённая помощь полезна, когда описание ошибки по телефону не позволяет понять состояние приложения. Но и здесь возможности разделены.
Для показа экрана требуется системное право Android на захват. Для управления вводом дополнительно нужна подключённая служба MDM в специальных возможностях. Поэтому изображение может быть доступно, а нажатия оставаться недоступными.
Режим Device Owner сам по себе не выдаёт право захвата экрана. На поддержанной прошивке агент может использовать действующее заранее выданное право. В других случаях сотруднику потребуется подтвердить запрос на терминале.
Текущая архитектура удалённого экрана использует MediaProjection и аппаратное кодирование H.264 на Android, передачу через WebSocket и воспроизведение через WebCodecs в браузере. Предусмотрен отдельный JPEG-режим совместимости. Для этого сценария документация не требует инфраструктуры TURN/STUN или подключения по RDP/VNC.
При кратком обрыве связи предусмотрено окно восстановления до 30 секунд. Пока соединение восстанавливается, ввод отключён до появления нового кадра. Так оператор не отправит нажатие, ориентируясь на устаревшее изображение.
Снимок экрана и запись видимого потока сохраняются через браузер оператора. Эти файлы не отправляются на сервер MDM в описанном сценарии записи.
Что проверять, когда «тормозит Wi-Fi»
Медленная установка приложения и зависающий удалённый экран могут выглядеть для сотрудника одинаково. Для администратора полезнее получить измерение с самого ТСД. В MDM есть диагностика связи: быстрая проверка измеряет задержку и долю запросов без ответа, полная дополнительно проверяет скорость приёма и передачи.
Эти показатели относятся к запросам от терминала до MDM, включая обработку сервером. Они не заменяют обследование Wi-Fi-радиоканала и не подтверждают доступность базы Mobile SMARTS. Если MDM отвечает, а база нет, проверять нужно уже другой путь соединения.
У измерения есть время. Старый хороший результат не описывает текущую связь. Если терминал недоступен, команда диагностики ждёт доставки; отсутствие нового замера само по себе не объясняет причину обрыва. Для разбора ошибки приложения рядом с сетевой проверкой нужны журнал и история действий на устройстве.
Где находится сервер и кто устанавливает соединение
MDM Клеверенс поддерживает облачное размещение и локальный Linux-сервер. При локальном размещении обычный обмен с ТСД идёт через сервер организации; облачный MDM не становится обязательным промежуточным узлом.
Браузер администратора и агент на ТСД подключаются к входу MDM по HTTPS/WSS. Команды и ответы проходят внутри установленных соединений. Для обычного управления не требуется отдельное входящее соединение от сервера к терминалу.
За клиентским входом расположены веб-консоль и API. В документации указаны Next.js и React для консоли, ASP.NET Core для API и PostgreSQL для данных. APK и диагностические архивы хранятся отдельно от публичного веб-каталога. Дополнительный локальный шлюз используется в подходящих сетевых схемах и не заменяет сервер управления.
При этом локальная установка не означает автоматически полное отсутствие внешних обращений. В документации отдельно перечислены лицензирование, обновления, телеметрия, почта и источники пакетов. Для конкретного внедрения нужно определить, какие из этих обращений используются и доступны.
Есть и важное ограничение терминологии: HTTPS защищает соединение до доверенного TLS-прокси. Это не обещание сквозного шифрования удалённого экрана, при котором сервер не может видеть содержимое. Подпись команд HMAC-SHA256 также не заменяет шифрование транспортного канала.
Проверять нужно рабочий сценарий целиком
Первое появление ТСД в консоли подтверждает только начало подключения. Для проверки управления нужна более длинная последовательность: получить сведения об устройстве, отправить команду и увидеть её результат, установить приложение, применить профиль и открыть удалённую сессию с нужными разрешениями.
Проводить такую проверку полезно в той сети и на той прошивке, с которыми устройство попадёт к сотруднику. Она показывает не только работоспособность сервера, но и границы полномочий агента, доступность соединений и действия, для которых всё ещё нужен человек рядом с ТСД.
После выдачи терминала администратору нужен проверяемый ответ на простой вопрос: устройство действительно приведено в нужное состояние или мы пока только отправили ему команду. На этой разнице и строится обслуживание рабочего парка.
ссылка на оригинал статьи https://habr.com/ru/articles/1107208/