Наша команда разработала и поддерживает корпоративное мобильное приложение по приёму платежей в рамках платёжной системы для крупного заказчика. Теперь оно используется сотрудниками клиента на устройствах под управлением операционной системы Аврора (ранее Sailfish Mobile OS RUS) в тридцати семи российских регионах. В этом посте я коротко расскажу об этом проекте и более подробно – о самой операционке.

Предыстория

Наша компания НОРБИТ разработала платежную систему для одного крупного заказчика. В состав системы входит серверная часть и несколько клиентов: desktop, web и мобильное приложение на операционной системе Android. Первоначально систему внедрили в нескольких регионах Российской Федерации. В 2016 году заказчик решил расширить региональное присутствие, и на данный момент система внедрена и успешно функционирует в 37 регионах.

В 2017 году заказчик решил использовать устройства на отечественном программном обеспечении и приобрел несколько тысяч устройств INOI R7 с операционной системой ОС Аврора (Sailfish Mobile OS RUS). Перед нашей командой поставили задачу создать ещё один мобильный клиент платёжной системы. 

На разработку отводилось всего несколько месяцев. Это был интересный челлендж, так как всю работу пришлось организовывать с нуля. Нам нужно было собрать команду, выстроить процесс разработки, тестирования и регулярного выпуска новых версий. Вкратце расскажу об этих этапах.

Как проходил проект

Для начала необходимо было понять, какими силами все это реализовывать. Нужна была команда, но на рынке готовых специалистов по ОС Аврора просто не было.

Здесь надо отдать должное самой платформе. Разработка под ОС Аврора ведется с использованием фреймворка Qt. Да и для написания простых приложений можно использовать декларативный язык QML, который в большинстве случаев позволяет не прибегать к низкоуровневому программированию на С++. В итоге задача свелась к поиску толковых разработчиков под Qt, коих на рынке в общем-то хватает.

Ок, команда сформирована, надо по функциональности догонять остальных клиентов. Сроки были сжатые – на актуализацию имеющейся функциональности и реализацию новых фич у нас было всего пара месяцев. Ко всему прочему, помимо битвы с бизнес-логикой нас ждала еще битва с самой платформой. Необходимо было решить много вопросов, а готовых ответов на них у нас не было. Со stackoverflow по-быстрому решение не скопируешь, потому как направление новое и мы были одними из первых. Вот только некоторые из них.

Взаимодействие по Bluetooth с ККМ

В проекте требовалась поддержка контрольно-кассовых машин (ККМ) от АТОЛ и «Штрих». Оба производителя ККМ выпускают продукцию с возможностью подключения через Bluetooth.  Примеры работы с Bluetooth можно найти на сайте Qt.

«Штрих» поставляет драйвер для работы с ККМ в виде исходного кода, скачать который можно по ссылке. Там же есть проект-пример использования драйвера.

Драйвер для АТОЛ можно скачать с сайта с ключевыми словами для поиска «Драйверы торгового оборудования». В своём проекте мы использовали восьмую версию драйвера.

В начале проекта были ККМ как с поддержкой 54-ФЗ, так и без. Поэтому  требовалась поддержка четырех типов кассовых аппаратов (АТОЛ/«Штрих» с 54-ФЗ/без 54-ФЗ).

Работа с большими обновлениями базы

Каждое утро сотрудники заказчика обновляют на телефонах справочную информацию о контрагентах. Поскольку контрагентов довольно много (несколько тысяч, в зависимости от региона), на обновление справочников уходило до 1 минуты. Изначально коммиты делались после вставки каждого контрагента. После того, как коммит стали делать после вставки всей справочной информации, время обновления справочников сократилось вдвое (один большой коммит).

Оптимизация сборки приложения

В начале на проекте были допущены «детские ошибки» – включение заголовочных файлов в заголовочные файлы. Переход к forward declaration позволил существенно сократить время сборки проекта. Также много времени на сборку и установку проекта занимает создание rpm-пакета. Если выбрать тип установки «копирование бинарных файлов», повторная сборка, установка и запуск проекта в отладке пройдут за считанные секунды. Также для более быстрой сборки на эмуляторе можно отключить сборку классов для работы с штрих-кодами и кассовым аппаратом. Вариант установки без сборки rpm потенциально опасен тем, что зависимости не будут подтягиваться.

Автоматизированная сборка приложения

Сборку приложения можно организовать без запуска среды разработки. Если собирать из среды разработки, то в консоли сборки можно увидеть запускающиеся команды. Эти же команды можно запустить через bash или batch.

Но несмотря на все трудности, мы выполнили поставленные заказчиком задачи. 31 декабря 2017 года приложение было успешно запущено, и на нем были приняты первые платежи. В данный момент приложение работает на нескольких тысячах мобильных устройств под управлением ОС Аврора. 

ОС Аврора 

А теперь поговорим подробнее об операционной системе и ее особенностях.


ОС Аврора (ранее Sailfish Mobile OS RUS) — это доверенная операционная система для мобильных устройств (смартфонов и планшетов). Ее развивает компания «Открытая мобильная платформа». Система основана на платформе Sailfish OS и предназначена для корпоративных пользователей и государственных корпораций.  

В 2018 году 75% компании «Открытая мобильная платформа» и контрольный пакет финского проекта приобрел «Ростелеком». В то же время был принято решение заменить название Sailfish Mobile OS Rus на операционную систему Аврора. Это лучше подходит для отечественного рынка и, по задумке авторов, соответствует целям продукта, а также вызывает позитивные ассоциации как в России, так и за рубежом.

Слово «доверенная» означает, что у организации, обеспечивающей своих сотрудников устройствами на ОС Аврора, есть полный контроль как над самими устройствами, так и над данными, которые используются ими. Безопасность хранения и передачи данных обеспечивается алгоритмами шифрования в соответствии с ГОСТ и подтверждается сертификатами ФСБ и ФСТЭК.

Для управления мобильными устройствами используется продукт SF Cloud, также разрабатываемый «Открытой мобильной платформой». Это серверное решение, которое может быть развёрнуто на оборудовании организации-заказчика и позволяет через панель администрирования в любое время отслеживать статус мобильных устройств сотрудников, устанавливать, обновлять и удалять приложения на устройствах, управлять обновлениями ОС, блокировать доступ к устройству, безопасно удалять данные (wipe).

Полный цикл разработки ОС Аврора происходит в России. Это позволило ей войти в Единый реестр российских программ для ЭВМ и БД. На данный момент это единственная мобильная ОС с таким статусом, поэтому совместимость с ней является необходимым условием для мобильных приложений из реестра. 

«Под капотом» ОС Аврора находится POSIX-совместимое окружение. То есть это полноценный Linux для мобильных устройств. Например, в отличие от Android, здесь «из коробки» есть systemd, D-Bus, ssh и другие сервисы и утилиты, привычные для «больших» дистрибутивов на ПК. В то же время система включает компонент libhybris, предназначенный для использования драйверов из Bionic-окружения в POSIX-совместимых системах. Это позволяет запускать ОС Аврора на устройствах, изначально спроектированных для Android. В том числе есть официальная поддержка Sony Xperia X и Sony Xperia XA2.

Практически все нужные API обеспечиваются с помощью фреймворка Qt и основанных на нём дополнительных библиотеках, которые используются и для реализации системных приложений и сервисов. Лицензия Qt позволяет писать как открытые приложения, так и проприетарные. Во втором случае существенным требованием является соблюдение правил LGPL, но при использовании библиотек Qt на коммерческой основе и это требование становится необязательным.

Sailfish SDK доступен публично и также ориентирован на работу с Qt. Он включает в себя следующие компоненты.

Qt Creator — IDE, развиваемая проектом Qt и предоставляющая глубокую интеграцию и инструменты для удобной работы с библиотеками Qt. Поддержка Sailfish Mobile OS RUS достигается с помощью плагина, который настраивает соответствующие комплекты сборки для архитектур ARM и x86 и средства управления сборкой и эмуляцией.


Среда сборки — Linux-окружение с набором инструментов и целей, упакованное в виртуальную машину для VirtualBox. Распространение в таком формате позволяет использовать одинаковые средства сборки, независимо от операционной системы разработчика — поддерживаются Linux, Windows и macOS, но и накладывает ряд ограничений. Например, проекты для ОС Аврора требуется размещать в определённых директориях, которые видны виртуальной машине: домашняя директория пользователя или альтернативная директория, указываемая при установке SDK.

Эмулятор — виртуальная машина для VirtualBox, включающая образ Sailfish OS, собранный для x86. По сути, это полноценная сборка операционной системы, позволяющая проверять многие аспекты работы приложений. Но в то же время удобно использовать физические устройства для проверки, например, использования датчиков.

Qt QML Live — инструмент, который позволяет «на лету» изменять графический интерфейс приложения при внесении правок в QML-файлы проекта без необходимости пересборки установочного пакета. Такой подход позволяет существенно ускорить процессы разработки интерфейса пользователя.

Документация — набор справочных статей, охватывающий как описание API, предоставляемых Qt, так и специфичные для ОС Аврора компоненты: например, документацию по Sailfish Silica. Документация доступна и для отдельного прочтения, и в формате контекстной справки, вызываемой для выделенного в редакторе исходного кода элемента.

Чтобы начать разрабатывать приложения для ОС Аврора, можно не только изучать документацию, но и пройти учебные курсы. Есть публичный вводный курс на платформе Stepik, описывающий первые шаги и основные аспекты разработки. Также сотрудникам партнёров компании «Открытая мобильная платформа» можно по запросу на адрес edu@omprussia.ru получить доступ к более полному учебному курсу, включающему, в том числе, уроки по использованию датчиков, навигации, мультимедиа и т. п.

Результатом разработки приложения является установочный rpm-пакет. Перед тем, как он попадёт на устройства сотрудников компании-заказчика, ему предстоит пройти следующие этапы.

1. Подпись валидным сертификатом разработчика. На самом деле, этот этап является составной частью сборки установочного пакета, поскольку подписывается не только сам rpm-файл, но и файлы, входящие в его состав. Наличие позволяет как проверить происхождение установочного пакета, так и целостность его структуры. Чтобы выполнить подпись, требуется получить инструменты генерации ключей и сертификат разработчика, для этого партнёры компании «Открытая мобильная платформа» могут направить соответствующие запросы по адресу dev-support@omprussia.ru.

2. Передача установочного пакета администратору SF Cloud. В зависимости от организации рабочего процесса этот этап может быть реализован по-разному. Важно, что в результате пакет должен оказаться загруженным в репозиторий SF Cloud и быть доступен для распространения на устройства через панель управления. При этом при загрузке в репозиторий происходит не только проверка подписи пакета, но и корректности структуры rpm-файла, на которую налагается ряд требований (обусловлены как стандартизацией путей размещения компонентов приложения, так и требованиями к безопасности). Например:

• в spec-файле, используемом для сборки пакета, не должны использоваться секции %pre, %post, %preun, %postun, %verifyscript;
• в скриптах spec-файла пакета приложения не должны изменяться или удаляться существующие файлы;
• имя исполняемого файла приложения и начало имени пакета приложения совпадают и содержат только строчные буквы, цифры и знаки тире;
• исполняемый файл располагается по пути /usr/bin/{имя проекта};
• desktop-файл располагается по пути /usr/share/applications/{имя_проекта}.desktop;
• иконки располагаются по путям /usr/share/icons/hicolor/{разрешение}/apps/{имя проекта}.png;
• дополнительные файлы, используемые приложением, располагаются в директории /usr/share/{имя проекта}.

Для автоматизации проверки таких требований служит скрипт rpm-validator. Аналогичная проверка доступна в SDK и может быть вызвана из IDE в центре управления Build Engine. Важно уточнить, что настройки скрипта rpm-валидатора могут быть обусловлены целевой платформой и требованиями заказчика. Получить rpm-validator для сертифицированных сборок ОС Аврора можно в «Открытой мобильной платформе» по запросу на адрес dev-support@omprussia.ru.

3. Распространение на устройства сотрудников через панель администрирования SF Cloud. Этот этап, как правило, включает техническое и функциональное тестирование на небольшой группе устройств. При установке rpm-файла на устройства с сертифицированной сборкой ОС Аврора также происходит проверка подписи и структуры. Разработчики могут быть привлечены для исправления возникающих ошибок до загрузки на устройства всех сотрудников.

ОС Аврора остается единственной мобильной операционной системой, соответствующей требованиям ФСБ и ФСТЭК. 

Готовы в комментариях обсудить особенности разработки мобильных приложений на ОС Аврора.

Статья подготовлена при поддержке компании «Открытая Мобильная Платформа»