Обновить приложение на одном ТСД можно вручную. Когда ту же работу нужно повторить на остальных терминалах, приходится искать устройства, выяснять версии, менять настройки и проверять результат. После выдачи сотрудникам к этому добавляется помощь на расстоянии: человек сообщает, что «ничего не работает», а администратору ещё предстоит понять, что происходит на экране. Система управления мобильными устройствами, 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.
После регистрации остаются разрешения на самом устройстве. На одной прошивке потребуется подтвердить работу в фоне, на другой добавятся дополнительные действия. Удалённый ввод и доступ к файлам зависят от отдельных разрешений. В карточке ТСД администратор видит, какой режим управления получил агент и какие действия ему доступны.
От команды в консоли до ответа ТСД
В интерфейсе администратор выбирает действие и устройство. Между этим моментом и изменением на ТСД остаются доставка команды, её обработка и ответ агента.
Действие может ожидать связи, требовать участия сотрудника или завершиться ошибкой. Поэтому запись об отправке нельзя использовать как доказательство успешного обновления.
История устройства позволяет восстановить последовательность: действие оператора, доставка, ответ ТСД и итог. Для операции на нескольких устройствах ответы раскрываются отдельно. Успех на одном терминале не подменяет результаты остальных.
В журнале Urovo DT50 видны результат установки приложения и замер связи с терминалом.
При обновлении приложения агент может вернуть ошибку проверки файла. По этой записи администратор видит, что команда дошла до ТСД, и может разобраться с конкретной версией APK.
Каталог приложений и профиль ещё нужно применить
В MDM Клеверенс загрузка приложения в каталог и его установка разделены. В каталоге хранятся версии, а установка запускается отдельным действием для выбранных ТСД. Обновление самого MDM-агента тоже выделено в отдельную операцию.
Аналогично устроены профили. Профиль объединяет поддерживаемые настройки Wi-Fi, звука, яркости, сна, ограничений и рабочего приложения. Пока администратор редактирует профиль в консоли, терминалы продолжают работать со своими настройками. Рассылка начинается, когда он назначает профиль устройствам.
Такую механику удобно использовать для проверки изменений на небольшой группе. Теги позволяют выделить тестовую партию, применить настройки или установить приложение, а затем посмотреть ответы устройств. По ответам тестовой группы администратор решает, готово ли обновление для остального парка.
У курьера ТСД может весь день оставаться на связи, пока сам курьер развозит заказы. В консоли администратор видит, что терминал доступен, но по этому статусу нельзя понять, закончил ли водитель работу. Поэтому момент обновления согласуют с водителем. Само обновление администратор отправляет удалённо.
У киоска своя задача. Приложение может успешно открыться, а кнопка выхода на рабочий стол при этом останется доступной. Киоск удерживает терминал в рабочем приложении там, где Android предоставляет необходимые права. Успешный запуск приложения сам по себе не доказывает, что ограничения применились.
От установки приложения к подключению базы
Для рабочего места со «Складом 15» установка APK ещё не завершает подготовку. Клиенту нужно подключиться к своей базе Mobile SMARTS. В MDM для этого есть отдельное действие: администратор выбирает установленный клиент и передаёт ему прямой адрес базы.
Дальше ответственность переходит к клиенту на ТСД. Именно он обращается по адресу, проверяет HTTPS-сертификат, проходит авторизацию и загружает базу. MDM к серверу этой базы не подключается. Результат «Ссылка передана приложению» подтверждает передачу адреса, а не успешное соединение.
Это объясняет вполне конкретную ситуацию: ТСД виден в облачном MDM, приложение на него устанавливается, удалённый экран работает, но складская база не открывается. Связь с облаком не даёт устройству доступ к внутреннему адресу сервера в другой сети. В этом случае причина может быть в маршруте от терминала до сервера базы.
Для этого действия нужен полностью управляемый ТСД, совместимый клиент с поддержкой диплинка и актуальные сведения об установленных приложениях. Даже после передачи адреса могут остаться запросы первого запуска или вход пользователя. Успешное подключение видно уже в самом «Складе 15», когда на терминале открывается нужная база.
Разрешения для просмотра экрана и удалённого ввода
Удалённая помощь полезна, когда описание ошибки по телефону не позволяет понять состояние приложения. Но и здесь возможности разделены.
Для показа экрана требуется системное право 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 Клеверенс поддерживает облачное размещение и локальный Linux-сервер. При локальном размещении обычный обмен с ТСД идёт через сервер организации; облачный MDM не становится обязательным промежуточным узлом.
Браузер администратора и агент на ТСД подключаются к входу MDM по HTTPS/WSS. Команды и ответы проходят внутри установленных соединений. Для обычного управления не требуется отдельное входящее соединение от сервера к терминалу.
За клиентским входом расположены веб-консоль и API. Веб-консоль мы разработали на Next.js и React, API работает на ASP.NET Core, а данные хранятся в PostgreSQL. APK и диагностические архивы хранятся отдельно от публичного веб-каталога. Дополнительный локальный шлюз используется в подходящих сетевых схемах и не заменяет сервер управления.
При локальной установке сетевые доступы зависят от настроек. Например, для онлайн-активации серверу нужен доступ к сервису лицензирования, а для почтовых уведомлений — к SMTP-серверу. Если приложение добавили в каталог по внешней ссылке, APK по этой ссылке скачивает сам ТСД. При настройке сети также учитывают получение обновлений и отправку телеметрии.
Есть и важное ограничение терминологии: HTTPS защищает соединение до доверенного TLS-прокси. Это не обещание сквозного шифрования удалённого экрана, при котором сервер не может видеть содержимое. Подпись команд HMAC-SHA256 также не заменяет шифрование транспортного канала.
Когда ТСД готов к работе
Терминал появился в консоли. Теперь администратору доступна карточка устройства, а впереди ещё установка приложения и применение профиля. После каждой операции агент возвращает свой результат. Если сотруднику понадобится удалённая помощь, возможность открыть экран и управлять вводом по-прежнему будет зависеть от разрешений Android.
На тестовом ТСД в офисе приложение может установиться и сразу открыть базу. На складе тот же APK может остановиться на экране подключения, потому что изменился маршрут до сервера. Поэтому о готовности рабочего места мы судим по тому, что происходит на терминале в сети сотрудника.
Для «Склада 15» таким подтверждением будет открытая рабочая база. Если терминал до неё не дошёл, в истории MDM уже видно, какую часть работы агент успел выполнить.
Источник: habr.com