ОС Аврора 4.0.2 для разработчиков: обзор и примеры исходного кода

Релиз ОС Аврора 4.0.2 — первый сертифицируемый выпуск четвёртого поколения операционной системы, именно он теперь будет использоваться на устройствах в актуальных проектах.

В этой статье мы расскажем о ключевых нововведениях и детально рассмотрим некоторые важные для разработчиков изменения (изоляцию приложений, валидацию и подписание пакетов). На примере приложения «Push Receiver» мы разберём обновлённую регистрацию D-Bus служб и покажем, как адаптировать приложение под ОС Аврора 4.0.2 с фокусом на важные особенности исходного кода приложений для нового поколения операционной системы.

Видеообзор основных нововведений Аврора 4.0

Аврора 4.0.2: ключевые нововведения

Унификация корпоративного и сертифицированного вариантов исполнения ОС Аврора: одно приложение без пересборки

ОС Аврора выпускается в двух вариантах исполнения — корпоративном и сертифицированном. В Авроре третьего поколения приложения, разработанные под корпоративное исполнение, приходилось дополнительно адаптировать под сертифицированное исполнение в другом дистрибутиве SDK. Теперь политики безопасности унифицированы, и все приложения для ОС Аврора 4.0 могут использоваться в проектах с корпоративным и с сертифицированным исполнением.

• Приложения устанавливаются на оба варианта исполнения ОС Аврора без пересборки.

• SDK унифицирован.

• В обоих вариантах исполнения теперь доступны основные механизмы безопасности: подпись пакетов, валидация приложений, подпись модулей ядра, контроль целостности, шифрование пользовательских данных, изоляция приложений.

Переработанные инструменты подписания и валидации

Вместо двух файлов для подписания установочных пакетов и бинарных файлов теперь используется единый сертификат подписи пакета (RPM) и файлов внутри него (IMA). Разработчикам доступны публичные ключевые пары, которые рекомендуется использовать при разработке, а приватные сертификаты нужны только сотрудникам со специальным доступом для подписания релизов.

В Аврора 4.0 валидация пакетов, которая раньше требовалась только для сертифицированного исполнения, стала обязательной для всех приложений.

• Инструменты валидации позволяют проверить, может ли пакет быть установлен на устройстве. Валидатор выполняет простой статический анализ возможных проблем с кодом — успешная проверка означает отсутствие неисправностей в структуре пакета. Проверка кода при валидации не является заменой тестированию, поскольку успешно прошедшее валидацию приложение может работать некорректно. Тем не менее, теперь основные ошибки проверки RPM могут быть найдены и исправлены в процессе разработки до этапа QA.

• Новый валидатор RPM-пакетов поддерживает профили в зависимости от подписи компании-разработчика приложения.

Изоляция приложений (сэндбоксинг)

Начиная с версии 4.0.1, в ОС Аврора реализован механизм безопасного исполнения программ — изоляция (сэндбоксинг). Каждое приложение запускается в «песочнице» — изолированном окружении, которое ограничивает доступ к API и данным. Изоляция минимизирует риск компрометации системы при запуске не заслуживающих доверия или потенциально уязвимых программ.

• Разрешения, необходимые для работы приложения, теперь указываются в desktop-файле, где следует декларировать требуемые функции для доступа к различным типам данных и к отдельным каталогам на устройстве, а также к API, работающим с этими данными или взаимодействующим с другими приложениями или системными сервисами.

Изоляцию приложений мы далее более подробно рассмотрим в примере.

Многопользовательский режим

В ОС Аврора четвёртого поколения реализован многопользовательский режим (одно устройство — до 6 пользователей + администратор). Многопользовательский режим позволяет организовать посменную работу на устройстве с ОС Аврора с новыми настройками рабочего окружения для каждого пользователя. Администратор обладает дополнительными привилегиями, в частности, может управлять аккаунтами других пользователей, настраивать политики безопасности и т. п.

• На экране ввода пароля пользователь выбирает свою учетную запись и получает доступ к своим данным и приложениям. Пользовательские данные в разных учетных записях на одном устройстве полностью независимы друг от друга. Шифрование данных осуществляется прозрачно для приложений: монтирование директории происходит при авторизации пользователя.

• Значения путей к директориям пользователя могут быть получены через специальные API (хардкодить не нужно).

Новый режим разработчика, нововведения в SDK, Platform SDK

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

В Авроре 4.0 переработан подход к активации режима разработчика на устройствах: перепрошивка не требуется, поскольку стала возможна загрузка и установка соответствующих пакетов из репозиториев, благодаря чему администратор может перевести любое устройство в режим разработчика.

• В настройках разработчика стало можно отключать валидацию RPM-пакетов на устройстве, чтобы разработчики могли проверять свои наработки уровня Proof-of-Concept. Важно помнить, что финальное решение должно корректно проходить валидацию, иначе оно не сможет быть установлено на используемые в проектах устройства.

   

  

• «Тихая установка» — долгожданная новая функция режима разработчика. Мы знаем, что раньше разработчиков (как и нас) сильно раздражала необходимость при деплое каждой новой сборки приложения подтверждать её установку на устройство. Рады наконец-то предложить коллегам решение для автоматической установки пакетов из SDK.

В четвёртом поколении Авроры представлен новый продукт Platform SDK — он предназначен для сборки приложений из командной строки и может использоваться для автоматизации процессов выпуска релизов.

Аврора SDK существенно обновлен, чтобы ускорить и сделать более удобной разработку приложений в Аврора IDE.

• В качестве контейнера среды сборки стало можно выбирать не только VirtualBox, но и Docker — зачастую это может существенно ускорить сборку приложений.

• В IDE появились диалоги для валидации и подписи RPM-пакетов, регистрации SSU, а также для управления эмуляцией (последний может имитировать работу датчиков, камеры и изменение геоданных).

Проектирование и разработка UI/UX приложений

Аврора 4.0 качественно расширяет возможности разработчиков по кастомизации внешнего вида и UX приложений. Теперь в их распоряжении есть набор компонентов и подробное руководство по проектированию интерфейсов прикладного ПО для четвертой версии Авроры.

• В UI Kit Аврора 4.0 включены все новые системные компоненты, стили и иконки, описаны и визуализированы жесты, основные свойства и компоненты, приведено подробное руководство по их применению в дизайне и верстке с примерами корректного использования.

• Добавлены API, позволяющие управлять фоном и цветовым оформлением приложений, API для кастомизации полей ввода, единый настраиваемый компонент для работы с кнопками.

• Всплывающие уведомления теперь могут содержать не только строку текста и иконку, но и графику (например, миниатюру изображения, пришедшего в мессенджер). Разработчики могут предложить пользователю несколько действий с уведомлением на выбор, реализовав их отдельными кнопками (например, для входящего сообщения или вызова). Добавлен новый класс уведомлений, позволяющий сообщить о только что выполненном действии (например, об установленном будильнике).

• Разработан API вырезов для управления внешним видом в зависимости от наличия вырезов, строки состояния или скруглений экрана. 

Видеообзор по UI/UX изменениям

Система push-сообщений

Для устройств на ОС Аврора 4 доступна система push-сообщений — коротких уведомлений от сторонних приложений на мобильное устройство, которые доставляются через Интернет или через интранет. Такой тип сообщений позволяет серверам приложений информировать пользователей о важных событиях, даже если приложение не запущено. Соответствующее инфраструктурное решение является частью Аврора Центр.

• Для разработчиков прикладного ПО предусмотрен соответствующий API, работу с которым мы далее более подробно рассмотрим в примере.

Обновлённые браузер и WebView

• В новом релизе стал доступен браузер на 78-й версии движка Gecko, что расширяет возможности использования браузера в информационных системах.

• Совместно с компанией КриптоПро реализована возможность использования электронной подписи в браузере с помощью КриптоПро CSP, что является уникальным решением в мире мобильных технологий.

• Разработчикам доступен новый WebView, использующий унифицированный с браузером стек технологий в отличие от WebView на основе устаревшего WebKit, который использовался в ОС Аврора третьего поколения и позволял отображать только базовый HTML-контент.

Другие изменения в API

В дополнение к описанным выше изменениям в ОС Аврора 4.0 добавились новые API:

• QML-модуль Share для отправки данных приложениям, позволяющий пользователю делиться контентом. В ОС Аврора 3 использовался Nemo Transfer Engine, который не был достаточно безопасным для применения в сторонних приложениях, поэтому не был доступен для сертифицированной версии. Новый модуль Share доступен для всех вариантов ОС Аврора 4.

• D-Bus интерфейс sstore для работы с криптоконтейнерами, позволяющий хранить ключи, пароли и другую конфиденциальную информацию. Свой криптоконтейнер создаётся независимо для каждого приложения и шифруется с помощью пароля, заданного пользователем.

• D-Bus интерфейс Device Info API, предоставляющий сервисную информацию о параметрах устройства. В третьей версии ОС Аврора подобная информация была доступна через различные API, теперь для удобства она собрана в одном месте.

• D-Bus-интерфейс NFCD для работы с NFC-устройствами, позволяющий управлять NFC-адаптером на устройстве, получать и передавать данные по протоколу NFC.

• Служба Integrityd для проверки целостности системы и устанавливаемых компонентов. В ОС Аврора 3 для проверки целостности использовалась AIDE, и в стороннее приложение было невозможно добавить собственный компонент для подобной проверки.

• QML-модуль QrFilter для распознавания и генерации QR и бар-кодов, работающий как видеофильтр со стандартными Qt API.

• Сервис sdjd для сбора и отслеживания событий безопасности, позволяющий получать и фильтровать события безопасности, которые отправляются различными компонентами ОС Аврора: вход в систему, запуск службы проверки integrityd и аналогичные события.

• D-Bus-служба Reports API для генерации зашифрованных отчётов с информацией от различных сервисов и компонентов. По запросу приложения она генерирует отчёт в виде архива.

• Antivirus API для работы с защитным ПО с минимально необходимыми для этого правами и изоляцией от внешнего воздействия. Модуль разработан специально таким образом, что антивирус не становится частью ОС, а является заменяемым модулем, использующим структурированный API.

• D-Bus-интерфейс IUDID для получения постоянного уникального идентификатора устройства. По сравнению с предыдущим API для получения UUID он более безопасен, поскольку не позволяет приложению отслеживать конкретное устройство (ID уникален для связки устройство-пользователь-приложение), но в то же время остаётся постоянным, что полезно, например, для авторизации.

• Библиотека MDM для управления мобильными устройствами. Разработанные с его помощью MDM-приложения позволяют применять ограничительные политики, а также в ручном режиме включать, отключать или вызывать конкретные функциональные возможности устройства.

Разберём нововведения в Аврора 4.0.2 на примере

Чтобы наглядно продемонстрировать ряд важных обновлений, разберём пример приложения «Push Receiver», которое позволяет получать и обрабатывать push-сообщения. Оно регистрируется как обработчик Push и получает идентификатор для внешнего сервиса, генерирующего уведомления. После этого приложение может получать и обрабатывать push-сообщения, в том числе, когда оно не запущено.

Подробнее остановимся на основных изменениях, релевантных для разработки любых приложений (изоляции приложений, валидации и подписании пакетов), а также рассмотрим обновлённую регистрацию D-Bus служб и работу с уведомлениями. Собирать и проверять работу приложения будем в Аврора SDK версии 4.0.2.175 (руководство по установке и базовой настройке доступно на портале разработчиков).

Для начала работы проект нужно склонировать с помощью git

git clone git@gitlab.com:omprussia/examples/PushReceiver.git

или скачать и распаковать в директорию, доступную SDK (домашняя директория пользователя или альтернативная, указанная при установке SDK). Впрочем, можно ознакомиться с кодом и на GitLab по ссылкам, которые мы приведём.

Название RPM-пакета

Начнём с того, что проявляется ещё до погружения в код проекта. В четвёртом поколении ОС Аврора сформулированы требования к наименованию установочных пакетов, которые позволяют идентифицировать поставщика и разграничить пространства имён:

{название_пакета}-{номер_версии}-{номер_релиза}.{архитектура}.rpm

При этом {название_пакета} должно иметь вид {доменное_имя}.{название_приложения}. При создании нового проекта в Аврора IDE название пакета будет сформировано именно таким образом. В случае «Push Receiver» название пакета такое: ru.auroraos.PushReceiver. Оно, как и в предыдущих версиях ОС Аврора, соответствует TARGET, а также используется в названиях некоторых файлов: pro-файл, spec-файл, desktop-файл, файлы иконок и переводов.

Библиотека AuroraApp

Начиная с ОС Аврора версии 4.0.2.175, рекомендуется использовать библиотеку libauroraapp вместо libsailfishapp. Такое изменение проявляется в нескольких местах проекта:

• конфигурация файла проекта

  CONFIG += \    

  auroraapp \

• директива для указания разрешения иконок

  AURORAAPP_ICONS = 86x86 108x108 128x128 172x172

• зависимости сборки

  BuildRequires: pkgconfig(auroraapp)

• подключение заголовочного файла

  #include <auroraapp.h>

• пространство имён Aurora::Application вместо SailfishApp для:

  • получения объекта приложения

    Aurora::Application::application(argc, argv)

  • создания объекта QquickView

    Aurora::Application::createView() 

  • получения путей к файлам, поставляемым приложением

    Aurora::Application::pathTo(QStringLiteral("qml/PushReceiver.qml"))

Кроме того, пространство имён Aurora::Application предоставляет API для получения путей к данным пользователя, в том числе к общим директориям приложений (валидатор теперь проверяет хардкод путей в коде приложения, поэтому нужно использовать API для получения путей в файловой системе).

Новая мета-информация в desktop-файле

Структура desktop-файла приложения расширена:

[Desktop Entry]
Type=Application
X-Nemo-Application-Type=silica-qt5
X-Nemo-Single-Instance=no
X-Aurora-Single-Cover=yes
Icon=ru.auroraos.PushReceiver
Exec=/usr/bin/ru.auroraos.PushReceiver
Name=Push Receiver
Name[ru]=Получение пушей

[X-Application]
Permissions=PushNotifications;Internet
OrganizationName=ru.auroraos
ApplicationName=PushReceiver
ExecDBus=/usr/bin/ru.auroraos.PushReceiver %u

Как видно из листинга, добавлен блок X-Application, позволяющий управлять настройками изолированной среды приложения с помощью новых ключей.

Ключ Permissions содержит список разрешений для приложения, которые описывают используемые API, директории и D-Bus интерфейсы. Приложения должны определять все необходимые разрешения в desktop-файле, при этом все разрешения будут предоставлены в момент первого запуска, если их подтвердит пользователь. «Push Receiver» декларирует разрешения PushNotifications для работы с системной службой push-сообщений и Internet для работы с сетью.

Ключи OrganizationName и ApplicationName содержат название организации и приложения аналогично тому, как это делается для названия установочного пакета. Такая информация из desktop-файла используется для определения собственных директорий приложения и директорий компании-поставщика при формировании изолированного окружения. При этом в ОС Аврора 4.0.1 для корректной работы QStandardPath нужно произвести дополнительную настройку в функции main():

application->setOrganizationName(QStringLiteral("ru.auroraos"));
application->setApplicationName(QStringLiteral("PushReceiver"));

Доменное имя (ru.auroraos) и название приложения (PushReceiver) должны соответствовать именам, которые указаны в desktop-файле. Начиная с ОС Аврора 4.0.2, такая настройка выполняется автоматически.

Ключ ExecDBus описывает команду для запуска приложения через D-Bus. Если он указан, то при установке пакета приложения будет сгенерирован unit-файл для systemd, регистрирующий на сессионной шине D-Bus службу {доменное_имя}.{название_приложения}. Это нужно для обработки обращений к приложению, когда оно не запущено. В случае Push Reveiver служба ru.auroraos.PushReceiver используется для обработки приходящих push-сообщений и реакции на действия пользователя с уведомлениями.

Напомним, что в третьем поколении ОС Аврора unit-файлы для регистрации D-Bus службы требовалось устанавливать самостоятельно. В корпоративном исполнении валидатор не проверял структуру пакета, поэтому unit-файл мог быть установлен непосредственно в каталог /run/user/100000/dbus-1/services/. В сертифицированной версии такая организация процесса была невозможна из-за требований безопасности: запись в системные каталоги запрещена. Поэтому unit-файлы создавались при первом запуске приложения в каталоге настроек sytemd домашней директории пользователя. Механизам регистрации службы D-Bus в ОА Аврора 4 сочетает в себе удобство разработки и безопасность передачи данных.

Также обратим внимание на связку ключей X-Nemo-Single-Instance и X-Aurora-Single-Cover:

X-Nemo-Single-Instance=no
X-Aurora-Single-Cover=yes

Такая связка позволяет запускать несколько экземпляров приложения так, что обложка отображается только для первого экземпляра. Это используется, например, чтобы развернуть уже запущенный экземпляр приложения, когда пользователь запускает новый экземпляр нажатием на иконку.

Кроме того, в ключе Exec теперь должен быть указан полный путь до исполняемого файла. В четвёртом поколении ОС Аврора допускается несколько исполняемых файлов в составе пакета.

Обработка push-сообщений

В четвёртом поколении ОС Аврора стала доступна системная служба, принимающая push-сообщения на устройстве и передающая их приложениям с помощью соответствующего API. Чтобы она смогла правильно адресовать сообщение, приложение должно при первом запуске обработать сигнал Aurora::PushNotifications::Client::registrationId и получить registration ID, который используется для идентификации экземпляра приложения на сервере и отправки push-сообщений конкретному устройству.

connect(m_notificationsClient, &Client::registrationId,
        this,                  &ApplicationController::_setRegistrationId);

Для этого предварительно требуется указать ID приложения, которое соответствует сервису в сети Интернет, и зарегистрировать обработчик.

m_notificationsClient->setApplicationId(applicationId);
m_notificationsClient->registrate();

В приложении «Push Receiver» идентификатор приложения считывается из файла. Для примера мы генерируем файл со значением testApp на этапе сборки:

APP_ID = testApp # write down the application_id here
APP_ID_PATH = /usr/share/$${TARGET}
APP_ID_FILE = applicationid

applicationid_install.extra = echo $${APP_ID} > $${OUT_PWD}/$${APP_ID_FILE}
applicationid_install.files = $${OUT_PWD}/$${APP_ID_FILE}
applicationid_install.path = $${APP_ID_PATH}
applicationid_install.CONFIG = no_check_exist

Когда push-сообщение приходит на устройство, системная служба вызывает через D-Bus метод соответствующее ему приложение. Если приложение не запущено, то выполняется команда запуска, указанная в desktop-файле, с флагом /no-gui, который позволяет отличить такой вызов от запуска по иконке:

if (arguments.indexOf(QStringLiteral("/no-gui")) == -1)
    showGui();

Для отслеживания входящих push-сообщений служит сигнал Aurora::PushNotifications::Client::notifications. В «Push Receiver» заполняется список входящих сообщений:

connect(m_notificationsClient, &Client::notifications,
       [this](const PushList &pushList) {
            for (const auto &push : pushList) {
                m_notificationsModel->insertPush(push);
                …

Кроме того, для каждого push-сообщения генерируется системное уведомление:

Notification notification;
notification.setAppName(tr("Push Receiver"));
notification.setSummary(push.title);
notification.setBody(push.message);
notification.setIsTransient(false);
notification.setItemCount(1);
notification.setHintValue("x-nemo-feedback", "sms_exists");
notification.setRemoteAction(defaultAction);
notification.publish();

Каждое такое уведомление помещается на Экран событий, а также может отображаться всплывашкой. Когда пользователь нажимает на любое из них, происходит обращение к D-Bus службе. В четвёртом поколении ОС Аврора можно указывать текст для кнопок действий, и таких кнопок может быть несколько:

QVariant defaultAction =
    Notification::remoteAction(QStringLiteral("default"), tr("Open app"),
        ApplicationService::notifyDBusService(),
        ApplicationService::notifyDBusPath(),
        ApplicationService::notifyDBusIface(),
        ApplicationService::notifyDBusMethod());

Если приложение было запущено, то отобразится его графический интерфейс, а если не было запущено, то произойдёт запуск на основе ключа ExecDBus из desktop-файла.

Если приложение запущенно в фоне и в течение некоторого времени для него не приходило никаких уведомлений, то оно завершает работу, обрабатывая сигнал, который испускает Aurora::PushNotifications::Client.

connect(m_notificationsClient, &Client::clientInactive, [this]() {
    if (m_view == nullptr)
        qApp->quit();
});

Подписание установочных пакетов

Напомним, что в четвёртом поколении ОС Аврора подписание RPM-пакетов обязательно для всех исполнений ОС: и сертифицированного, и корпоративного. Для примера мы будем использовать публичную ключевую пару профиля regular. Её же стоит использовать на всех этапах разработки приложений, однако для подписания релиза следует выпустить собственный  сертификат.

Для подписания RPM-пакетов теперь используется утилита rpmsign-external:

rpmsign-external sign --key key.pem --cert cert.pem ru.auroraos.PushReceiver-0.1-1.armv7hl.rpm

Также можно это сделать в Аврора IDE с помощью диалога подписи: Инструменты → Аврора ОС → Подпись пакетов.

Однако для разработки вручную подписывать неудобно, поэтому настроим автоматическое подписание при деплое из IDE. Для этого в разделе Проекты → Запуск, раскроем вкладку RPM Sign и укажем пути к файлам ключа и сертификата. Также нужно активировать этот шаг, нажав на иконку Ø .

Тихая установка

Непосредственно за этапом подписания идёт этап развёртывания. Обратим внимание на то, что в нём используется ключ silent, позволяющий запускать приложения в эмуляторе или на устройстве без необходимости подтверждать установку.

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

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

Работа с push-сообщениями из эмулятора

При разработке для тестирования взаимодействия с push-сообщениями на устройствах удобно использовать тестовый сервер и, например, приложение «Push Sender» для отправки сообщений. В актуальной версии Аврора SDK доступна эмуляция отправки push-сообщений. Однако, если запустить «Push Receiver» без дополнительной настройки эмулятора, приложение не сможет связаться с системной службой push-сообщений и получить registration ID.

Чтобы служба push-сообщений стала доступна, нужно создать файл настроек push-сервера в IDE. Для этого генерируем сертификат и ключ:

openssl req -x509 -newkey rsa:4096 -keyout push_key.pem -out push_cert.pem -days 365 -nodes -subj "/C=RU/emailAddress=edu@omp.ru"

Затем запускаем эмулятор, переходим в диалог настроек (Инструменты → Параметры → Push-уведомления → Push-сервер), указываем ключевую пару и нажимаем Создать.

В результате будет создан файл настроек push-сервера, а идентификаторы устройств, доступных для отправки сообщений, отобразятся в списке.

Нажимаем OK, перезапускаем «Push Receiver» и проверяем, что получен registration ID. Для эмулятора он совпадает с ID приложения, но при работе с реальным push-сервером это не так.

Информация о получении registration ID приложением также доступна в основном окне Аврора IDE на вкладке Push Notifications (можно перейти с помощью Alt+9).

Из этой же вкладки можно отправить push-сообщения в приложение. Для этого нужно проверить, что указан идентификатор приложения и выбраны устройства, на которые будут отправляться сообщения.

Затем достаточно ввести текст сообщения и нажать на зелёную стрелку для отправки.

Сообщение об успешно отправленном сообщении будет добавлено в лог.

«Push Receiver», запущенный в эмуляторе, получит сообщение, добавит информацию из него в список и сгенерирует системное уведомление.

Для отправляемых сообщений можно указать дополнительные свойства (Инструменты → Параметры → Push-уведомления → Значения по умолчанию для уведомлений), которые по умолчанию не заполнены.

 Если указать значения, то соответствующая информация будет приходить с push-сообщениями.

Сообщения строковые, но можно, например, сериализовать JSON и передавать более сложные данные. Однако на практике push-сообщения используются, чтобы уведомить приложение о событии, подробности которого оно сможет получить уже подключившись к серверу.

Заключение

Мы описали основные изменения, связанные с разработкой приложений для четвёртого поколения ОС Аврора. В качестве резюме приведём набор действий, которые потребуются для адаптации приложения с предыдущей версии ОС:

• указать в секции X-Application desktop-файла название приложения, домен организации и разрешения для доступа к API и каталогам;

• если приложение предоставляет службу D-Bus, заменить собственный service-файл на механизм ExecDBus;

• если используется ОС Аврора только версии 4.0.2.175 или новее, заменить библиотеку SailfishApp на AuroraApp;

• если используется ОС Аврора до версии 4.0.2.175, задать название приложения и домен организации при настройке экземпляра класса QGuiApplication;

• использовать API для получения путей к данным приложения и подключаемым библиотекам;

• если требуется обрабатывать уведомления сервера, то использовать push-сообщения;

• адаптировать код приложения с учётом изменений в API;

• обеспечить подписание и прохождение валидации установочного пакета.

Кроме того, мы рекомендуем перейти на новые API для решения функциональных задач приложения, и адаптировать внешний вид приложения, ориентируясь на UI Kit.