Справочник по метаданным сборки

Информация, используемая fdroid update для составления публичного индекса, поступает из нескольких источников:

Эти файлы метаданных представляют собой простые, легко редактируемые текстовые файлы, которые всегда называются “имя пакета” с добавлением типа файла. Существует широкий спектр доступных полей для добавления информации для описания пакетов и/или приложений. Для всех полей, таких как AuthorName, которые применяются ко всем выпускам пакета/приложения, поля используют CamelCase, начиная с буквы верхнего регистра. Все остальные поля используют camelCase, начиная со строчной буквы, включая поля для каждой сборки, локализованные поля и т.д.

Файлы метаданных записываются в формате YAML

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

fdroid rewritemeta

Или просто запустите его в конкретном приложении:

fdroid rewritemeta org.adaway

В следующих разделах описываются поля, распознанные в файле.

Категории

Любое количество категорий, в которые будет помещено приложение. Фиксированного списка категорий нет - и клиент, и веб-сайт автоматически покажут все категории, которые существуют в любых приложениях. Однако, если ваши метаданные предназначены для основного репозитория F-Droid, вам следует использовать одну из существующих категорий (Связь,Разработка,Игры,Графика,Интернет,Деньги,Мультимедиа,Навигация,Телефон и SMS, Чтение,Наука и образование,Безопасность,Спорт и здоровье,Система,Теминг,Время,Письмо), или обсудить предложение о добавлении новой. Категории должны быть списком элементов, даже если есть только один.

Это конвертируется в (<categories>) в XML файле (index.xml)

AuthorName (Имя автора)

Имя автора: полное, сокращенное или псевдоним. Если он присутствует, он должен представлять имя (имена), опубликованные апстримом, например в файле об авторских правах или об авторах. Его можно опустить (или оставить пустым).

Warning: это переопределяет все AuthorName записи установленные в исходном коде приложения.

Это конвертируется в (<author>) в XML файле (index.xml).

AuthorEmail (Почта автора)

Электронный адрес автора(ов). Его можно опустить (или оставить пустым).

Warning: это переопределяет все AuthorEmail записи установленные в исходном коде приложения.

Это конвертируется в (<email>) в XML файле (index.xml).

AuthorWebSite (Веб-сайт автора)

url веб-сайта автора(ов). Его можно не указывать (или оставить пустым).

Warning: это переопределяет все AuthorWebSite записи установленные в исходном коде приложения.

Лицензия

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

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

Это конвертируется в (<license>) в XML файле (index.xml).

Имя автора

Название приложения, которое лучше всего можно получить из исходного кода. Это делается для того, чтобы fdroid checkupdates мог поместить знакомое имя в описание коммитов, создаваемых при обнаружении нового обновления приложения. Запись AutoName генерируется автоматически при запуске fdroid checkupdates и используется только для сообщений о фиксации, генерируемых fdroid checkupdates.

Имя

Название приложения с необязательной описательной фразой. Это поле переопределяет все другие источники названия приложения, в том числе взятые из APK и из локализованных метаданных. Установка Name обычно не требуется, поскольку правильное имя приложения извлекается из APK-файла. Однако в ситуации, когда APK содержит плохое или отсутствующее имя приложения, его можно переопределить с помощью этого параметра. Обратите внимание, что это только переопределяет имя в списке приложений, представленном в клиенте; оно не изменяет имя или ярлык приложения в исходном коде.

Ограничение в 50 символов

Warning: это переопределяет все Name/title записи установленные в исходном коде приложения.

Это конвертируется в (<name>) в XML файле (index.xml).

Веб-сайт

URL-адрес веб-сайта приложения. Если соответствующего веб-сайта нет, его можно опустить (или оставить пустым).

Это преобразуется в (<web>) в XML-файле (index.xml).

Исходный код

URL для просмотра или получения исходного кода приложения. Это должно быть что-то удобное для человека. Машиночитаемый исходный код рассматривается в поле Repo.

Это преобразуется в (<source>) в XML-файле (index.xml).

IssueTracker (Трекер проблем)

URL-адрес системы отслеживания проблем приложения. Необязательно, поскольку он есть не во всех приложениях.

Это преобразуется в (<tracker>) в XML-файле (index.xml).

Перевод

URL-адрес портала переводов приложения или хотя бы руководства. Необязателен, поскольку не все приложения имеют такой портал.

Это преобразуется в (translation) в JSON-файле (index.json).

Изменения

URL-адрес журнала изменений приложения. Необязателен, поскольку не все приложения имеют такой журнал.

Это преобразуется в (<changelog>) в XML-файле (index.xml).

Пожертвование

URL-адрес для пожертвования на проект. Это должна быть страница пожертвований проекта, если она есть.

Здесь можно использовать прямую ссылку PayPal, если это все, что доступно. Однако имейте в виду, что разработчик может не знать об этой прямой ссылке, и если впоследствии он перейдет на другой счет PayPal или формат ссылки PayPal изменится, все может пойти не так. Всегда лучше использовать ссылку, которую разработчик явно обнародует, а не что-то, что автоматически генерируется “кодом кнопки”.

Это преобразуется в (<donate>) в XML-файле (index.xml).

FlattrID

Flattr (https://flattr.com) ID проекта, если он есть. Это должен быть числовой идентификатор, такой, чтобы (например) https://flattr.com/thing/xxxx вел прямо на страницу для пожертвования проекту.

Это преобразуется в (<flattr>) в XML-файле (index.xml).

Liberapay

Имя пользователя или группы проекта Liberapay (https://liberapay.com), если оно есть. Это должно быть буквенно-цифровое имя, такое как (например) https://liberapay.com/xxxxx, которое перенаправляет на страницу вашего аккаунта. Раньше это был LiberapayID, который представлял собой числовой идентификатор, получаемый с сайта Liberapay путем добавления /public.json за страницей вашей команды.

Это преобразуется в (<liberapay>) в XML-файле (index.xml).

OpenCollective

Имя пользователя или группы проекта OpenCollective (https://opencollective.com), если оно есть. Это должно быть буквенно-цифровое имя, такое, чтобы (например) https://opencollective.com/xxxxx перенаправляло на страницу вашей учетной записи.

Bitcoin

Биткоин-адрес для пожертвования на проект.

Это преобразуется в (<bitcoin>) в XML-файле (index.xml).

Litecoin

Адрес litecoin для пожертвования на проект.

Это преобразуется в (<litecoin>) в XML-файле (index.xml).

Резюме

Краткая информация о приложении. Резюме используется в списке приложений и в плиточных представлениях клиента F-Droid, а также в качестве подзаголовка в некоторых других представлениях.

лимит в 80 символов

Предупреждение: это отменяет все Сводки, а также записи “краткого описания” заданные в исходном коде приложения.

Это преобразуется в (<summary>) в XML-файле (index.xml).

Описание

Полное описание приложения, соответствующее последней версии. Оно может состоять из нескольких строк (не более 80 символов) и завершается строкой, содержащей один символ ‘.’.

Форматирование описания соответствует установленным соглашениям, которые работают во многих магазинах приложений:

  • Можно использовать базовое форматирование HTML.
  • Новые строки будут сохранены.
  • Ссылки на другие пакеты на f-droid.org будут отображаться как кликабельные на сайте, другие ссылки будут отображаться как обычный текст.

Может быть полезно отметить информацию, касающуюся обновления с более ранней версии; содержит ли приложение какие-либо предварительные сборки, созданные предыдущими разработчиками, или были ли удалены несвободные элементы; находится ли приложение в стадии быстрого развития или последняя версия отстает от текущей; поддерживает ли приложение несколько архитектур или указан ли максимальный SDK (такая информация не записывается в индекс).

Ограничение в 4000 символов

Warning: это отменяет все записи Description, также известной как “полное описание” заданные в исходном коде приложения.

Это преобразуется в (<desc>) в XML-файле (index.xml).

Примечания для обслуживающих

Это многострочное поле, использующее те же правила и синтаксис, что и описание. Оно используется для записи заметок для сопровождающих F-Droid, чтобы помочь в поддержании и обновлении приложения в репозитории.

Эта информация также публикуется в вики.

Тип репозитория

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

  • ‘git’
  • ‘svn’
  • ‘git-svn’
  • ‘hg’
  • ‘bzr’
  • ‘srclib’

Репозиторий

Местоположение репозитория. Обычно это, например, URL git: или svn:.

Опция git-svn подключается к SVN-репозиторию, и вы указываете URL точно так же, но в качестве back-end используется git. Это предпочтительнее по соображениям производительности, а также потому, что локальная копия всей истории будет доступна в случае, если вышестоящий репозиторий исчезнет. (Такое случается!). Чтобы использовать теги в качестве UpdateCheckMode для этого типа VCS, URL должен иметь специальный аргумент tags=. Аналогично, если вы собираетесь использовать схему RepoManifest/branch, вы должны указать branches=. Наконец, можно также добавить trunk=. Все эти специальные аргументы будут переданы команде “git svn” по порядку, и их значения должны быть относительными путями к корневому каталогу svn-репо. Вот пример сложного git-svn Repo URL: http://svn.code.sf.net/p/project/code/svn;trunk=trunk;tags=tags;branches=branches

Если RepoType равен srclib, то вы должны указать имя соответствующего srclib .txt файла. Например, если существует scrlibs/FooBar.txt и вы хотите использовать этот srclib, то вы должны установить Repo в FooBar.

Двоичные файлы

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

Если указано, F-Droid будет сверять выходной APK-файл сборки с указанным. Вы можете использовать %v и %c для указания имени версии и кода версии текущей сборки. Для проверки самого клиента F-Droid можно использовать: Binaries: https://f-droid.org/repo/org.fdroid.fdroid_%c.apk

Если проверка прошла успешно, F-Droid будет использовать двоичные файлы из восходящего потока.

Сборки

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

Builds:
  - versionName: '1.2'
    versionCode: 12
    commit: v1.2

  - versionName: '1.3'
    versionCode: 13
    commit: v1.3-fdroid

versionName: xxx

versionCode: yyy

Указывает на сборку версии xxx, которая имеет код версии yyy.

commit: xxx

Параметр commit указывает тег, номер коммита или ревизии на основе которого будет производиться сборка в хранилище исходных текстов.

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

disable: <message>

Отключает эту сборку с указанием причины. (Для обратной совместимости, этого также можно добиться, если начать идентификатор фиксации с ‘!’)

Цель этой функции - позволить релизам, не подлежащим сборке (напр. источник не опубликован) быть помеченными, чтобы скрипты не генерировали повторяющиеся сообщения о них. (А также для записи информации для последующего анализа). Если APK уже был создан, отключение приведет к его удалению после запуска fdroid update; это процедура применяется в случае необходимости замены версии.

subdir: <path>

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

submodules: true

Используется, если проект (только git) имеет подмодули - вызывает git submodule update --init --recursive выполняться после того, как источник клонируется. Подмодули сбрасываются и очищаются, как и основное приложение перед каждой сборкой.

sudo: xxxx

Указывает сценарий, который будет выполняться с помощью sudo bash -x -c "xxxx" в гостевой виртуальной машине buildserver VM. Этот сценарий запускается с полными привилегиями root, но состояние будет сбрасываться после каждой сборки. Подавляющее большинство приложений собираются с использованием стандартной базовой среды Debian/stable. Это полезно для настройки сервера сборки для сложных сборок, которые требуют очень специфические вещи, которые нецелесообразно устанавливать для всей сборки, или для вещей, которые могут конфликтовать с другими сборками.

timeout: <seconds>

Ограничение по времени для этой сборки (в секундах). По истечении времени виртуальная машина buildserver VM будет принудительно завершена. По умолчанию 7200 (2 часа); 0 означает отсутствие ограничения.

Ограничение применяется только в режиме сервера, т.е. когда fdroid build вызывается с опцией --server.

init: xxxx

Подобно “предварительной сборке”, но работает с исходным кодом ДО того, как произойдет любая другая обработка.

Вы можете использовать $$SDK$$$, $$NDK$$$ и $$MVN3$$$, чтобы подставить пути к каталогам android SDK и NDK и исполняемому файлу maven 3 соответственно. Следующие переменные для каждой сборки также доступны: $$$VERSION$$$, $$$VERCODE$$$ и $$$COMMIT$$$.

oldsdkloc: true

Расположение sdk в репозитории имеет старый формат, или build.xml ожидает такого формата. “Новый” формат - sdk.dir, а ОЧЕНЬ СТАРЫЙ формат sdk-location. Обычно, если вы получаете сообщение типа: “com.android.ant.SetupTask cannot be found” при попытке сборки, то попробуйте включить эту опцию.

target: <target>

Определяет конкретную цель SDK для компиляции, переопределяя значение, определенное в коде по восходящему потоку. Это имеет различные эффекты в зависимости от используемой системы сборки - в настоящее время этот флаг влияет на только на проекты Ant, Maven и Gradle. Обратите внимание, что это не изменяет целевой SDK в AndroidManifest.xml, который определяет уровень функций, которые могут быть включены в сборку.

В случае проекта Ant, он изменяет project.properties приложения и, возможно, подпроектов. Это может привести к тому, что весь build.xml будет переписан, что хорошо, если это “стандартный” файл android или он еще не существует, но это не очень хорошая идея, если он сильно кастомизированный.

androidupdate: <auto/dirs>

По умолчанию ‘android update’ используется в сборках Ant для генерации или обновления проекта и всех ссылающихся на него проектов. Указание update=no позволяет обойти это. Обратите внимание, что это бесполезно в сборках, которые не используют Ant.

Значение по умолчанию - ‘auto’, которое рекурсивно использует пути в файле project.properties, чтобы найти все подпроекты для обновления.

В противном случае значение может быть списком директорий, разделенных запятыми в которых нужно запустить ‘android update’ относительно каталога приложения.

encoding: xxxx

Добавляет свойство java.encoding к local.properties с заданным значением. Обычно это значение будет ‘utf-8’. Оно принимается муравьиными правилами SDK и заставляет компилятор Java интерпретировать исходные файлы с этой кодировкой. Если вы получаете предупреждения во время компиляции о кодировках символов, вам, вероятно, нужно это значение.

forceversion: true

Если указано, версия пакета в AndroidManifest.xml заменяется на имя версии сборки, указанное в метаданных.

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

forcevercode: true

Если указано, код версии пакета в AndroidManifest.xml будет заменяется на код версии сборки. См. также forceversion.

rm: <path1>[,<path2>,...]

Указывает относительные пути к файлам или каталогам, которые необходимо удалить перед завершением сборки. Пути являются относительными по отношению к основанию каталога сборки - т.е. корня структуры каталогов, проверенных из репозитория исходных текстов - не обязательно каталог, который содержит AndroidManifest.xml.

Можно указать несколько файлов/каталогов, разделяя их символом ‘,’. Каталоги будут удаляться рекурсивно.

extlibs: <lib1>[,<lib2>,...]

Список внешних библиотек (jar-файлов), разделенных запятыми, из библиотеки build/extlib, которые будут помещены в каталог libs проекта.

srclibs: [n:]a@r,[n:]b@r1,...

Список исходных библиотек или проектов Android, разделенный запятыми. Каждый элемент имеет вид name@rev, где name - это предопределенное имя исходного кода имя библиотеки, а rev - ревизия или тег для использования в соответствующем контроле исходного кода.

Для проектов Ant вы можете по желанию добавить номер с двоеточием в в начале элемента srclib, чтобы автоматически поместить его в project.properties как библиотеку под указанным номером. Для примера, если вы укажете 1:somelib@1.0, F-Droid автоматически сделает эквивалент унаследованной практики prebuild=echo "android.library.reference.1=$$somelib$$" >> project.properties.

Каждый srclib имеет файл метаданных в каталоге srclibs/ в директории репозитория, а исходный код хранится в build/srclib/. RepoType и Repo указываются таким же образом как для apps; Subdir: может быть списком, разделенным запятыми, для случаев, когда каталоги переименовываются восходящим потоком; Update Project: обновляет проекты в рабочем каталоге и на один уровень ниже; Prepare: может использоваться для любого вида подготовки: в частности, если вам нужно обновить проект с определенной целью. В этом случае вы также можете использовать $$$name$$ в команде init/prebuild/build для замены относительного пути к каталогу библиотеки, но это может потребовать корректировки, если вы перешли в другую директорию.

В настоящее время srclibs необходимы, когда апрстрим (upstream) использует jar-файлы или берет зависимости из ненадежных хранилищ. Хотя нет никакой гарантии, что эти двоичные файлы свободны и соответствуют исходному коду, F-Droid разрешает использовать следующие известные репозитории до тех пор. пока не будет доступна альтернатива с исходным кодом:

  • ‘mavenCentral’ - исходный репозиторий, жестко закодированный в Maven и Gradle.
  • ‘jCenter’ - жестко закодирован в Gradle, этот репозиторий от Bintray пытается обеспечить более простую работу с ним. Он должен синхронизироваться с mavenCentral время от времени.
  • ‘OSS Sonatype’ - поддерживаемый людьми, стоящими за mavenCentral, этот репозиторий фокусируется на услугах хостинга для двоичных файлов проектов с открытым исходным кодом.
  • ‘OSS JFrog’ - поддерживаемый людьми, стоящими за jCenter, этот репозиторий фокусируется на услугах хостинга для двоичных файлов проектов с открытым исходным кодом.
  • ‘JitPack.io’ - сборка непосредственно из репозиториев GitHub. Однако они не предоставляют никакой возможности воспроизвести или проверить полученные двоичные файлы. В некоторых случаях собирает предварительные версии.
  • ‘Clojars’ - репозиторий библиотек Clojure.
  • ‘CommonsWare’ - репозиторий, содержащий коллекцию библиотек с открытым исходным кодом.
patch: x

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

prebuild: xxxx

Указывает команду оболочки (или команды - цепочка с &&) для выполнения перед началом сборки. Обратная косая черта может быть использована в качестве управляющего для вставки литеральных запятых, или как последний символ, чтобы соединить эту строку со следующей. Он не имеет специального значения в других контекстах; в частности, буквальные обратные косые черты не должны экранироваться.

Команда выполняется с помощью bash.

Обратите внимание, что на этом этапе предварительной сборки ничего не должно быть собрано - сканирование кода и сборка исходного тарбала, например, происходят после этого. Для пользовательских действий, которые фактически сборки или создания двоичных файлов, используйте ‘build’ вместо этого.

Вы можете использовать $$$name$$ для подстановки пути к ссылаемому файлу. srclib - подробности см. в каталоге srclib.

Вы можете использовать $$SDK$$$, $$NDK$$$ и $$MVN3$$$ для замены пути к каталогам android SDK и NDK, и Maven 3 исполняемого файла соответственно, например, для случая, когда вам нужно запустить android update project в явном виде. Следующие переменные для каждой сборки также доступны: $$$VERSION$$$, $$$VERCODE$$$ и $$$COMMIT$$$.

scanignore: <path1>[,<path2>,...]

Позволяет исключить один или несколько файлов/путей из процесса сканирования. Этот параметр следует использовать только при наличии очень веских причин, и, возможно, сопровождается комментарием, объясняющим почему это необходимо.

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

scandelete: <path1>[,<path2>,...]

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

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

build: xxxx

Как и в случае с ‘prebuild’, но запускается во время фактической фазы сборки (но перед основной сборкой Ant/Maven). Используйте это только для действий, которые выполняют фактическую сборку. Любая подготовка исходного кода должна быть выполнена с помощью ‘init’ или ‘prebuild’.

Любая сборка, выполненная до build, будет проигнорирована, так как либо Ant, mvn или gradle будут выполнены для очистки среды сборки непосредственно перед запуском build (или финальной сборки).

Вы можете использовать $$SDK$$$, $$NDK$$$ и $$MVN3$$$ для замены пути к каталогам android SDK и NDK, и maven 3 соответственно. Следующие переменные для каждой сборки доступны аналогичным образом: $$$VERSION$$$, $$$VERCODE$$$ и $$$COMMIT$$$.

buildjni: [yes|no|<dir list>]

Позволяет собирать нативный код с помощью сценария ndk-build до того, как выполнится основная сборка Ant. Значение может представлять собой список каталогов относительно основного каталога приложения, в котором следует запустить ndk-build, или ‘yes’, что соответствует ‘.’. Использование явного списка может быть полезно для сборки многокомпонентных проектов.

Процессы сборки и сканирования выдадут ошибку (отказ в сборке), если этот параметр не определен, но присутствует каталог jni. Если нативный код собирается другим способом, например, с помощью задачи Gradle, вы можете указать no здесь, чтобы избежать этого. Однако, если нативный код на самом деле не требуется или не используется, удалите каталог вместо этого (например, с помощью rm=jni). Использование buildjni=no, когда код jni не используется и не собирается, приведет к ошибке, говорящей о том, что ожидаются родные библиотеки в результирующем пакете.

ndk: <version>

Version of the NDK to use in this build. The value is the NDK version as a string in either of the two official version schemes, e.g. r21e or 21.4.7075529. NDK r10e or later is supported. This can also be a list of version strings, and all listed versions will be installed. The ANDROID_SDK_ROOT environment variable will be set to the first version in the list.

gradle: <flavour1>[,<flavour2>,...]

Сборка с помощью Gradle вместо Ant, указав, какие вкусы использовать. Вкусы чувствительны к регистру, поскольку путь к выходному APK является также.

Если указан только один аромат и он имеет значение ‘yes’, то аромат не будет использоваться. Обратите внимание, что для проектов со вкусами, вы должны указать хотя бы хотя бы один правильный вкус, так как при значении ‘yes’ будут собраны все по отдельности.

maven: yes[@<dir>]

Сборка с помощью Maven вместо Ant. Дополнительный @<dir> указывает F-Droid запустить Maven внутри этого относительного подкаталога. Иногда необходимо использовать @…, чтобы сборка происходила правильно.

preassemble: <task1>[,<task2>,...]

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

gradleprops: <prop1>[,<prop2>,...]

Список свойств Gradle для передачи через командную строку в Gradle. Может иметь форму foo или форму key=value.

Например: gradleprops=enableFoo,someSetting=bar приведет к тому, что gradle -PenableFoo -PsomeSetting=bar.

antcommands: <target1>[,<target2>,...]

Укажите альтернативный набор команд Ant (целевой) вместо стандартного ‘release’. Ему не могут быть заданы никакие флаги, например, путь к build.xml.

output: glob/to/output.apk

Укажите глобальный путь, где должен находиться результирующий неподписанный релиз APK из сборки. Это можно использовать в сочетании с такими методами сборки как gradle=yes или maven=yes, но если метод сборки не указан, сборка будет ручной. Вам следует запустить свои команды сборки, такие как make, в build.

novcheck: true

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

antifeatures: <antifeature1>[,<antifeature2>,...]

Список анти-функций для данного конкретного билда. Они описаны в AntiFeatures.

AllowedAPKSigningKeys

When making automated binary repositories with fdroid update, it is generally easy to find out the expected signing key for the APKs that are gathered. AllowedAPKSigningKeys lets the repo operator set the expected signing keys, then fdroid update will check that the APKs are signed by one of those keys. If not, the mismatched APKs will not be included in the repo. If fdroid update --delete-unknown is specified, the mismatched APKs will be deleted. Then an automated process can be used to download newer APKs to the repo, and they will only be included if they have a known good signature. The value is a lowercase hex value of the SHA-256 fingerprint of the signing certificate. This can be fetched using:

apksigner verify --print-certs example.apk | grep SHA-256

Анти-особенности

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

  • ‘Ads’ - приложение содержит рекламу.
  • ‘Отслеживание’ - данные о пользователе или действиях отслеживаются или утекают по умолчанию. Верно, если приложение или функция не могут быть использованы без сбора и передачи таких данных или выполнения запросов к сетевому сервису сбора данных (независимо от того, основан ли сервис на свободном программном обеспечении или нет). Например, основанная на активности загрузка данных о погоде, карт, аватаров и т.д. (услуги по размещению и доставке данных), или загрузка журналов аварий и т.д.
  • ‘NonFreeNet’ - the application contains a feature that promotes or depends on a Non-Free network service which is impossible, or not easy to replace. Replacement requires changes to the app or service. This antifeature would not apply, if there is a simple configuration option that allows pointing the app to a running instance of an alternative, publicly available, self-hostable, free software server solution.
  • ‘NonFreeAdd’ - приложение продвигает несвободные дополнения, так что приложение фактически является рекламой другого несвободного программного обеспечения.
  • ‘NonFreeDep’ - приложение зависит от несвободного приложения (например, Google Maps) - т.е. оно требует его установки на устройстве, но не включает его.
  • ‘NSFW’ — в приложении содержится контент, который пользователь может не захотеть публиковать или демонстрировать, аббревиатура от «Not Safe For Work (небезопасно для работы)».
  • ‘UpstreamNonFree’ - приложение является или зависит от несвободного программного обеспечения. Это не означает, что несвободное программное обеспечение включено в приложение: Скорее всего, оно было каким-то образом исправлено, чтобы удалить несвободный код. Однако функциональность может отсутствовать.
  • ‘NonFreeAssets’ - приложение содержит и использует несвободные активы. Наиболее распространенный случай - приложения, использующие произведения искусства - изображения, звуки, музыку и т.д. - по некоммерческой лицензии.
  • ‘KnownVuln’ - приложение имеет известные уязвимости безопасности.
  • ‘ApplicationDebuggable’ - APK-файл скомпилирован для отладки (application-debuggable), что обычно делает его непригодным для обычных пользователей и использования.
  • ‘NoSourceSince’ - Источник этого приложения больше недоступен. Либо приложение стало коммерческим, либо репозиторий был закрыт, либо оно переместилось в неизвестное нам место. Обычно это означает, что дальнейших обновлений не будет, пока источник не появится вновь.

Это преобразуется в (<antifeatures>) в XML-файле (index.xml).

Отключено

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

Требуется Root

Установите в это необязательное поле в значение “True”, если для использования приложения требуются привилегии root. Это позволит клиенту отфильтровать его, если пользователь того пожелает. Независимо от того, требуется root или нет, в описании желательно указать условия, при которых может быть запрошен root, и причину этого.

Это преобразуется в (<requirements>) в XML-файле (index.xml).

Архив политик

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

Версия, указанная через CurrentVersionCode, всегда считается самой новой при решении вопроса о том, какие версии поместить в архив. Это означает, что когда ArchivePolicy имеет значение “1 версия”, сохраняется только APK, соответствующий CVC, который не обязательно имеет самый высокий код версии.

В настоящее время поддерживается только формат “n версий”, где n - количество версий, которые необходимо сохранить. По умолчанию установлено значение “3 версии”.

Режим проверки обновлений

Это определяет метод, используемый для определения доступности новых выпусков - другими словами, обновление полей CurrentVersion и CurrentVersionCode в метаданных процессом fdroid checkupdates.

Доступными режимами являются:

  • None - проверка не производится, поскольку нет подходящего автоматизированного способа сделать это. Обновления должны проверяться вручную. Используйте это, например, при развертывании нестабильных или исправленных версий; когда сборки выполняются в каталоге, отличном от того, где находится AndroidManifest.xml; если разработчики используют систему сборки Gradle и хранят информацию о версии в отдельном файле; если разработчики создают новую ветку для каждого выпуска и не делают тегов; или если вы изменили имя пакета или логику кода версии.
  • Static - Проверка не производится - либо разработка прекращена, либо новые версии нежелательны. Этот метод также используется, когда нет другого метода проверки, и разработчик, находящийся выше по течению, информирует нас о новых версиях.
  • RepoManifest - При последнем коммите файлы AndroidManifest.xml и build.gradle ищутся в каталоге, где они были найдены в последней сборке. Целесообразность использования этого метода зависит от процесса разработки, используемого разработчиками приложения. Не следует указывать этот метод, если вы не уверены, что он уместен. Например, некоторые разработчики устанавливают версию при начале разработки, а не при публикации. Метод вернет ошибку, если AndroidManifest.xml переместился в другой каталог или если имя пакета изменилось. Текущая версия, которую он выдает, может быть неточной, поскольку не все версии пригодны для публикации. Поэтому перед сборкой часто необходимо проверить, была ли текущая версия опубликована где-либо разработчиками, либо проверив APK, которые они распространяют, либо по тегам в репозитории исходного кода.

    В настоящее время он работает для каждого типа репозитория в разной степени, за исключением репозитория типа srclib. Для репозиториев типов git, git-svn и hg вы можете использовать “RepoManifest/yourbranch” в качестве UpdateCheckMode, так что “yourbranch” будет веткой, используемой вместо ветки по умолчанию. Значения по умолчанию “master” для git, “default” для hg и none для git-svn (он остается в той же ветке). С другой стороны, поддержка ветвей еще не была реализована в bzr и svn, но RepoManifest все еще может быть использован без нее.

  • RepoTrunk - Для svn и git-svn репозиториев, особенно для тех, у которых нет встроенного AndroidManifest.xml файла, проверки Tags и RepoManifest не будут работать, так как нет информации о версии, которую можно получить. Но для тех приложений, которые автоматизируют свой процесс сборки с помощью ссылки на коммит, на который указывает HEAD, RepoTrunk установит CurrentVersion и CurrentVersionCode на этот номер.
  • Tags - Проверяются файлы AndroidManifest.xml и build.gradle во всех помеченных ревизиях в хранилище исходных текстов, ищется код наивысшей версии. Целесообразность использования этого метода зависит от процесса разработки, используемого разработчиками приложения. Не следует указывать этот метод, если вы не уверены в его целесообразности. Его не следует использовать, если разработчики любят помечать нестабильные версии или, как известно, забывают помечать релизы. Как и RepoManifest, он не вернет правильное значение, если каталог, содержащий AndroidManifest.xml, переместился. Несмотря на эти предостережения, это часто любимый UpdateCheckMode.

    В настоящее время он работает только для репозиториев git, hg, bzr и git-svn. В случае последних, URL репозитория должен содержать путь к ветвям и тегов, иначе теги не будут найдены.

    По желанию добавьте в конце шаблон regex - разделенный пробел - чтобы проверять только те теги, которые соответствуют этому шаблону. Полезно, когда приложения отмечают нерелизные версии, такие как X.X-alpha, так что вы можете отфильтровать их с помощью чего-то вроде .*[0-9]$, что требует, чтобы имена тегов заканчивались цифрой.

    Optionally UpdateCheckData can be specified to extract version code and name from repository files you specify (instead of relying on the defaults used to match against otherwise, which in most cases is build.gradle or AndroidManifest.xml).

  • HTTP - HTTP-запросы используются для определения кода текущей версии и ее названия. Это контролируется полем UpdateCheckData, которое имеет форму urlcode|excode|urlver|exver.

    Во-первых, если urlcode не является пустым, документ из этого URL-адреса извлекается и сопоставляется с регулярным выражением excode, причем первая группа становится кодом версии.

    Во-вторых, если urlver не является пустым, то документ с этого URL-адреса извлекается и сопоставляется с регулярным выражением exver, причем первая группа становится именем версии. Поле urlver может быть может быть установлено просто ‘.’, что означает использование того же документа, возвращенного для кода версии, а не использование другого документа.

VercodeOperation

Операция, которая будет применена к веркоду, полученному с помощью определенного UpdateCheckMode. %c будет заменен на реальный веркод, а вся строка будет передана функции eval в python.

Особенно полезно для приложений, которые мы хотим скомпилировать для разных ABI, но чьи веркоды не всегда имеют нули в конце. Например, установив VercodeOperation на что-то вроде %c*10 + 4, мы сможем отслеживать обновления и собирать до четырех различных версий каждой версии.

Не проверять обновления

При проверке обновлений (через UpdateCheckMode) это может быть использовано для указания символа regex, который, если сопоставить его с именем версии, заставит игнорировать эту версию. Например, ‘beta’ может быть указано для игнорирования имен версий, включающих этот текст.

Доступно только с UpdateCheckMode по HTTP.

UpdateCheckName

При проверке обновлений (через UpdateCheckMode) это можно использовать для указания имени пакета для поиска. Полезно, когда приложения имеют статическое имя пакета, но программно изменяют его в некоторых вкусах приложений, например, добавляя “.open” или “.free” в конце имени пакета.

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

UpdateCheckData

Используется совместно с UpdateCheckMode Tag или HTTP.

UpdateCheckData: <vercode-location>|<RegEx-for-versionCode>|<versionName-location>|<RegEx-for-versionName>
  • vercode-location - URL (with UpdateCheckMode: HTTP) or path/file relative to repo root, leave empty to check the tag name instead (with UpdateCheckMode: Tags).
  • RegEx-for-versionCode - RegEx to match versionCode.
  • versionName-location - Same as vercode-location just for versionName. A . means to take vercode-location, leave empty to check the tag name instead (only with UpdateCheckMode: Tags).
  • RegEx-for-versionName - Similar to RegEx-for-versionCode, just for versionName.
  • RegEx pipe operators are not supported at this time.

Examples for UpdateCheckMode: Tag:

  • Flutter app with the pubspec.yaml in the repo root: pubspec.yaml|version:\s.+\+(\d+)|.|version:\s(.+)\+
  • Use the git tag as version name: app/build.gradle|versionCode\s(\d+)||
  • Optionally a regex to extract the version name from the tag can be specified: app/build.gradle|versionCode\s(\d+)||Android-([\d.]+)
  • If no file for the version code was specified, code and name can be extracted from the tag: '|\+(\d+)||Android-([\d.]+)'
  • Note: Be sure to use single quotes around the entire value if you leave vercode-location empty: UpdateCheckData: '|\+(\d+)||Android-([\d.]+)'

Examples for UpdateCheckMode: HTTP:

  • https://foo/version.json|"version_code":.*"(.*)"|.|"version_name":.*\"(.*)\",
  • https://foo/version_fdroid.txt|versionCode=(.*)|.|versionName=(.*)

AutoUpdateMode

Определяет метод, используемый для автоматической генерации новых сборок при появлении новых релизов - другими словами, добавление новой строки Build Version в метаданные. Это происходит в сочетании с функциональностью UpdateCheckMode - т.е. когда обновление обнаруживается этой функциональностью, оно также обрабатывается этой.

Доступными режимами являются:

  • None - автообновление не производится
  • Version - Generates a value (tag name) used for the commit: property of new build blocks. It is simply text in which %v and %c are replaced with the required version name and version code respectively. The resulting string must match an existing tag in the app’s repo, which then will be used by F-Droid to build the corresponding version.

    Например, если приложение всегда имеет тег “2.7.2”, соответствующий версии 2.7.2, вы просто укажете “Version %v”. Если приложение всегда имеет тег “ver_1234” для версии с кодом версии 1234, можно указать “Version ver_%c”.

    Continuing the first example above, you would specify that as “Version +-fdroid %v” - “-fdroid” is the suffix F-Droid will then append to the versionName specified in e.g. build.gradle when building the APK.

    Кроме того, на этом этапе к имени версии может быть добавлен суффикс чтобы отличить сборку F-Droid от оригинальной. Продолжая первый пример выше, вы можете указать это как “Version +-fdroid %v” - “-fdroid” - это суффикс.

    If UpdateCheckMode is set to Tags the generator string behind Version is optional and not used for the commit: field.

Текущая версия

Имя версии, которое является рекомендуемым выпуском. Могут существовать более новые версии приложения, чем эта (например, нестабильные версии), и почти наверняка будут более старые. Это должна быть та версия, которая рекомендуется для общего использования. В случае отсутствия исходного кода для текущей версии или использования несвободных библиотек, в идеале это должна быть последняя версия, которая все еще свободна, хотя может быть целесообразно сохранить автоматическую проверку обновлений - смотрите No Source Since.

Это поле обычно обновляется автоматически - см. UpdateCheckMode.

Это преобразуется в (<marketversion>) в XML-файле (index.xml).

CurrentVersionCode

Код версии, соответствующий полю CurrentVersion. Оба эти поля должны быть правильными и соответствовать друг другу, хотя именно код текущей версии используется Android для определения порядка версий и клиентом F-Droid для определения того, какая версия должна быть рекомендована.

Обычно это поле обновляется автоматически - см. UpdateCheckMode.

Если не установлено, клиенты будут рекомендовать самую высокую версию, которую они могут, как если бы CurrentVersionCode был бесконечным.

Это преобразуется в (<marketvercode>) в XML-файле (index.xml).

NoSourceSince

В случае отсутствия исходного кода для CurrentVersion, о которой сообщает Upstream, или появления элементов Non-Free, здесь определяется первая версия, для которой начал отсутствовать исходный код. Приложения, у которых отсутствует исходный код только для одной или нескольких версий, но предоставляются исходные коды для более новых версий, здесь не рассматриваются - это поле предназначено для иллюстрации того, какие приложения в настоящее время не распространяют исходный код, и с какого времени они это делают.

Устаревшие или удаленные поля

Provides

Разделенный запятыми список идентификаторов приложений, которые предоставляет данное приложение. Это поле было только заглушкой и никогда ни для чего не использовалось. Оно никогда не поддерживалось ни в index-v1.json, ни в _.yml файлах метаданных.

Это конвертируется в (<provides>) в XML файле (index.xml).