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

В данной статье мы расскажем, с какими особенностями сталкивается разработчик при работе с Авророй. Рассмотрим отличия от популярных мобильных платформ, сложности настройки среды, выбор между Qt и Flutter, ограничения в экосистеме и публикации приложений.

Читать на Дзен
Читать на Workspace

ОС Аврора — российская мобильная операционная система, созданная на базе финской Sailfish OS. Разрабатывается с 2016 года компанией "Открытая мобильная платформа", дочкой Ростелекома.

Цель Авроры — создать защищенную мобильную платформу для государственных учреждений и корпораций. Система получила сертификат ФСБ и включена в реестр российского ПО. В данный момент одними из основных пользователей — Почта России, РЖД, министерства и крупные корпорации.

Техническая основа — Qt Framework с использованием языков QML и C++, что отличается от привычной Android-разработки на Java/Kotlin. Однако экосистема постепенно расширяется: доступна поддержка Flutter, позволяющая использовать Dart
и создавать приложения с единым кодом для Авроры и других платформ. Это особенно актуально для разработчиков, знакомых с Android или кроссплатформенными фреймворками.

В экосистеме уже около 100 приложений, преимущественно корпоративного
и государственного назначения.

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

Архитектурные отличия: Вместо императивного создания UI через код приложения строятся декларативно через QML. Нет привычных Activities и View Controllers — все базируется
на компонентах и их состояниях. Навигация реализуется через StackView и PageStack вместо Intent'ов и segue.

Системные API: Доступ к камере, GPS, уведомлениям происходит через Qt API, которые работают поверх Linux-сервисов. Вместо Android Services используются D-Bus демоны. Разрешения настраиваются через конфигурационные файлы, а не runtime запросы.

Процесс сборки: Отсутствует привычный Gradle или Xcode Build System. Используется qmake или CMake с Qt-специфичными настройками. Сборка происходит в виртуальных машинах, что усложняет CI/CD процессы.

Отладка: Нет аналогов Layout Inspector или Instruments. Отладка UI ведется через текстовые логи QML. Профилирование производительности доступно только через базовые Qt-инструменты.

Управление данными: SQLite работает через Qt SQL модули с другим API.
Нет ORM-решений уровня Room или Core Data. Сетевые запросы реализуются
через QNetworkAccessManager вместо Retrofit или URLSession.

Главное отличие — смена парадигмы с объектно-ориентированной мобильной разработки на компонентно-декларативную desktop-подобную архитектуру в мобильном форм-факторе.

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

Главная проблема — крайне ограниченная экосистема. Готовых библиотек
и компонентов в десятки раз меньше, чем в Android или iOS, поэтому многие решения придется писать с нуля или адаптировать из Qt библиотек.

Документация существенно уступает стандартам Android и iOS. Официальные гайды часто поверхностны, примеры кода устаревают, а детальные технические спецификации недоступны. Разработчикам приходится методом проб и ошибок изучать особенности платформы.

Тестирование на реальных устройствах затруднено. Смартфоны и планшеты на Авроре стоят дорого, их сложно купить в рознице. Эмулятор работает медленнее аналогов
и не всегда корректно воспроизводит поведение реального железа.

Начать разработку под Аврору можно практически бесплатно — все основные инструменты распространяются без лицензионных ограничений. SDK Аврора, Qt Creator и эмулятор доступны для скачивания с официального сайта после простой регистрации.

Минимальные системные требования демократичны: большинство ноутбуков последних 5 лет с 8 ГБ ОЗУ и поддержкой виртуализации подойдут для разработки простых приложений.

Примечания:

• macOS (особенно ARM-чипы) официально не поддерживается;
• Docker используется для сборки, VirtualBox — для запуска эмуляторов;
• Поддержка ALT Linux актуальна, особенно в госорганизациях РФ.

Дополнительные инструменты зависят от специфики проектов. Для работы с государственными системами понадобятся средства криптографической защиты информации — они платные
и требуют сертификации.

Альтернативой локальной разработке становятся облачные решения, которые предлагает ОМП для корпоративных заказчиков. Разработчик получает доступ
к настроенной среде через браузер, но такой подход подходит только для работы
в рамках конкретного проекта.

У разработчика Авроры есть всего два реальных варианта: нативная разработка
на Qt Framework или кроссплатформенная на Flutter.

Qt Framework — единственный полностью поддерживаемый стек для серьезной разработки под Аврору. Все системные приложения, корпоративные решения
и сложные проекты создаются именно на Qt с использованием C++ и QML.

Главные преимущества: полная интеграция с системными возможностями, максимальная производительность, богатая экосистема компонентов Qt. Приложения получаются нативными по ощущениям и оптимально используют ресурсы устройства.

Для мобильных разработчиков платформа представляет значительные трудности. Кривая обучения крутая — C++ и QML кардинально отличаются от Android/iOS подходов. Время разработки увеличивается в 1.5-2 раза по сравнению с привычными мобильными фреймворками. Отладка сложнее, инструменты менее удобные. Частично проблему решает поддержка Flutter — можно использовать привычный фреймворк и портировать готовые приложения.

Flutter для Авроры доступен с августа 2023 года, но это не обычный Flutter
с официального сайта Google. ОМП портировала фреймворк специально под свою платформу, поэтому нужно использовать их версию.

Плюсы для мобильных разработчиков: знакомый Dart, привычная архитектура, возможность переиспользовать код с Android/iOS проектов. Можно быстро портировать существующие Flutter-приложения.

Минусы: доступны не все плагины и библиотеки, некоторые функции работают
по-другому. Производительность ниже нативного Qt. Зависимость от ОМП — новые версии Flutter выходят с задержкой относительно официальных релизов Google.

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

Основная сложность — гибридная природа системы. Аврора базируется на Linux,
но включает Android-совместимый слой, что создает архитектурную путаницу. Разработчик должен понимать, какие функции работают через Qt API, какие через Android-слой, а какие через нативные Linux-сервисы. Это требует более широких знаний,
чем разработка под "чистый" Android или iOS.

Системы управления состоянием работают по-другому. В отличие от Android с его четким жизненным циклом Activity, в Авроре приложения управляются через D-Bus и systemd. Для мобильных разработчиков это неожиданность — нужно изучать desktop Linux подходы для решения мобильных задач.

Ограничения безопасности серьезнее конкурентов. Каждое обращение к системным ресурсам требует явных разрешений, подписи сертификатами, соблюдения политик ФСТЭК. Архитектуру нужно планировать с учетом этих ограничений с самого начала.
Интеграция с корпоративными системами усложнена. Типичная задача — интегрировать мобильное приложение с 1С или другой ERP-системой заказчика. На Android это решается готовыми библиотеками, на Авроре приходится писать адаптеры с нуля
или использовать веб-сервисы.

Одним из ключевых вопросов для разработчика является производительность платформы и скорость разработки. Аврора показывает смешанные результаты
в этих аспектах.

Производительность:

• Qt обеспечивает стабильную работу на слабом железе
• Сложные интерфейсы с анимациями могут тормозить
• Игры и мультимедиа требуют серьезной оптимизации
• Для корпоративных CRUD-приложений производительности достаточно
• Производительность предсказуема, но не выдающаяся

Публикация в Aurora Store кардинально отличается от привычных Google Play
и App Store.

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

Многие заказчики требуют сертификат даже для внутренних корпоративных приложений. Эти расходы нужно закладывать в бюджет проекта с самого начала.

Требования к разработчикам жесткие. Нужно российское юрлицо, аккредитация в реестре разработчиков ПО, соответствие требованиям ИБ. Физлица и иностранные компании фактически исключены из рынка.

Реклама в приложениях практически невозможна — нет аналогов AdMob или Facebook Ads. Российские рекламные сети не интегрированы с Aurora Store.
Модель "бесплатно + реклама" не работает.

In-app покупки реализованы примитивно. Нет подписок, сложных тарифных планов,
A/B тестирования цен. Монетизация возможна только через прямые продажи приложений
или корпоративные лицензии.

Автоматические обновления работают плохо. Пользователи часто остаются
на старых версиях месяцами, что усложняет поддержку. Приходится поддерживать совместимость с 3-4 версиями API одновременно.

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

Продвижение приложений затруднено. В Aurora Store нет аналогов App Store Optimization, рекламных кампаний, featured-размещений. Популярность зависит только от word-of-mouth и прямого маркетинга.

Аналитика пользователей примитивна. Нет детальной статистики использования, воронок конверсии, когортного анализа. Сложно понять, как улучшить продукт
и увеличить retention.

Длительные циклы публикации убивают MVP-подход. Нельзя быстро тестировать гипотезы и итерировать продукт. Приходится тщательно планировать функциональность заранее, что увеличивает риски.

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

Многие разработчики обходят Aurora Store через корпоративные каналы.
Продают лицензии напрямую заказчикам, устанавливают через
enterprise MDM-системы. Это быстрее, но ограничивает масштабирование.

Некоторые используют веб-приложения вместо нативных — не нужна сертификация, быстрые обновления, простая аналитика. Но функциональность ограничена, производительность хуже.

Публикация в Aurora Store подходит только для долгосрочных проектов с большими бюджетами. Стартапы и MVP-продукты экономически нецелесообразны. Если планируете разработку под Аврору, закладывайте публикацию как отдельный этап проекта длительностью 1-2 месяца.

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

При этом у Авроры есть объективные ограничения: сложная архитектура, нестандартные инструменты, ограниченная экосистема, высокая цена входа
и публикации. Разработка требует больше времени, ресурсов и компетенций.
Механизмы распространения и монетизации упрощены, а скорость обновлений невысока.

Push-уведомления в ОС Аврора работают через централизованную систему доставки сообщений, которая обеспечивает надежную доставку уведомлений при минимальном энергопотреблении. Основные ограничения включают лимит на количество уведомлений в час и требования к содержанию сообщений в соответствии с российским законодательством.

Да, использовать Flutter для разработки под ОС Аврора можно, но с определёнными ограничениями. С августа 2023 года компания ОМП (Открытая мобильная платформа) выпустила специально портированную версию Flutter, адаптированную для работы
в среде Авроры. Это не официальный релиз от Google, поэтому использовать стандартный Flutter SDK с сайта flutter.dev нельзя — необходимо устанавливать версию, предоставленную ОМП.

Для получения сертификации приложений, обрабатывающих персональные данные, необходимо пройти дополнительную процедуру проверки соответствия требованиям ФЗ "О персональных данных". Это включает подготовку документации по обработке данных и прохождение аудита безопасности.

Локализация приложений для российской ОС включает не только перевод интерфейса на русский язык, но и адаптацию под российские стандарты форматирования дат, времени, валют и адресов. Также важно учитывать культурные особенности и предпочтения российских пользователей.

Автоматическое тестирование может быть организовано с использованием CI/CD систем, которые интегрируются с SDK Аврора. Это включает юнит-тестирование, интеграционное тестирование и автоматизированное тестирование пользовательского интерфейса с использованием эмуляторов.

Для кроссплатформенной разработки рекомендуется использовать Qt Framework, который поддерживает компиляцию как для ОС Аврора, так и для Android. Также возможно использование общей кодовой базы на C++ с платформо-специфичными интерфейсами.

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

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

Система обновлений приложений в ОС Аврора работает через Aurora Store и поддерживает как автоматические, так и ручные обновления. Разработчики могут настроить различные стратегии обновления, включая поэтапное развертывание и откат к предыдущим версиям.

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