Всем привет! Меня зовут Илья, и я разработчик ПО в области автоматизации документооборота в компании «Диджитал Дизайн». Так получилось, что изначально я iOS-разработчик, но по воле случая мне удалось поучаствовать в создании мобильного приложения — клиента СДУ «Приоритет» (далее — СЭД, система электронного документооборота) для устройств под управлением мобильной ОС «Аврора». И сейчас, когда первая версия приложения готова, а сам проект находится на этапе внедрения, я бы хотел поделиться полученным опытом и рассказать про особенности разработки под ОС «Аврора» и трудности, с которыми нам пришлось столкнуться в процессе.
Кратко о проекте
Дано:
существующий мобильный клиент СЭД под iOS и его бэкенд (веб-сервис, который выступает в качестве интерфейса для взаимодействия с сервером приложений СЭД);
сжатые сроки (~5 месяцев).
Задача: импортозаместить существующий мобильный клиент СЭД, то есть сделать мобильное приложение со всей функциональностью имеющегося у заказчика решения, которое бы работало на устройствах под управлением ОС «Аврора».
Цель, которую мы преследовали при выполнении задачи — проект нужно писать с ориентацией на кросс-платформенность, т.к. все больше заказчиков начинают проявлять интерес к портированию знакомого мобильного клиента СЭД для iOS на другие платформы (в частности, на ОС Android, а кто-то даже на мобильную Astra Linux).
Из особенностей и возможностей мобильного клиента СЭД можно выделить:
доступ в офлайн-режиме к документам СЭД, назначенным пользователю;
офлайн-просмотр файлов локальных документов самых распространённых форматов: pdf, офисных форматов (doc, docx, xls, xlsx), форматов графических изображений;
внесение текстовых и графических аннотаций на файлы документа, в том числе добавление на файл факсимильного воспроизведения подписи;
подписание файлов документов личным сертификатом электронной подписи по ГОСТ 34.10-2012.
Проведя небольшое исследование технологий для кросс-платформенной разработки мобильных решений, которые бы позволяли реализовать приложение под ОС «Аврора», мы решили остановиться на фреймворке Qt (C++, QML).
С одной стороны, задачу упрощало полное понимание того продукта, который необходимо получить на выходе, а также знакомый бэкенд. С другой же стороны — нам предстояло познакомиться с абсолютно непривычными технологиями и неизведанной платформой.
Средства разработки под ОС «Аврора»
Разработчик операционной системы ОМП («Открытая Мобильная Платформа») предоставляет партнёрам-разработчикам набор средств и компонентов для создания мобильных приложений под ОС «Аврора» — Аврора SDK, в состав которого входят:
Aurora IDE (IDE) — интегрированная среда разработки, основанная на Qt Creator, для написания приложений на языках С, С++ и QML для ОС «Аврора» с использованием компонентов Sailfish Silica. IDE предоставляет продвинутый редактор кода с интеграцией системы контроля версий, управления проектами и сборками;
Aurora OS Emulator (эмулятор) — виртуальная машина, которая позволяет выполнять приложения в окружении ОС «Аврора» аналогично работе на физических мобильных устройствах;
Aurora OS Build Engine (среда сборки) — окружение, которое обеспечивает среду для сборки приложений, не зависящую от домашней операционной системы (ОС).
Также разработчикам предоставляются руководства и примеры приложений для ОС «Аврора» с открытым исходным кодом.
Архитектура проекта
За основу архитектуры взят шаблон программирования MVC (Model-View-Controller), где View — QML-компонент (в частности, Page), Controller — класс С++, который подключается в QML.
Для сохранения данных синхронизации используется SQLite, файл которой хранится в директории локальных файлов приложения. Для создания базы применяется скрипт, формирующий БД при первом запуске приложения или, если БД отсутствует/повреждена.
Для работы с базой используется стандартный класс Qt QSqlDatabase, а для более удобной работы с данными базы реализован Data Access Object (DAO). Из-за отсутствия ORM в Qt внутри классов происходят прямые SQL-запросы к базе данных.
Сам проект для удобства был разделен на модули:
App — интерфейс и жизненный цикл приложения.
Core —логика приложения на C++.
Quazip — код для работы с архивами.
Crypt — работа с криптографией (электронная подпись, ГОСТ-соединение, шифрование) методами криптографического провайдера КриптоПро.
UI
В Aurora SDK входит собственный модуль для разработки интерфейса на QML — Sailfish Silica, который включает в себя все необходимые компоненты.
Однако использование этого модуля накладывает значительные ограничения на применяемые в интерфейсе приложения цвета (шрифты, контролы, фон), которые зависят и регулируются «атмосферами» ОС (то есть такими глобальными темами, установленными на устройстве). Подобные ограничения затрудняли нам возможность сохранения фирменных стилистик пользователей и, самое главное, практически сводили на нет возможность конфигурировать внешний вид приложения для кастомизации под нужды и пожелания заказчиков без необходимости серьезного вмешательства в код.
Другая не менее важная для нас причина невозможности использования готовых UI-элементов, которые предоставляет Aurora SDK, — это привязка к платформе ОС «Аврора», что противоречит нашей цели по реализации кросс-платформенного решения.
Примечание: в проекте все же использовали основной компонент страницы Page для навигации в целях экономии времени, но впоследствии будет написан кастомный аналог.
Для отрисовки UI в самом фреймворке Qt есть два основных модуля с компонентами: Qt Quick Controls и обычный Qt Quick. Qt Quick Controls реализован на базе компонентов из QtQuick и предоставляет набор готовых UI-элементов управления, таких как Button, CheckBox, Label и многие другие. Благодаря ему можно было бы значительно ускорить разработку пользовательского интерфейса. Изначально планировалось брать компоненты из Qt Quick Controls. Но, как оказалось, при их применении приложение не проходит валидацию (в Aurora SDK не разрешено использовать данный модуль).
Обходным вариантом является реализация интерфейса приложения на стандартных компонентах Qt Quick. Это библиотека компонентов, которая предоставляет базовые возможности, такие как якоря (с помощью которых можно позиционировать UI-элементы относительно других элементов на экране), списки, текстовые метки и другое, что позволяет реализовать практически любой UI-элемент. Некоторые компоненты, которые изначально доступны в Qt Quick:
Text — компонент для создания текста;
Rectangle — создание фигуры (любых форм элементов интерфейса);
MouseArea — компонент, с помощью которого можно отслеживать нажатие пользователя;
Image — создание изображения;
ListView — формирование списка;
Item — создание кастомного компонента.
Самое интересное, что удалось сделать на компонентах Qt Quick, — это анимированные выпадающие списки и модальные/диалоговые окна для показа, например, сообщений пользователям.
В процессе разработки была обнаружена одна странность: ширина и высота экрана не вычислялись относительно положения устройства. Компонент Screen выдавал всегда одну и ту же ширину и высоту вне зависимости от ориентации.
В результате у приложения получился интерфейс, который выбивается из стандартного подхода к дизайну, предполагаемого разработчиками ОС «Аврора», но соответствует всем целям, которые мы преследовали в рамках проекта.
Просмотр файлов внутри приложения
Для работы приложения в качестве мобильного клиента СЭД жизненно необходима возможность отображать все самые распространенные форматы файлов (от графических и обычных текстовых до pdf и офисных). Если с изображениями проблем не возникло, то с pdf-файлами и текстовыми/офисными форматами начались трудности.
Для отображения pdf-файлов существует библиотека AmberPDF, разработанная коллегами из ОМП, которая является оберткой над библиотекой PDFium и позволяет использовать ее в Qt. Но помимо отображения, нам было также необходимо реализовать возможность добавлять аннотации на pdf-файлы (перо, выделение, текстовые аннотации и наложение изображения).
Из «коробки» обертка предоставляла возможность использовать только графические аннотации (перо и выделение), а текстовые аннотации и наложение изображений не поддерживались. Поэтому было решено немного дописать AmberPDF в части этого функционала. Но после доработок обнаружилась новая загвоздка — пакет с доработанной библиотекой AmberPDF не проходит валидацию. Для решения этой проблемы потребовалось передать правки по AmberPDF коллегам из ОМП для согласования и включения в репозиторий и, как следствие, локальное внедрение в сборочное окружение подписанных библиотек для успешной валидации приложения.
Правки, которые были внесены в AmberPDF, в будущем должны появиться в составе «Аврора SDK». Это:
добавление графических аннотаций (линии различной ширины);
добавление изображений;
добавление текстовых аннотаций.
Также обнаружилась проблема, из-за которой в pdf-файлах не отображаются шрифты, если они не встроены в сам pdf и отсутствуют в системных шрифтах. Например, большая часть документов использует Times New Roman или Arial, но по умолчанию в системных шрифтах их нет, из-за чего AmberPDF не может отрендерить такой файл. В качестве временного решения недостающие шрифты сейчас вручную добавляются в /usr/share/fonts на устройствах.
Текстовые и офисные форматы
С отображением офисных файлов дела обстоят сложнее. Библиотек или QML-компонентов для отображения нет.
Мы попробовали отображать файл в WebView, но при попытке передать путь файла в качестве URL в WebView открывается диалог выбора каталога для сохранения файла.
Выход из ситуации удалось найти опять же благодаря коллегам из ОМП, которые помогли в разработке компонента-просмотрщика на основе модулей LibreOffice.
Такое решение, однако, принесло некоторые неудобства, т.к. нам пришлось перетащить к себе в код как submodule полную коллекцию модулей LibreOffice (более 3 гигабайт до сборки), из-за чего очень сильно увеличилось время сборки и итоговый размер rpm-пакета приложения. Также после внедрения библиотек LibreOffice собирать приложение стало возможно только вручную через sfdk, а осуществлять отладку только с помощью gdb на физическом устройстве. Это обусловлено тем, что библиотеки LibreOffice собираются в момент сборки самого приложения и команды (configure, make..) находятся в spec-файле, а при такой конфигурации запуск и отладка в IDE становится невозможной.
Во избежание этих сложностей решили собирать библиотеки LibreOffice заранее и копировать их в rpm-пакет, что позволило вернуть время сборки к состоянию, которое было до внедрения библиотек, а также дало возможность сборки и отладки приложения внутри IDE.
Пример того, как собираются и используются библиотеки LibreOffice, можно посмотреть в проекте DocumentConverter, опубликованном в репозитории «ОМП».
Сборка приложения
Сборка в «Аврора SDK» происходит в среде Build Engine, которая представляет из себя либо виртуальную машину, либо Docker-контейнер. Способ выбирается при установке SDK.
По мере увеличения кодовой базы и подключения сторонних модулей в проект время сборки приложения также начало увеличиваться. И в какой-то момент сборка «на холодную» в SDK начала занимать около 15-20 минут.
Для использования в CI/CD системах у ОМП есть компонент Platform SDK, который предоставляет возможность сборки приложений из командной строки с подписанием и валидацией пакета. На удивление, полная сборка нашего проекта со всеми шагами проходит примерно за 4-7 минут.
Проблемы с отладкой
Проблемы начались, когда необходимо было дебажить код. Были моменты, когда при остановке на брейкпоинте остановка происходила вообще в другой части кода, а сам брейкпоинт удалялся. Такое поведение было замечено в IDE, которая установлена на macOS и на Windows. После перехода на Linux Ubuntu подобные проблемы практически не наблюдались.
Вторая сложность — использование эмулятора. Сам эмулятор является виртуальной машиной в VirtualBox, и он очень медленно работает. Данная проблема была замечена по большей части на macOS, если запускать в Linux, то эмулятор работает куда лучше, но все равно не идеально.
Поэтому самым лучшим вариантом, как и везде, остается иметь физическое устройство с ОС «Аврора». Подключение устройства к IDE происходит без проблем, и при подключении через SSH дебаг можно проводить в терминале уже в запущенном приложении с помощью gdb.
Послесловие и благодарности
В заключение хочется отметить, что разработка под ОС «Аврора» в нашем случае, как и любая разработка, сопровождалась трудностями. Но даже с ними, и вопреки всем опасениям, касающимся текущих технологий и самой операционной системы, нам удалось создать приложение, которое соответствует требованиям заказчика и бизнеса в целом.
Верим, что в дальнейшем средства разработки и сама ОС будут только совершенствоваться.
Выражаем свою благодарность коллегам из ООО «ФРУКТ», которые бок о бок с нами участвовали в реализации проекта в крайне сжатые сроки, а также компании «Открытая Мобильная Платформа» за всестороннюю помощь в решении проблем и консультации по многочисленным вопросам, возникавшим в процессе разработки.
Rezzet
Не понимаю почему Qt/QML так мало используют в мобильной и уж тем более в десктопной разработке. Очень удобный фрейморк или СДК, кому как нравится, работает быстро, накладные расходы на кроссплатформенность минимальные, платформенно специфичные баги бывают, но достаточно редко. Я его использую для разработки внутреннего тулинга в геймдеве, причем уже в двух компаниях. Альтернатива электрон, но смотрю на слак и скайп, постоянно то одно то другое бажит и как-то желания даже смотреть его нет. Скайп был вообще мегастабильный до перехода на электрон. Вайбер и Телеграмм на qt сделаны, телеграмм конечно достаточно специфично qt использует )) но то ладно.
По теме топика, какую версию Qt используете?
Rusrst
В Авроре 5.6.х вроде версия. Она старая очень.
А используют реже потому что что сама ide то ещё по сравнению с Android studio гораздо хуже. Сам язык сложнее. Непонятки с QML/C++ что где писать и на что ориентироваться. И ещё куча всего. Ну и сам kotlin гораздо приятнее чем с++
Rezzet
IDE может быть любой, красота Qt в том что вы можете писать программу полностью на десктопе под десктоп, без эмуляторов, симуляторов и прочего, почти 95% кода так можно написать и остается 5% которым потребуется платформенно зависимые штуки, скорее всего это будут пуши, может быть работа с камерой. Нет проблемы разрабатывать на Qt используя андроид студию. В разработке на qt строго говоря вы вообще не привязаны к IDE. Насчет сложности С++ разговоры сильно преувеличены, тут конечно вкусовщина, это мой основной язык разработки на протяжение наверно 20 лет, но у него есть плюс, даже два, он кроссплатформенный, программа написанная на котлин или Swift будет работать только под одной платформой, и если их выбрать как основу, вам нужно иметь две команды которые будут фактически делать два приложения, программа написанная на с++ будет работать везде, конечно же мы говорим про логику, а не взаимодействие с ОС специфичными. "сам kotlin гораздо приятнее" Вы же понимаете что это вкусовщина, язык должен позволять выполнять определенные задачи, грубо говоря реализовывать алгоритм, все Си подобные языки более менее одинаковые (если не нравится си подобный, можно сказать оберон подобные или процедурные или ООП, кому как нравится). В целом что бы решать почти все задачи достаточно функций и структур, остальное это синтаксический сахар, корутины, замыкания, стандартная библиотека и прочее и прочее, это удобные помощники, но не больше.
"Непонятки с QML/C++ что где писать и на что ориентироваться" стоит начать и все сразу станет понятно, с++ это строительные блоки QML это клей который склеивает их между собой. С++ строго типизированный язык, на нем нужно писать 90% кода, в случае если что-то пойдет не так, программа как правило не соберется(имею ввиду не соответствие типов), QML дает свободу в виде отсутствующей типизации, на нем удобно склеивать между собой различные блоки сделанные на с++, но если вы нарушили типизацию узнаете(как в питоне) в момент выполнения программы. QML по большей части декларативный язык, это такой HTML на стероидах, в нем можно писать блоки на JS, но лучше что бы это были простые функции проброса данных в с++ и логику на js лучше вообще не писать. Ну и мегафича Qt/QML это свои виджеты, у вас есть RHI(можно считать что это OpenGL) и делай что хочешь и как хочешь, шейдеры, многопоточный рендер, все сразу, любые капризы, вот тебе gl контекст делай шо хочешь. У нас представление игры в тулинге фактически через один виджет реализовано, просто сделали его оберткой вокруг движка и игры.
Писать мобильные приложения на десктопе без эмуляторов и прочего это кстати очень удобно и значительно быстрее. Просто делаете приложение, оно запускается, отлаживается, все как в любом десктопном приложение, любой профилировщик втягивается, потом шаманите с системой сборки, где МОКи для мобильно специфичных задач подменяются на реальные при сборке и вырезается все что вы прикрутили на десктопе для отладки и профилирования и прочие хелперы. И хлоп на выходе мобильное приложение, причем у себя на машине вообще не собираю его, все делает CI. Я просто пишу приложение как для десктопа, а потом магическим образом получаются ios и android приложения.
Rusrst
Вероятно я менее опытный чем вы, но все же...
Я не видел примеров работы в другой ide отличной от qt creator. Если скинете примеры, буду благодарен.
Так то и kotlin уже мультиплатформенный, ui для ПК уже есть, для iOS в альфе сейчас. И ui декларативный, с кучей примеров где все разжевано, а не как в qt. Тут больше претензии не к самому языку, а к инфраструктуре примеров вокруг, может он и крутой, но примеров очень мало, с Android developer не сравнить.
Ну и то, что все языки одинаковые это все же лукавство, да, делать можно одинаковые вещи, но удобнее на языках более высокого уровня. (У меня есть опыт написания проектов и на с и на kotlin и даже на ассемблер, есть с чем сравнить так сказать). Что касается вкусовщины или нет, по мне работать с coroutines приятнее и удобнее чем с потоками, да плюс асинхронщину в сам язык вроде не так и давно завезли (я про с++). Впрочем сигналы/слоты вроде это все же упрощают. Но я лучше буду на kotlin писать где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны, чем писать монструозную реализацию на с++.
На gl мне сказать нечего, я с ними особо не работал, на Android их полноценно только в 12 версии завезли (agsl)
Ну ладно, нет там магии для Android и iOS. И работы там сделано много, просто она от вас спрятана, так и про flutter можно сказать, он тоже все собирает. И ci сейчас у всех так, Jenkins вроде не сильно сложная штука.
В общем мой основной посыл, что связка qt/C++ менее удобна чем kotlin/as. Хотя я честно пытался разобраться и что-то сделать.
Rezzet
"Если скинете примеры", что скидывать то? есть правила сборки qt приложения, они примерно такое, qml файлы декларируются в qrc файле, дальше при сборке весь контент перечисленный в qrc файле трансформируется в с++ код, прим в исходнике base64 текстом все бинарные фалы идут. Потом компилятор все собирает в бинарные файлы. Данные падают в секцию данных и доступны грубо говоря как глобальные переменные, обертка над ресурсной системой позволяет их доставить типа QFile("qrc://main.qml"), все. Для того что бы собрать проект нужна любая система сборки которая позволяет делать правила компиляции для файлов. Сборка qt/c++ приложения это последовательный вызов определенных утилит, которые делают определенные трансформации над данным и в итоге получается бинарный файл. Для того что бы это все руками не настраивать есть CMake он интегрируется в Gradle, и с помощью него же генерируется xcode проект где уже все настроено. Для того что бы писать на qt достаточно минимальных знаний cmake, после чего вы получите проект для MSVS, XCode, такие среды как CLion и QtCreator могут прямо открывать Cmake файлы и показывать из них проекты. Отладчик QML вы кроме QtCreator больше нигде не получите, но там особо отлаживать нечего, это статическая верстка и очень тривиальный код.
"для iOS в альфе сейчас" В 2012 году уже писал на Qt/QML большой коммерческий проект под Android.
"с coroutines приятнее и удобнее чем с потоками" так используйте они же есть уже в стандарте. Но операционка все равно оперирует потоками и семафорами, хотите быстро и полный контроль тут без шансов, вам нужно манипулировать самым близким уровнем к железу, а это с++.
"где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны" Как выглядит парсинг JSON в с++:
namespace ns {
struct person { std::string name; std::string address; int age; };
}
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
Сложно?
Для с++ сделали пакетный менеджер уже несколько лет, даже несколько есть конан, не использовал, есть vcpkg там 2200 библиотек. Есть такие библиотеки которые невозможно переписать на что-то иное, максимум вокруг с++ написать обертку в нужный язык, boost::graph, opencv, curl, jolt, box2, bullet, openimage, spirv, implot, sqlite3, libtorrent, tesseract, cgal. Каждая из этих библиотек это сотни человеколет работы, мы с вами вместе за всю жизни не напишем даже одну из этих библиотек, даже если всю жизнь будем работать только над этим.
Скорее всего для многих написали обертки в котлин для Qt даже есть обертка в питон. Но зачем нужно ждать пока кто-то сделает и зачем нужна обертка, если все равно основные библиотеки все на с++ написаны, бери исходник, даже WebRTC это с++ в основе, там без шансов быть чему-то иному.
Вы просто попробуйте решить задачу редактора любой игры прям на девайсе. Тут же столкнетесь с кучей проблем, если только у вас движок игры будет не на котлине, а на котлине он врядли будет, просто не потянут не по перфу не по сложности, все это тут же сожрет всю память сегментацией и будут дикие фризы во время сборки мусора, это кое как решили в юнити, и то, вместо фриза на кадр, просадки на несколько кадров. Мощь с++ не в том что он какой-то удобный или в его синтаксическом сахаре, его мощь в библиотеках которые решают любую задачу которые можете придумать и скорее всего они уже лежат на гитхабе и добавлены в vcpkg.
o_f
Хороший комментарий. Странно, что заминусовали
sshmakov
Раскройте мысль, пожалуйста, почему на JS в QML не стоит писать логику, с чем это связано? Сложность отладки?
Rezzet
Все просто, причина та же по которой с++ программисты не понимают зачем код покрывать 100% юнит тестами. Условно код программы можно разделить на:
1) код который выполняет задачу, как правило это какой алгоритм, у него есть входные данные и выходные
2) код который занимается доставкой данных из разных мест и отправкой результата в нужные места программы или обработки различных действий по результатам(показать попап, обновить БД или еще что).
Причем кода второго типа может быть достаточно много, но он простой, ошибиться можно разве что написав метод с ошибкой или имя переменной, нарушить типизацию или еще что, особенно это важно когда происходит какой-то рефакторинг. Так вот правильность имен переменных, правильность типов, совместимость данных большей частью проверит компилятор во время сборки. А JS исполняется строчка за строчкой и программа содержащая ошибку в JS коде запустится, но работать не будет и вы узнаете о ошибке в название метода или переменной во время работы приложения. Контролировать большое количество такого кода становится проблемой. Я не говорю что компилятор это магическая палка выручалка которая защитит вас от всего на свете, но она защитит вас от ошибки в именах методов, классов, функции, от несоответствия типов, а если применять мета программирование(шаблоны) еще много от всего.
И конечно же с++ код легче отлаживать, отладка с++ кода реализована наверно в любом компиляторе и на любой платформе, от программирования микроволновок, до микро сервисов(да на с++ то же можно писать микро сервисы, причем для этого есть очень крутые системы типа CORBA которым 100500 лет). Беда многих молодых программистов в том что они даже если слышали про CORBA открывают ее документацию смотрят минут 15 и закрывают, после чего начинают делать JRPC на с++, сталкиваются с тем что не понимают как быстро написать парсер json после чего идут смотрят на Go, где это пишут чуть ли не во введение и решают писать на нем. Я не против Go, это хороший язык, но неплохо было бы знать какие методы и решения использовались до того как появился Go, возможно там будет что-то более мощное и функциональное. Или еще пример, опять же про тот же json, есть такая библиотека simdjson, у нас получилось на современном компьютере парсить 3Гб json файлов за 150мс на нем. Кто-то может похвастаться таким перфом?
Или boost::graph, я половины этой библиотеки не понимаю, но даже то что понимаю позволяет решить все задачи на графах которые у меня когда либо возникали, причем достаточно компактными 15-20 строчками кода, да это будут очень странные 20 строчек кода, на которые посмотришь и такой, чё???? Но работать будет быстро и лучше ничего нет, вообще. Как и CGAL это наверно самая фундаментальная и комплексная геометрическая библиотека которая существует.
Digital_Design Автор
В данном случае мы использовали версию Qt 5.15.7, т.к. на ней основана Aurora IDE. В дальнейшем будем использовать более новые версии Qt, вероятнее всего 6.5, т.к. планируем выпускать приложение и под Android
SkaarjScout
Версия ide != версии sdk. На авроре версия sdk 5.6.3. Вроде в планах есть перейти на 5.15, про 6ую и речи нет.
Портировал декстоп приложение на Qt 5.15 на аврору. И там плюсовый код не так много надо было адаптировать, в отличие от qml. UI пришлось полностью с 0 писать.
Digital_Design Автор
Мы заранее продумали UI и практически не использовали компоненты из Sailfish Silica (использовали в основном стандартный qt quick). Поэтому адаптировать qml-код практически не нужно будет. Только избавиться от компонентов Page и SilicaListView.
А про версию мы в курсе, в планах для Android не использовать в принципе Аврора SDK, а использовать чистый Qt. Получается, для сборки будут использоваться два разных SDK: для "Авроры" — "Aurora SDK", для Android — "Qt 6 SDK". Пока это только все в планах, так что точно не можем сказать, какие трудности могут возникнуть.