F-Droid

Довідка про метадані збірки

Дані, з яких fdroid update складає загальнодоступний індекс, походять із кількох джерел:

These metadata files are simple, easy to edit text files, always named as the “package name” with file type appended. There are a wide range of available fields for adding information to describe packages and/or apps. For all of the fields like AuthorName that apply to all releases of a package/app, the fields use CamelCase starting with an upper case letter. All other fields use camelCase starting with a lower case letter, including per-build fields, localized fields, etc.

Note that although the metadata files are designed to be easily read and written by humans, they are also processed and written by various scripts. They can be automatically cleaned up when necessary, eg. comments are removed. The structure will be preserved correctly, although the order of fields will be standardised. In fact, you can standardise all packages in a repository using a single command, without changing the functional content, by running:

fdroid rewritemeta

Або виконайте її лише для певного застосунку:

fdroid rewritemeta org.adaway

Розмітка та формат даних

F-Droid metadata files are written in YAML and have a file extension .yml. The top-most data structure is a “map” or “dictionary”, made up of key/value pairs. All keys are strings. There are some internal data types used for values:

  • TYPE_BOOL - Або true, або false.
  • TYPE_BUILD - Список записів збірки, які є картами пар ключ/значення.
  • TYPE_INT - Ціле число у десятковому форматі.
  • TYPE_LIST - Список рядків.
  • TYPE_MULTILINE - Блок тексту з кількох рядків.
  • TYPE_SCRIPT - Рядок або список рядків для виконання як скрипту bash.
  • TYPE_STRING - Рядок.
  • TYPE_STRINGMAP - Карта карт, внутрішні ключі якої розташування BCP 47, а значення — прочитний людиною текст.

The canonical format is YAML 1.2. The process of reading metadata files is more tolerant, and will do some automatic type conversions when that can provide a reliable transformation. fdroid rewritemeta will output YAML 1.2, so it will not preserve the original values as written, if they have been converted.

Поля

У наступних розділах описуються поля, визнані у файлі.

Categories (Категорії)

Any number of categories for the application to be placed in. There is no fixed list of categories - both the client and the web site will automatically show any categories that exist in any applications. However, if your metadata is intended for the main F-Droid repository, you should use one of the existing categories defined in fdroiddata or discuss the proposal to add a new one. Categories must be a list of items, even if there is just one.

AuthorName (Ім’я автора)

The name of the author, either full, abbreviated or pseudonym. If present, it should represent the name(s) as published by upstream, e.g. in their copyright or authors file. This can be omitted (or left blank). The same AuthorName should be used for apps from the same author so that other apps from the same author can be found.

AuthorEmail (Електронна адреса автора)

Адреса е-пошти авторки, автора чи команди. Можна пропустити (чи залишити порожньою).

Увага: це замінює всі значення AuthorEmail, вказані у вихідному коді застосунку.

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

URL-адреса вебсайту авторів застосунку. Це можна пропустити (або залишити порожнім).

Увага: це замінює всі значення AuthorWebSite, вказані у вихідному коді застосунку.

License (Ліцензія)

The overall license for the application in terms of the binary that the user can install. Values should correspond to short identifiers of the SPDX license list. There can only be one license listed here. If there are multiple licenses that apply to the source code, then this field should contain the least restrictive license that the whole app can be used under. When multiple licenses are combined, that usually means the most restrictive wins.

Це поле не описує ні всієї складності ліцензій окремих складових застосунку, ні випуску застосунків водночас під кількома ліцензіями.

AutoName (Автоназва)

Назва застосунку в тому вигляді, в якому її вдається отримати з вихідного коду. Це потрібно, щоб fdroid checkupdates міг вписувати звичну назву в опис комітів, створюваних при виявленні оновлення застосунку. Значення AutoName генерується автоматично при запуску fdroid checkupdates і використовується лише для повідомлень комітів, створюваних fdroid checkupdates.

Name (Назва)

The title of the application, with optional descriptive phrase. This field will override all other sources of the application name, including scraped from the APK and from localized metadata.

Note: Don’t use this. The localized metadata in the app’s source code should be used instead.

максимум 50 символів

Увага: це замінює всі значення Name/title, вказані у вихідному коді застосунку.

WebSite (Вебсайт)

The URL for the application’s web site. If there is no relevant web site, this can be omitted (or left blank). Don’t use the source code url as website.

SourceCode (Джерельний код)

URL-адреса для перегляду або отримання джерельного коду застосунку. Це має бути щось зручне для людей. Машинозчитуваний джерельний код розглядається в полі Repo.

IssueTracker (Трекер обговорень)

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

Translation (Переклад)

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

Changelog (Історія змін)

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

URL-адреса внесків для проєкту. Це повинна бути сторінка внесків для проєкту, якщо вона існує.

Тут можна використати пряме посилання PayPal за відсутності альтернатив. Проте пам’ятайте, команда розробки може не знати про це пряме посилання, і щось може піти не так, якщо вони зрештою змінять обліковий запис PayPal або якщо PayPal змінить формат посилань. Краще завжди використовувати посилання, явно надане командою розробки, ніж який-небудь автоматично згенерований «код кнопки».

Liberapay

The project’s Liberapay (https://liberapay.com) user or group name, if it has one. This should be an alphanumeric name, such that (for example) https://liberapay.com/xxxxx which redirects to your account page. This used to be LiberapayID, which was a numeric ID.

OpenCollective

The project’s Open Collective (https://opencollective.com) user or group name, if it has one. This should be an alphanumeric name, such that (for example) https://opencollective.com/xxxxx redirects to your account page.

Bitcoin

Адреса Bitcoin для пожертви проєкту.

Litecoin

Адреса Litecoin для пожертви проєкту.

Summary (Підсумок)

A brief summary of what the application is. The Summary is used in the app list and tile views of the F-Droid client, and as a sub-headline in some other views.

Note: Don’t use this. The localized metadata in the app’s source code should be used instead.

максимум 80 символів

Увага: це замінює всі значення Summary або short_description, вказані у вихідному коді застосунку.

Description (Опис)

Повний опис програми, щодо останньої версії. Може складатися з кількох рядків (максимум 80 символів) та закінчуватися рядком, що містить єдиний знак ‘.’.

Форматування опису відповідає усталеним звичаям, підтримуваним різними сховищами застосунків:

  • Дозволено просте HTML-форматування.
  • Розриви рядка буде збережено.
    • Посилання на інші пакунки f-droid.org вебсайт дозволятиме натиснути, а інші посилання покаже звичайним текстом.

Може бути корисно описати: як оновитися з більш ранньої версії; чи містить застосунок якісь двійкові складові від команди розробки оригіналу; які невільні елементи було видалено; чи триває активна розробка застосунку; чи відстає найновіша доступна версія від актуальної; чи підтримує застосунок декілька архітектур; чи є верхня межа підтримуваних версій SDK — тобто всі дані, яких індекс не передбачає.

Note: Don’t use this. The localized metadata in the app’s source code should be used instead.

максимум 4000 символів

Увага: це замінює всі значення Description або full_description, вказані у вихідному коді застосунку.

MaintainerNotes (Примітки супроводу)

Це поле може містити кілька рядків (правила й синтаксис — як в описі) із допоміжними нотатками для команди F-Droid про супровід і оновлення саме цього застосунку в репозиторії.

RepoType (Тип репозиторію)

Тип репозиторію — для автоматичної збірки з вихідного коду. Якщо цього не вказати, автоматичні збірки буде вимкнено для цього застосунку. Можливі значення:

  • git
  • srclib

Repo (Репозиторій)

Розташування сховища.

Якщо RepoType — це git, то URL-адреса має бути публічною, використовувати https:// та не вимагати жодної автентифікації.

Якщо RepoType є srclib, тоді ви повинні вказати назву відповідного файлу .yml srclib. Наприклад, якщо srclibs/FooBar.yml існує, і ви хочете використовувати цей srclib, тоді вам потрібно встановити Repo на FooBar.

Binaries (Двійкові файли)

Адреса двійкових файлів, використовуваних для звірки.

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

Якщо звірка вдасться, F-Droid використає APK за адресою.

This url must be versioned and can be calculated from the versionName and versionCode.

Builds (Збірки)

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

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 вказує, який тег, коміт чи номер ревізії слід обрати в репозиторії вихідного коду для збірки.

Note: Don’t use branch name or tag name. The full commit hash should be used.

На додаток до трьох, завжди необхідних параметрів, описаних вище, додаткові параметри можна додати (у форматі ім'я: значення), щоб застосувати далі конфігурації до збірки. Це (приблизно в порядку застосування):

disable: <повідомлення>

Вимикає цю збірку, зазначаючи причину. (Для зворотної сумісності, замість цього можна додати на початок ID коміту символ «!»)

Мета цієї функції — позначити випуски, які неможливо зібрати (наприклад, втрачено код), щоб скрипти не генерували про них повторних повідомлень. (Також ця нотатка допомагає повернутись пізніше). Якщо APK вже зібрано, вимкнення спричинить його видалення при запуску fdroid update; саме так діємо, коли доводиться замінювати версію.

subdir: <шлях>

Specifies to build from a subdirectory of the checked out source code. This is the directory where the build scripts are run. For Gradle apps this should be the path where the build directory will be generated in. For Flutter apps, this should be the directory where pubspec.yaml file is in. The root of the source code repo is used by default.

submodules: true

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

sudo: xxxx

Specifies a script to be run using sudo bash -x -c "xxxx" in the buildserver VM guest. This script is run with full root privileges, but the state will be reset after each build. The vast majority of apps build using the standard Debian/stable base environment. This is useful for setting up the buildserver for complex builds that need very specific things that are not appropriate to install for all builds, or for things that would conflict with other builds. Don’t add commands which don’t need root privileges here.

timeout: <секунд>

Time limit for this build (in seconds). After time is up, buildserver VM is forcefully terminated. The default is 7200 (2 hours); 0 means no limit.

Обмеження діє лише в режимі сервера, тобто коли fdroid build викликано з опцією --server.

init: xxxx

Подібно до prebuild, але запускається з вихідним кодом ПЕРЕД будь-яким відбувається інша обробка.

Ви можете використовувати $$SDK$$ і $$NDK$$, щоб замінити шляхи до Каталоги Android SDK і NDK відповідно. Наступне так само доступні змінні для кожної збірки: $$VERSION$$, $$VERCODE$$ і $$COMMIT$$.

Він запускається у subdir:, якщо його встановлено.

oldsdkloc: true

Розташування SDK у сховищі має старий формат або build.xml очікує такого. «Новий» формат — це sdk.dir, а ДУЖЕ СТАРИЙ формат sdk-location. Як правило, якщо ви отримуєте повідомлення разом із рядки: “com.android.ant.SetupTask неможливо знайти” під час спроби build, потім спробуйте ввімкнути цю опцію.

Note: Only used by some old apps.

target: <ціль>

Зазначає конкретний цільовий SDK-компілятор, замінюючи значення, взяте з коду оригіналу. Це працює по-різному, залежно від системи збірки: наразі підтримуються лише проєкти з Ant, Maven та Gradle. Зауважте, це не впливає на цільовий SDK в AndroidManifest.xml, який визначає, наскільки нові функції може бути додано в збірку.

У випадку Ant-проєкту, зміниться project.properties застосунку й, можливо, підпроєктів. Імовірно, перепишеться весь build.xml, що прийнятно, якщо це «стандартний» файл Android або його взагалі немає, проте небажано, якщо цей файл було суттєво доповнено вручну.

Note: Only used by some old apps.

android update: auto|<path1>[,<path2>,...]

Усталено, Ant-збірки використовують ‘android update’ для створення чи оновлення проєкту та всіх його посилань. Вкажіть androidupdate: no, щоб це обійти. Зауважте, це не має сенсу в збірках, які не використовують Ant.

Значення за замовчуванням – auto, яке рекурсивно використовує шляхи в project.properties, щоб знайти всі підпроекти для оновлення.

Або можете перелічити через кому шляхи, в яких слід запустити «android update», відносно каталогу застосунку.

Note: Only used by some old apps.

encoding: xxxx

Додає local.properties властивість java.encoding зі вказаним значенням — зазвичай «utf-8». Ant-правила SDK виявляють це й змушують компілятор Java розпізнавати джерело як файли з цим кодуванням. Якщо отримуєте попередження при збірці про кодування символів, імовірно це вам потрібно.

Note: Only used by some old apps.

forceversion: true

Якщо зазначено, версію пакунку в AndroidManifest.xml буде замінено на ту назву версії, яку вказано в метаданих збірки.

Це корисно, якщо певний тег репозиторію оригіналу не оновив версію; або якщо треба зібрати конкретний коміт; або щоб підкреслити відмінність версії від оригіналу; або щоб вказати, на якій архітектурі чи платформі APK може виконуватись.

forcevercode: true

Якщо зазначено, код версії пакунку в AndroidManifest.xml буде замінено на той код версії, який вказано в метаданих збірки.

binary: URL

Розташування двійкового файлу, який використовується в процесі перевірки для цієї збірки.

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

Якщо звірка буде успішною, F-Droid використає попередній двійковий файл.

rm: <шлях1>[,<шлях2>,...]

вказує відносні шляхи файлів або каталогів для видалення перед початком будівництва. Шляхи вказані відносно основи каталог побудови - тобто перевірено корінь структури каталогу з вихідного сховища - не обов’язково того каталогу, який містить AndroidManifest.xml.

Якщо файлів чи каталогів декілька, перелічіть їх через кому. Каталоги видалятимуться рекурсивно.

extlibs: <бібліотека1>[,<бібліотека2>,...]

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

Note: Only used by some old apps.

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 вказуються однаково щодо додатків; Subdir: може бути списком, розділеним комами, для коли каталоги перейменовуються upstream; Оновити проект: оновлює проекти в робочому каталозі і на рівень нижче; Приготувати: можна використовувати для будь-якого виду підготовки: зокрема, якщо вам потрібно оновити проект із певною метою. Ви також можете використовувати $$name$$ в init/prebuild/build команди для заміни абсолютного шляху до каталогу бібліотеки.

Наразі srclibs використовується, якщо оригінал використовує jar-файли чи завантажує залежності з недовірених репозиторіїв. Оскільки srclibs не може бути оновлений автоматично, підмодуль git є кращим вибором.

patch: x

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

prebuild: xxxx

Specifies a shell command (or a list of commands) to run before the build takes place. Backslash can be used as an escape character to insert literal commas, or as the last character on a line to join that line with the next. It has no special meaning in other contexts; in particular, literal backslashes should not be escaped.

Команду виконує bash.

Зауважте, під час «prebuild» не має відбуватися жодної збірки: сканування коду й збірка архіву джерела, наприклад, відбуваються потім. Нетипові дії, які справді збирають щось чи створюють двійкові файли, слід винести в «build».

Замість $$name$$ буде підставлено шлях відповідної srclib, докладніше про це в каталозі srclib.

Ви можете використовувати $$SDK$$ і $$NDK$$, щоб замінити шляхи до каталоги Android SDK і NDK відповідно, напр. коли ти потрібно явно запустити проект оновлення Android. Наступне так само доступні змінні для кожної збірки: $$VERSION$$, $$VERCODE$$ і $$COMMIT$$.

Він запускається у subdir:, якщо його встановлено.

scanignore: <шлях1>[,<шлях2>,...]

Enables one or more files/paths to be excluded from the scan process. This should only be used where there is a very good reason, and probably accompanied by a comment explaining why it is necessary in the Merge Request.

Виявлення проблем у вихідному коді пропускатиме файли, чиї відносні шляхи починаються з будь-якого зазначеного тут шляху.

scandelete: <шлях1>[,<шлях2>,...]

під час запуску процесу сканування будь-які файли, які викликають помилки, - наприклад двійкові файли - буде видалено. Він діє так само, як scanignore, але замість того, щоб ігнорувати файли, це видаляє їх.

Корисно, коли сховище вихідного коду містить двійкові файли чи інше непотрібні файли, які не потрібні для збірки. Замість видалення їх вручну за допомогою rm, використання scandelete простіше.

build: xxxx

як для prebuild, але виконується під час фактичної збірки фаза (але перед основною збіркою Ant/Maven). Використовуйте це лише для дій, які займатися фактичним будівництвом. Необхідно виконати будь-яку підготовку вихідного коду за допомогою init або prebuild.

Any building that takes place before build will be ignored, as either Ant, mvn will be executed to clean the build environment right before build (or the final build) is run and the source code will be scanned to ensure there is no binary.

Ви можете використовувати $$SDK$$ і $$NDK$$, щоб замінити шляхи до Каталоги Android SDK і NDK відповідно. Наступне для кожної збірки так само доступні змінні: $$VERSION$$, $$VERCODE$$ і $$COMMIT$$.

Він запускається у subdir:, якщо його встановлено.

buildjni: [yes|no|<перелік тек>]

Дозволяє створення рідного коду за допомогою сценарію ndk-build раніше виконує основну збірку Ant. Значенням може бути список каталогів відносно основного каталогу програми, у якому потрібно запускати ndk-build або ‘yes’, що відповідає ‘.’ . Використання явного списку може бути корисним для створення багатокомпонентних проектів.

У цьому випадку процеси збирання та сканування скаржаться (відмовляються створювати). параметр не визначено, але присутній каталог jni. Якщо нативний код будується іншими засобами, як-от завдання Gradle, ви можете вказати ні тут, щоб уникнути цього. Однак, якщо нативний код фактично не потрібний або не використовується, замість цього видаліть каталог (наприклад, за допомогою rm: jni). Використання buildjni: ні, коли код jni не використовується і не створений, призведе до помилки, що нативний бібліотеки очікувалися в отриманому пакеті.

Note: Only used by some old apps.

ndk: <версія>

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_NDK and ANDROID_NDK_HOME environment variables will be set to the first version in the list.

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

Збирати з Gradle замість Ant. Зазначте потрібні різновиди (flavours). Регістр чутливий, оскільки шлях до APK результату міститиме вид.

If only one flavour is given and it is ‘yes’, no flavour will be used. Note that for projects with flavours, you must specify at least one valid flavour since ‘yes’ will build all of them separately. The Gradle task will be assembel<flavors>Release.

Метадані Fastlane для цього варіанту можна помістити в ./src/<buildFlavor>/fastlane/metadata/<locale>/ замість ./fastlane/metadata/<locale>/.

maven: yes[@<каталог>]

Створення за допомогою Maven замість Ant. Додатковий @<dir> повідомляє F-Droid щоб запустити Maven у цьому відносному підкаталозі. Іноді це так потрібно використовувати @.., щоб збірки відбувалися правильно.

preassemble: <завдання1>[,<завдання2>,...]

Перелік завдань Gradle, які слід запустити перед завданням assemble у Gradle-проєкті.

gradleprops: <властивість1>[,<властивість2>,...]

Перелік властивостей, які Gradle отримає через командний рядок. Властивість може мати вигляд щось або ключ=значення.

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

antcommands: <ціль1>[,<ціль2>,...]

Альтернативний набір команд (цілей) Ant замість усталеного «release». Не підтримує жодних опцій, зокрема шляху до файлу build.xml.

Note: Only used by some old apps.

вихід: <glob/to/output.apk>

укажіть глобальний шлях, звідки отриманий непідписаний випуск APK збірка повинна бути. Це можна використовувати в поєднанні з побудовою такі методи, як gradle: yes або maven: yes, але якщо метод збірки не вказано, збірка виконується вручну. Ви повинні бігти ваші команди збірки, наприклад make, у build.

Він запускається у subdir:, якщо його встановлено.

postbuild: xxxx

As for prebuild, but runs after the actual build phase (the main Ant/Maven build). Use this only for actions that perform some post-processing on the build outputs.

Замість $$name$$ буде підставлено шлях відповідної srclib, докладніше про це в каталозі srclib.

Можете використати $$SDK$$ і $$NDK$$, щоб підставити шляхи до каталогів Android SDK і NDK відповідно. Для кожної збірки аналогічно стають доступними такі змінні : $$VERSION$$, $$VERCODE$$ і $$COMMIT$$.

Шлях до вихідного APK доступний за адресою $$OUT$$.

Він запускається у subdir:, якщо його встановлено.

novcheck: true

Не перевіряти назву й код версії в отриманому APK, тобто нехтувати виводом збірки та вважати метадані коректними. Буде втрачено корисні перевірки цілісності, тож утримайтесь від цього, якщо значення можливо виявити.

antifeatures: <функція1>[,<функція2>,...]

Перелік небажаних функцій конкретної збірки. Їх описано в розділі AntiFeatures (небажані функції).

AllowedAPKSigningKeys (Дозволені ключі підпису APK)

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 lower case hex value of the SHA-256 fingerprint of the signing certificate. This can be fetched using apksigner from the Android SDK:

apksigner verify --print-certs зразок.apk | grep SHA-256

Або за допомогою keytool з Java Development Kit (JDK):

keytool -printcert -jarfile example.apk | sed -n 's/[[:space:]]*SHA256: //p' | tr -d ':' | tr '[:upper:]' '[:lower:]'

Usually, APKs are signed using only one signer. APKs that require verification by multiple signers are currently not supported by AllowedAPKSigningKeys (this is quite rare).

AntiFeatures (Небажані функції)

Якщо зазначено, то має бути розділеним комами переліком підмножини наступних значень, що описує, які небажані функції містить застосунок. В описі слід зазначити підстави вказання небажаних функцій:

  • Ads — застосунок містить рекламу.
  • KnownVuln — застосунок має відомі вразливості безпеки.
  • NonFreeAdd — застосунок просуває невільні додатки, тобто по суті є рекламою іншого невільного програмного забезпечення.
  • NonFreeAssets — застосунок містить і використовує невільні ресурси. Зазвичай такими є твори мистецтва: зображення, звуки, музика тощо — на умовах ліцензії, яка обмежує комерційне використання або створення похідних робіт (наприклад, будь-яка ліцензія Creative Commons з обмеженням «Некомерційна» (NC) або «Без похідних» (ND)).
  • NonFreeDep — застосунок залежить від невільного застосунку (наприклад, від Google Карт), тобто вимагає його присутності на пристрої, хоч і не додає його сам.
  • NonFreeNet - застосунок просуває або повністю залежить від власницької мережевої служби.
  • NoSourceSince — оригінал коду застосунку став недоступний. Можливо, застосунок став комерційним — або його репозиторій знищено чи переміщено до невідомої нам адреси. Зазвичай це означає, що оновлень більше не буде, поки початковий код не з’явиться знову.
  • NSFW — застосунок містить вміст, який авдиторія може не бажати оприлюднювати чи скрізь показувати; походить від терміну «Not Safe For Work» — «небезпечно для роботи».
  • TetheredNet — застосунок повністю залежать від служби, яку неможливо (чи складно) замінити. Тобто заміна вимагає внесення змін до застосунку чи служби. Цю не буде застосовано, якщо існує проста опція конфігурації, яка дозволяє вказати застосунку на запущений екземпляр альтернативного загальнодоступного саморозміщуваного серверного рішення.
  • Tracking — користувацькі дані чи діяльність усталено відстежуються або витікають. True, якщо застосунок чи певну його функцію неможливо використати без жодного збору й поширення таких даних, або якщо він робить запити до мережної служби, що збирає дані (незалежно від того, побудована ця служба на вільному програмному забезпеченні чи ні). Наприклад, завантажує різні залежно від користувацьких дій дані про погоду, карти, аватари тощо, використовує служби розміщення й доставлення даних, вивантажує журнали збоїв тощо.

Disabled (Вимкнено)

Якщо це поле присутнє, програма не потрапляє до загальнодоступного індексу. Це дозволяє зберігати метадані, поки програму тимчасово не можна публікувати. Значення має бути описом того, чому програму вимкнено. Жодні APK або архіви вихідного коду не видаляються: щоб очистити APK, перегляньте disable у розділі Builds або видаліть його вручну для збірок розробників. Таким чином, поле використовується, коли програма пережила свою корисність, оскільки зберігається вихідний архів.

RequiresRoot (Необхідні права root)

Додайте це необов’язкове поле зі значенням true, якщо для використання застосунку потрібні root-права. Це дає змогу фільтрувати користувацьку видачу. Незалежно від того, обов’язковий root чи ні, в описі слід виділити абзац на умови, в яких root може бути запитано, й на підстави для цього.

ArchivePolicy (Політика архівації)

Це визначає політику пересування старих версій застосунку до архівного репозиторію, якщо такий налаштовано (вказано усталену максимальну кількість версій, що зберігаються в головному репозиторії, при досягненні якої старіші версії посуваються до архіву). Усталене значення можна замінити для певного застосунку цією властивістю.

The version specified via CurrentVersionCode is always considered the newest version when deciding which versions to put into the archive. This means that when ArchivePolicy is set to 1 only the APK corresponding to CVC is kept, which is not necessarily the one with the highest version code.

Наразі єдиним підтримуваним форматом є n, де n означає кількість версій, які потрібно зберегти. За замовчуванням 3. Для програм зі списком VercodeOperation значення за замовчуванням обчислюється як «3 × кількість операцій», напр. для програми з двома операціями, для двох ABI, буде збережено 6 версій.

AutoUpdateMode (Режим автооновлення)

Це визначає метод, який використовується для автоматичного створення нових збірок, коли нові випуски доступні - іншими словами, додавання нового рядка версії збірки до метаданих. Це відбувається в поєднанні з функцією UpdateCheckMode, тобто коли оновлення виявляється цим, воно також обробляється цим.

Щоб увімкнути, встановіть підтримуваний режим:

  • Version — автооновлення увімкнено.

    Якщо UpdateCheckMode встановлено на Теги, це має бути встановити Версія без шаблону. Позначений тег використовується безпосередньо.

    If UpdateCheckMode is set to HTTP, a pattern should be added after the Version. The pattern is used to generate 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, потрібно просто вказати Версія %v. Якщо додаток завжди має тег ver_1234 для версії з кодом версії 1234, ви повинні вказати Version ver_%c.

    Крім того, тут можна додати суфікс до назви версії етап, щоб відрізнити збірку F-Droid від оригіналу. Продовжуючи перший приклад вище, ви б вказали це як Версія +-fdroid %v, де -fdroid — це суфікс, який буде додано до versionName, указаного, напр. build.gradle під час створення APK.

Для застосунків зі списком з VercodeOperation кількість збірок дорівнює кількості елементів у списку.

UpdateCheckMode (Режим перевірки оновлень)

Це визначає метод, який використовується для визначення того, коли нові випуски доступні – іншими словами, оновлення полів CurrentVersion і CurrentVersionCode у метаданих процесом fdroid checkupdates.

By default, no checking is done because there’s no appropriate automated way of doing so. Updates should be checked for manually. Use this, for example, when deploying unstable or patched versions; when builds are done in a directory different to where the AndroidManifest.xml is; if the developers use the Gradle build system and store version info in a separate file; if the developers make a new branch for each release and don’t make tags; or if you’ve changed the package name or version code logic.

Щоб увімкнути, встановіть підтримуваний режим:

  • Static - перевірка не виконується - або розробка припинена, або нові версії не потрібні. Цей метод також використовується, коли немає іншого доступного методу перевірки, а попередній розробник тримає нас у курсі нових версій.

  • RepoManifest - At the most recent commit, the AndroidManifest.xml and build.gradle files are looked for in the directory where they were found in the most recent build. The appropriateness of this method depends on the development process used by the application’s developers. You should not specify this method unless you’re sure it’s appropriate. For example, some developers bump the version when commencing development instead of when publishing. It will return an error if the AndroidManifest.xml has moved to a different directory or if the package name has changed. The current version that it gives may not be accurate, since not all versions are fit to be published. Therefore, before building, it is often necessary to check if the current version has been published somewhere by the upstream developers, either by checking for APKs that they distribute or for tags in the source code repository.

    For git repo types, you may use RepoManifest/yourbranch as UpdateCheckMode so that “yourbranch” would be the branch used in place of the default one. The default branch is “master”. It does not work for srclib repo types.

  • Tags - The AndroidManifest.xml and build.gradle files in all tagged revisions in the source repository are checked, looking for the highest version code. The appropriateness of this method depends on the development process used by the application’s developers. You should not specify this method unless you’re sure it’s appropriate. It shouldn’t be used if the developers like to tag unstable versions or are known to forget to tag releases. Like RepoManifest, it will not return the correct value if the AndroidManifest.xml were moved to another directory. Despite these caveats, it is often the favourite UpdateCheckMode.

    It currently only works for git repositories.

    Необов’язково додайте шаблон регулярного виразу в кінці, відокремивши його символом a пробіл - для перевірки лише тегів, які відповідають зазначеному шаблону. Корисно, коли програми позначають невипущені версії, наприклад X.X-alpha, щоб ви могли фільтрувати їх за допомогою чогось на зразок .*[0-9]$, для чого потрібні імена тегів закінчуються цифрою. Приклад: UpdateCheckMode: Теги .*[0-9]$

    Додатково можна вказати UpdateCheckData витягніть код версії та ім’я з указаних вами файлів сховища (замість покладаючись на значення за замовчуванням, якими в більшості випадків є build.gradle або AndroidManifest.xml).

  • HTTP - HTTP-запити використовуються для визначення коду поточної версії та назви версії. Це контролюється полем UpdateCheckData, яке має форму urlcode|excode|urlver|exver.

    По-перше, якщо urlcode непорожній, документ із цієї URL-адреси є таким отримано та порівняно з регулярним виразом excode, з перша група стає кодом версії.

    По-друге, якщо urlver непорожній, документ із цієї URL-адреси є таким отримано та порівняно з регулярним виразом exver, з перша група стає назвою версії. Поле urlver може бути встановити просто «.» який говорить про використання того самого документа, для якого повернуто код версії знову, а не отримання іншої.

VercodeOperation (Дія з кодом версії)

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

Особливо корисно, якщо треба зібрати для різних ABI застосунок, коди версій якого не завжди закінчуються нулями. Наприклад, якщо вказати кілька VercodeOperation, ми зможемо відстежувати оновлення та створювати до чотирьох різних версій кожної основної версії, скажімо, для 4-х архітектур:

VercodeOperation:
  - 100 * %c + 1
  - 100 * %c + 2
  - 100 * %c + 3
  - 100 * %c + 4

Отже, 4 блоки збірки копіюються зверху і додаються як оновлення з їх верифікаційним кодом, який обчислюється під час виконання кожної математичної операції.

UpdateCheckIgnore (Перевірка оновлень. Пропуск)

Під час перевірки оновлень (через UpdateCheckMode) це можна використовувати, щоб указати регулярний вираз, який, якщо збігається з назвою версії, спричиняє ігнорування версії. Наприклад, можна вказати «бета», щоб ігнорувати назви версій, які містять цей текст.

Доступно лише з UpdateCheckMode HTTP.

UpdateCheckName (Перевірка оновлень. Назва)

При перевірці оновлень (через UpdateCheckMode), це дає змогу зазначити, яку назву пакунку слід шукати. Доречно, коли застосунок має певну основну назву пакунку, але змінює її програмно в деяких різновидах збірки, наприклад додаючи «.open» чи «.free» в кінець назви пакунку.

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

UpdateCheckData (Перевірка оновлень. Дані)

Використовується в поєднанні з UpdateCheckMode Tags або HTTP.

UpdateCheckData: <адреса-коду>|<регулярний-вираз-коду>|<адреса-назви>|<регулярний-вираз-назви>
  • vercode-location – URL-адреса (з UpdateCheckMode: HTTP) або шлях/файл відносно кореня репо, залиште порожнім, щоб замість цього перевірити назву тегу (з UpdateCheckMode: Tags).
  • RegEx-for-versionCode – регулярний вираз для відповідності versionCode.
  • versionName-location – те саме, що vercode-location лише для versionName. . означає взяти vercode-location, залиште порожнім, щоб замість цього перевірити назву тегу (лише з UpdateCheckMode: Tags).
  • RegEx-for-versionName – Подібно до RegEx-for-versionCode, лише для versionName.
  • Конвеєрні оператори RegEx наразі не підтримуються.

Приклади для UpdateCheckMode: Теги:

  • Програма Flutter із pubspec.yaml у корені сховища: pubspec.yaml|версія:\s.+\+(\d+)|.|версія:\s(.+)\+
  • Використовуйте тег git як назву версії: app/build.gradle|versionCode\s(\d+)||
  • За бажанням можна вказати регулярний вираз для отримання назви версії з тегу: app/build.gradle|versionCode\s(\d+)||Android-([\d.]+)
  • Якщо файл для коду версії не вказано, код і назву можна отримати з тегу: '|\+(\d+)||Android-([\d.]+)'
  • Note: Be sure to use single quotes around the entire value if you leave vercode-location empty: UpdateCheckData: '|\+(\d+)||Android-([\d.]+)'

Приклади для UpdateCheckMode: HTTP:

  • https://foo/version.json|"код_версії":.*"(.*)"|.|"назва_версії":.*\"(.*)\",
  • https://foo/version_fdroid.txt|versionCode=(.*)|.|versionName=(.*)

CurrentVersion (Поточна версія)

Назва версії, яка є рекомендованим випуском. Можуть бути новіші версії програми (наприклад, нестабільні версії), і майже напевно будуть старіші. Це має бути те, що рекомендовано для загального використання. У випадку, якщо немає вихідного коду для поточної версії або використовуються невільні бібліотеки, в ідеалі це буде остання версія, яка все ще є безкоштовною, хоча може бути доцільним зберегти автоматичну перевірку оновлень — див. NoSourceSince.

Це поле зазвичай оновлюється автоматично: перегляньте UpdateCheckMode.

CurrentVersionCode (Код поточної версії)

Код версії, що відповідає полю CurrentVersion. Обидва поля мусять стосуватися одної чинної версії, хоча саме поле коду версії використовується в Android для визначення порядку версій, а в клієнті F-Droid — для визначення рекомендованої версії.

Це поле зазвичай оновлюється автоматично: перегляньте UpdateCheckMode.

Якщо не зазначено, клієнти радитимуть найвищу знайдену версію, ніби CurrentVersionCode нескінченний.

NoSourceSince (Джерельний код недоступний)

Якщо нам не вистачає вихідного коду для CurrentVersion, про який повідомляє Upstream, або якщо введено невільні елементи, це визначає першу версію, у якій почав відсутній вихідний код. Програми, у яких відсутній вихідний код лише для однієї чи кількох версій, але надають вихідний код для новіших, тут не розглядаються – це поле призначено для ілюстрації того, які програми наразі не поширюють вихідний код і відколи вони це роблять так.

Застарілі чи вилучені поля

Provides (Надає)

Comma-separated list of application IDs that this app provides. This field was only ever a stub and was never used for anything. It was never supported in index-v1.json nor .yml metadata files.

Пошук застосунків

Допомогти

F-Droid працює завдяки вашій підтримці!

Connect

mastodon
@fdroidorg@floss.social

Новини