Требования к установочным пакетам

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

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

Установочные пакеты приложений проверяются на соответствие требованиям как при развёртывании на устройствах, так и при размещении в Платформе управления Аврора Центр. Самостоятельно проверить установочный пакет можно с помощью валидатора RPM-пакетов или диалога в Аврора IDE.

Общие требования
Наименование установочного пакета
Пути файлов
Файл .desktop
Файл .spec
QML
Разделяемые библиотеки
Пользовательские библиотеки
Значок приложения

Общие требования

Файлы, поставляемые установочным пакетом, должны быть размещены в определённых директориях (см. Пути к файлам). В том числе, при установке приложения файлы не должны создаваться в домашней директории пользователя. Про размещение данных, конфигурации и кэша приложения см. Данные пользователя.
Файлы, поставляемые установочным пакетом, не могут иметь права доступа, позволяющие пользователям удалять или модифицировать их (chmod 666 или chmod 777).
В исполняемых файлах запрещено использовать флаги доступа Set User/Group ID Upon Execution (suid/sgid).
Установочный пакет не должен содержать файлы систем управления версиями.
Модули QML не должны импортироваться по абсолютным путям.

Наименование установочного пакета

Установочный пакет следует именовать следующим образом: <название_пакета>-<номер_версии>-<номер_релиза>.<архитектура>.rpm, где:

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

<доменное_имя> используется для идентификации поставщика приложения, а также для устранения коллизий в наименованиях. Рекомендуется, чтобы оно соответствовало имени компании, указанному для сертификата подписи (см. Выпуск сертификата), записанному в обратном порядке. Например, для компании «Открытая мобильная платформа», официальный сайт которой находится по адресу omp.ru, в качестве доменного имени используется ru.omp. Доменное имя должно соответствовать требованиям.
<название_приложения> — уникальное для поставщика название приложения, записанное в формате CamelCase. Например, для приложения My application оно может иметь вид: MyApplication. Название приложения должно соответствовать требованиям.

Название	Описание
`{номер_версии}`	Указывается в ключе `Version` .spec/.yaml-файла. См. Номер версии.
`{номер_релиза}`	Указывается в ключе `Release` .spec/.yaml-файла. См. Номер релиза.
`{архитектура}`	Может быть armv7hl, aarch64, x86_64 или noarch и должна соответствовать архитектуре исполняемых файлов, поставляемых пакетом.

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

Пути файлов

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

Путь	Назначение
/etc/av-launcher/antivirus.desktop	Файл с параметрами для запуска сервиса антивирусного решения (профиль Antivirus)
/etc/connman/	Файлы для конфигурации connman (профиль Extended)
/etc/integrityd/config.d/`<название_пакета>`.json	Настройки Integrityd
/etc/kcapi/qca_aurora_pkcs11/	Директория для хранения конфигурационных файлов для QCA pkcs11 плагинов (профиль Extended)
/opt/extension/p11-kit-modules/	Директория для хранения библиотек для PKCS11 API (профиль Extended)
*/usr/lib/3rdparty/`<название_пакета>`/.so**	Публичные библиотеки (профиль Extended)
/usr/lib/connman/plugins-vpn/`<название_пакета>`/./*	Директория плагинов connman (профиль Extended)
/usr/lib/qt5/qml/	Директория для плагинов (профиль Extended)
/usr/libexec/`<название_пакета>`/*	Дополнительные исполняемые файлы. Название пакета может быть произвольным
/usr/share/`<название_пакета>`/*	Прочие файлы
/usr/share/`<название_пакета>`/lib/*	Разделяемые библиотеки, необходимые приложению
/usr/share/`<название_пакета>`/qml/*	QML-файлы и ресурсы графического интерфейса пользователя
/usr/share/applications/`<название_пакета>`.desktop	Файл .desktop
/usr/share/icons/hicolor/`{размер}`/apps/`<название_пакета>`.png	Файлы значка приложения
/usr/share/sailfish-vpn/`<название_пакета>`./	Директория для плагинов настроек VPN (профиль Extended)
/usr/bin/`<доменное_имя>.<название_приложения>.<название_задачи>`	Исполняемый файл для запуска фоновой задачи. Название задачи может быть произвольным

Не рекомендуется поставлять с установочным пакетом большой объём данных. Директория /usr/share/, как правило, располагается на разделе, предназначенном для хранения корневой файловой системы, основных настроек, библиотек и исполняемых файлов. Отсутствие свободного места на данном разделе может привести к невозможности корректной работы устройства.

В установочном пакете рекомендуется поставлять только скомпилированный код приложения, QML-файлы интерфейса пользователя, файлы значков, файлы переводов и сопутствующие системные файлы. Если приложению требуется большой объём данных, то их рекомендуется загружать из сети при первом запуске приложения или поставлять на съёмном носителе.

Файл .desktop

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

Файл .spec

.spec-файл описывает правила сборки установочного пакета, в том числе: информацию о названии, описании, номере версии и номере релиза.

Требования к spec-файлам описаны в соответствующей статье.

Номер версии

Ключ Version содержит информацию о версии установочного пакета, оформленную по принципам семантического версионирования в формате X.Y или X.Y.Z, где X, Y и Z — целые числа в десятичной системе счисления. Согласно требованиям Аврора Маркета, строка с номером версии должна быть длиной от 1 до 20 символов.

При обновлении приложения в Аврора Маркет номер версии нового пакета должен быть больше номера версии загруженного ранее. Увеличить номер версии можно с сохранением предыдущего формата или с добавлением минорной версии. Например, версии 1.1 и 1.1.0 можно увеличить до версии 1.1.1 или до версии 1.2.0.

Номер релиза

Ключ Release содержит номер релиза и может состоять из цифр, символов точки и подчёркивания.

Зависимости

Ключ Requires указывает зависимости, необходимые для работы ПО. Разрешённые для использования зависимости приведены в разделе Допустимые зависимости приложений ОС Аврора.

Запрещённые секции

Ряд секций недопустимы при сборке приложений для ОС Аврора:

ключи Vendor и Obsoletes;
скрипты %pre, %post, %preun, %postun и %verifyscript — выполнение дополнительных действий с правами суперпользователя не допускается.

QML

Разрешённые для использования общие модули QML приведены в разделе Допустимые зависимости приложений ОС Аврора.

Ресурсы QML, поставляемые установочным пакетом для использования в приложении, должны располагаться в директории /usr/share/<название_пакета>/qml.

Модули QML, поставляемые установочным пакетом для использования в приложении как библиотеки-плагины, должны располагаться в директории /usr/share/<название_пакета>. Они должны иметь название для импорта, начинающееся с префикса название_пакета. Например, для пакета ru.auroraos.QmlPluginUsage импорт может быть организован по имени:

import ru.auroraos.QmlPluginUsage.customqmlplugin 1.0

В spec-файле для QML-модулей определяется макрос __provides_exclude_from. Он должен начинаться с регулярного выражения ^%{_datadir}/%{name} и указывать путь к плагину. Пример:

%define __provides_exclude_from ^%{_datadir}/%{name}/ru/auroraos/QmlPluginUsage/customqmlplugin/.*$

Разделяемые библиотеки

Разрешённые для использования общие разделяемые библиотеки приведены в разделе Допустимые зависимости приложений ОС Аврора.

Разделяемые библиотеки, поставляемые установочным пакетом для использования в приложении, должны располагаться в директории /usr/share/<название_пакета>/lib.

Если приложение не использует библиотеку Libauroraapp, следует убедиться, что в исполняемом файле приложения строка rpath правильно указывает на директорию /usr/share/<название_пакета>/lib. В qmake можно использовать QMAKE_RPATHDIR для установки значения rpath.

Проверить корректность rpath можно в среде сборки.

С помощью команды readelf:

$ readelf -d {путь_к_бинарному_файлу_приложения} | grep RPATH
0x0000000f (RPATH) Library rpath: [/usr/share/<название_пакета>/lib]

С помощью валидатора RPM-пакетов, который выведет значение rpath:

RPATH
=====
OK [rpath in binary seems to be ok: '/usr/share/<название_пакета>/lib']
PASSED

Пользовательские библиотеки

Иногда для разработки может потребоваться включить в проект стороннюю или собственную библиотеку, которой нет в списке разрешённых. Для того, чтобы валидатор пропустил подключаемую библиотеку, требуется явно убрать зависимость RPM-пакета от данной библиотеки. Для этого нужно в .spec-файл добавить макрос:

%define __requires_exclude ^libname.*$

где libname — имя добавляемой библиотеки, записанное в виде регулярного выражения.

Если требуется добавить несколько библиотек, то их требуется перечислить в этом же макросе в виде регулярного выражения:

%define __requires_exclude ^(libname1.*|libname2.*|libname3.*).*$

где libname1, libname2 и libname3 — имена добавляемых библиотек.

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

%define __provides_exclude_from ^%{_datadir}/%{name}/lib/.*$

где %{_datadir}/%{name}/lib/.* — путь к директории с собранными разделяемыми библиотеками (.so-файлами), записанный в виде регулярного выражения. Этот путь является рекомендуемым для хранения разделяемых библиотек.

Подробнее про объявление макросов с помощью директивы %define можно найти на странице описания спецификации .spec-файла.

Пример .spec-файла с подключением сторонней библиотеки из проекта DocumentScanner:

%define __provides_exclude_from ^%{_datadir}/%{name}/lib/.*$
%define __requires_exclude ^libopencv.*$

Name: ru.auroraos.DocumentScanner
Summary: Document Scanner
Version: 0.1.0
Release: 1
License: BSD-3-Clause
Source0: %{name}-%{version}.tar.bz2
BuildRequires: pkgconfig(auroraapp)
BuildRequires: pkgconfig(protobuf)
BuildRequires: pkgconfig(nemonotifications-qt5)
BuildRequires: pkgconfig(Qt5Core)
BuildRequires: pkgconfig(Qt5Qml)
BuildRequires: pkgconfig(Qt5Quick)
BuildRequires: pkgconfig(Qt5Concurrent)
BuildRequires: pkgconfig(Qt5Gui)
BuildRequires: pkgconfig(Qt5OpenGL)
BuildRequires: pkgconfig(Qt5DBus)
BuildRequires: cmake >= 2.6.3
Requires: sailfishsilica-qt5 >= 0.10.9
Requires: nemo-qml-plugin-notifications-qt5

%description
The project provides an example of using video filters to finding documents.

%prep
%autosetup

%build
%qmake5 –r OPENCV_MFLAGS=%{?_smp_mflags}
make %{?_smp_mflags}

%install
%make_install

%files
%defattr(-,root,root,-)
%{_bindir}/%{name}
%defattr(644,root,root,-)
%{_datadir}/%{name}
%{_datadir}/applications/%{name}.desktop
%{_datadir}/icons/hicolor/*/apps/%{name}.png

Значок приложения

Изображения значка приложения должны быть в формате PNG и располагаться по путям, соответствующим размерам:

/usr/share/icons/hicolor/
├── 86x86/apps/<название_пакета>.png
├── 108x108/apps/<название_пакета>.png
├── 128x128/apps/<название_пакета>.png
└── 172x172/apps/<название_пакета>.png

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