构建元数据参考

fdroid update 用于编译公共索引的信息来自多个来源:

这些元数据文件是简单且易于编辑的文本文件,文件名通常为“包名称”加文件类型。有大量可用字段可用于添加信息以描述包和/或应用。适用于包或应用的所有发布版本的所有字段,如 AuthorName,都使用以一个大写字母开头的大驼峰式,形如 CamelCase。包括每个构建字段,本地化字段等在内的所有其他字段都使用一个小写字母开头的小驼峰式,形如 camelCase。

请注意,尽管元数据文件被设计为便于人类读取和写入,但它们也可以通过各种脚本进行处理和写入。必要时可自动格式化。结构和注释将正确保留,但字段顺序将标准化。(如果格式化后字段顺序与原文件中的不同,则注释被视为附加到其后面的字段中)。事实上,你可以通过运行以下命令,在不改变功能内容的情况下,使用单个命令标准化存储库中的所有包:

fdroid rewritemeta

或对特定应用,运行:

fdroid rewritemeta org.adaway

标记和数据格式

F-Droid 元数据用 YAML 写成,文件扩展名为 .yml。最顶层的数据结构是“映射”或“字典”,由键值对组成。所有的键均为字符串。有一些用于值的内部数据类型:

  • TYPE_BOOL - truefalse
  • TYPE_BUILD - 构建条目列表,条目是键值对的映射。
  • TYPE_INT - 十进制格式的整数。
  • TYPE_LIST - 字符串列表。
  • TYPE_MULTILINE - 多行文本的区块。
  • TYPE_SCRIPT - 将作为 bash 脚本执行的字符串或字符串列表。
  • TYPE_STRING - 一条字符串。
  • TYPE_STRINGMAP - 映射的映射,内部键是 BCP 47 区域设置,值是人类可读的文本。

标准格式是 YAML 1.2。读取元数据文件的过程容忍度更高,并且在能够提供可靠转换的情况下会执行一些自动类型转换。fdroid rewritemeta 将输出 YAML 1.2,因此如果原始值已被转换,则不会保留写入的原始值。

字段

以下部分描述了文件中可识别的字段。

Categories (类别)

要将应用置入的任意数量的类别。没有固定的类别列表 - 客户端和网站都会自动显示任何应用中存在的任何类别。但是,如果元数据用于 F-Droid 主存储库,则应该使用现有的类别之一:

  • App Store & Updater
  • Bookmark
  • Browser
  • Calculator
  • Calendar & Agenda
  • Cloud Storage & File Sync
  • Connectivity
  • Development
  • DNS & Hosts
  • Draw
  • Ebook Reader
  • Email
  • File Encryption & Vault
  • File Transfer
  • Finance Manager
  • Forum
  • Gallery
  • Games
  • Graphics
  • Habit Tracker
  • Icon Pack
  • Internet
  • Keyboard & IME
  • Launcher
  • Local Media Player
  • Location Tracker & Sharer
  • Messaging
  • Money
  • Multimedia
  • Music Practice Tool
  • Navigation
  • News
  • Note
  • Online Media Player
  • Pass Wallet
  • Password & 2FA
  • Phone & SMS
  • Podcast
  • Public Transport
  • Reading
  • Recipe Manager
  • Science & Education
  • Security
  • Shopping List
  • Social Network
  • Sports & Health
  • System
  • Task
  • Text Editor
  • Theming
  • Time
  • Translation & Dictionary
  • Unit Convertor
  • Voice & Video Chat
  • VPN & Proxy
  • Wallet
  • Wallpaper
  • Weather
  • Workout
  • Writing

或讨论添加新分类的提议。 分类 必须是项目列表,即便列表中只有一个项目。

在 XML 文件(index.xml)中,该字段将被转换为 (<categories>)。

AuthorName (作者姓名)

作者名字可为全名、缩写或别名。如果存在,它应该等同于上游发布的名称,例如在其版权或作者文件中。该部分可省略(或留空)。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<author>)。

AuthorEmail (作者的电子邮箱)

作者的电子邮箱地址。可省略(或留白)。

警告:这会覆盖所有的 AuthorEmail 条目在应用的源代码中设置

在 XML 文件 (index.xml) 中,该字段将被转换为 (<email>)。

AuthorWebSite (作者网站)

作者网站的链接。可省略(或留空)。

警告:这会覆盖所有的 AuthorWebSite 条目在应用的源代码中设置

License (许可证)

在用户可以安装的二进制文件意义上的应用的总体许可证。值应对应于 SPDX 许可证列表的短标识符。这里只能列出一个许可证。如果有多个适用于源代码的许可证,那么这个字段应该包含整个应用可以使用的限制性最小的许可证。当多个许可证结合时,通常意味着限制性最强的许可证获胜。

这个字段不能表示适用于部分应用的许可证的复杂性,或者整体在一个以上的许可证下发布的应用。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<license>) 。

AutoName (自动命名的应用名)

应用的名称可以最好地从源代码中检索出来。这样做是为了让 fdroid checkupdates 能够在发现应用的新更新时,在创建的提交描述中放入一个熟悉的名字。AutoName 条目在 fdroid checkupdates 运行时自动生成,并且只用于 fdroid checkupdates 生成的提交消息。

Name(名称)

应用的标题,可选描述性短语。这个字段将覆盖所有其他来源的应用名称,包括从 APK 和本地化元数据中抓取的名称。一般不需要设置 Name,因为应用的正确名称是从 APK 文件中检索出来的。然而,在 APK 包含一个坏的或缺失的应用名称的情况下,可以用这个来覆盖它。请注意,这只覆盖客户端显示的应用列表中的名称;它并不改变源代码中的名称或应用标签。

50 个字符限制

警告:这会覆盖所有的 Name / title 条目在应用的源代码中设置

在 XML 文件 (index.xml) 中,该字段将被转换为 (<name>)。

WebSite (网站)

该应用的网站 URL。如果没有相关的网站,可以省略(或留空)。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<web>)。

SourceCode (源代码)

用于查看或获取应用源代码的 URL。这应该是人类友好的页面。机器可读的源代码在由 Repo 字段涵盖。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<source>)。

IssueTracker (问题追踪器)

应用的问题跟踪器 URL。可选,因为不是所有的应用都有。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<tracker>)。

Translation (翻译)

应用的翻译门户或至少是一个指南的 URL。可选,因为不是所有的应用都有。

在 JSON 文件中 (index.json),该字段将被转换为 (翻译)。

Changelog (变更日志)

应用的更新日志 URL。可选,因为不是所有的应用都有。

在XML 文件 (index.xml) 中,该字段将被转换为 (<changelog>)。

用于捐赠项目的 URL。这应该是项目的捐赠页面,如果有的话。

在这里使用直接的 PayPal 链接是可能的,如果这是仅有的。然而,请记住,开发者可能不知道这个直接链接,如果他们后来改用了一个不同的 PayPal 账户,或者 PayPal 链接的格式改变了,就可能出错。最好是使用开发者明确公开的链接,而不是使用自动生成的“按钮代码”。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<donate>)。

Liberapay

项目的 Liberapay (https://liberapay.com) 用户或组名,如果有的话。这应该是一个由字母数字组成的名字,使(例如)https://liberapay.com/xxxxx 可以重定向到你的账户页面。这曾经是 LiberapayID,一个数字 ID。

在 XML 文件 (index.xml)中,该字段将被转换为 (<liberapay>)。

OpenCollective

项目的 Open Collective (https://opencollective.com) 用户或组名,如果有的话。这应该是一个字母数字组成的名称,使(例如)https://opencollective.com/xxxxx 指向你的账户页面。

Bitcoin (比特币)

一个用于捐赠项目的比特币地址。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<bitcoin>) 。

Litecoin (莱特币)

一个用于捐赠给项目的莱特币地址。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<litecoin>)。

Summary (概要)

关于该应用是什么的简介。Summary 用于 F-Droid 客户端的应用列表和磁贴视图中,并作为其他一些视图的副标题。

80 个字符限制

警告:这会覆盖所有的 Summary ,即”short description”条目 在应用的源代码中设置

在 XML 文件(index.xml) 中,该字段将被转换为 (<summary>)。

Description (描述)

对应用最新版本的完整描述。这可以跨越多行(每行应保持在 80 个字符以内),并以包含一个单 ‘.’ 的行作为结束。

描述的格式遵循许多应用商店的既定惯例:

  • 可以使用基本的 HTML 格式化。
  • 换行将被保留。
    • f-droid.org 上的其他软件包的链接将在网站上显示为可点击链接,其他链接将显示为纯文本。

与从更早版本更新有关的注释信息是很有帮助的;应用是否包含任何由上游开发者预构建内容,或者是否移除了非自由元素;应用是否处于快速开发阶段,或者最新版本是否落后于当前版本;应用是否支持多种架构,或者是否有指定的最大 SDK(此类信息未被记录在索引中)。

4000 个字符限制

警告:这会覆盖所有的 Description ,即“full description”条目 在应用的源代码中设置

在 XML 文件 (index.xml) 中,该字段将被转换为 (<desc>)。

MaintainerNotes (维护者注解)

这是一个多行字段,使用与描述相同的规则和语法。它用于记录 F-Droid 维护者的注意事项,以协助维护和更新仓库中的应用。

这些信息也会发布到维基上。

RepoType (存储库类别)

存储库类型 - 用于从源代码自动构建。如果不指定这个,这个应用的自动构建将被禁用。可能的值为:

  • git
  • srclib

Repo (存储库)

存储库位置。

如果 RepoTypegit,则 URL 必须可公开访问,使用https://,且不要求任何类型的身份认证。

如果 RepoTypesrclib,那么你必须指定相应的 srclib .yml 文件。例如,如果存在 srclibs/FooBar.yml 并且你想使用这个 srclib,那么你必须将 Repo 设置为 FooBar

Binaries (二进制文件)

验证过程中使用的二进制文件的位置。

如果指定了,F-Droid 将验证输出的 APK 文件和指定的文件。你可以使用 %v%c来指向当前构建的版本名称和版本代码。为了验证 F-Droid 客户端本身,你可以使用:Binaries: https://f-droid.org/repo/org.fdroid.fdroid_%c.apk

如果验证成功,F-Droid 将使用上游的二进制文件。

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 参数指定了在源代码库中构建它的标签、提交或修订号。

除了上述三个始终需要的参数外,还可以添加更多的参数(以 `name: value` 的格式)来对构建进行进一步配置。这些参数是(大致按应用顺序排列):
disable: <message>

禁用此构建,并给出原因。 (如果出于向后兼容目的, 也可以通过以 ‘!’ 开头的 commit ID 实现)

这个功能的目的是让不可编译的版本(比如说源代码没有发布)被标记出来,
    这样脚本就不会产生关于它们的重复信息。
    (同时也是为了记录这些信息以便日后查阅)。
    如果一个 APK 已经被构建了,
    禁用会导致它在 `fdroid update` 运行后被删除;
    这是的确需要替换一个版本时所需的步骤。
subdir: <path>

指定从检出的源代码的一个子目录中构建。 这是构建脚本运行的目录。

submodules: true

:如果项目(仅 git)有子模块,则使用 - 使得 git submodule update --init --recursive 将在源代码被克隆后执行。子模块在构建前和主应用存储库本身一样被重置和清理。

sudo: xxxx

:指定一个使用 sudo bash -x -c "xxxx" 在 buildserver VM guest 中运行的脚本。这个脚本是以完全的 root 权限运行的,但在每次构建后,其状态将被重置。绝大多数的应用都是使用标准的 Debian/stable 基本环境来构建的。这对于设置需要非常特殊东西的复杂的构建服务器是很有用的。 而这些东西不适合在所有的构建中安装或者与其他构建冲突。

超时 timeout: <seconds>

:该构建的时间限制(以秒为单位)。到时间之后,buildserver VM 会被强制终止。默认是 7200(2小时);0 表示没有限制。

限制只适用于服务器模式,即当 `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 cannot be found” 消息,请尝试启用此选项。

target: <target>

:指定一个特定的 SDK 目标进行编译,覆盖代码中由上游定义的值。取决于所使用的构建系统具有不同的作用 - 这个标志目前只影响 Ant,Maven 和 Gradle 项目。请注意,这并不改变 AndroidManifest.xml 中的目标 SDK,它决定了可以包含在构建中的功能的级别。

对于 Ant 项目,
 它修改应用和可能的子项目的 _project.properties_。
 这可能会导致整个 _build.xml_ 被重写,
 如果它是一个“标准”的 Android 文件或不存在就没有问题,
 但如果它是高度自定义的文件可能会导致问题。
androidupdate: auto|<path1>[,<path2>,...]

默认情况下, ‘android update’ 在 Ant 构建中用来生成或 更新项目及其所有引用的项目。 指定 androidupdate: no 可以绕过这个。 请注意,在不使用 Ant 的构建中,这不起作用。

默认值是 auto, 它以递归的方式地使用 project.properties 中的路径找到所有要更新的子项目。

除此之外,这个值可以是目录组成的列表,目录名之间用英文逗号隔开。 在这些目录中相对于应用目录运行 ‘android update’。

encoding: xxxx

用给定的值添加一个 java.encoding 属性到 local.properties 。这个值的编码通常会是 ‘utf-8’。这是由 SDK 的 ant 规则挑选的,并强迫 Java 编译器用这个编码 解释源文本。如果你在编译期间收到 有关字符编码的警告,你可能需要这个。

forceversion: true

:如果指定,AndroidManifest.xml 中的软件包版本将被替换为元数据中指定的构建版本名称。

这在一些情况下有用:上游存储库未更新其特定 tag 中的版本;建立一个任意的修订版;构建一个任意的 revision;明显地显示出此版本与上游版本有很大的不同;或者明确表示 APK 被设计用于哪个架构或平台上运行。

forcevercode: true

:如果指定,AndroidManifest.xml 中的软件包版本代码将被替换为构建的版本代码。另参见 forceversion。

binary: URL

此构建验证过程中所使用的二进制文件的位置。

如果指定了,F-Droid 将验证输出的 APK 文件和指定的文件。 你可以使用 %v%c来指向当前构建的版本名称和版本代码。 为了验证 F-Droid 客户端本身, 你可以使用: binaries: https://f-droid.org/repo/org.fdroid.fdroid_%c.apk

如果验证成功,F-Droid 将使用上游的二进制文件。

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

指定构建开始前 要删除的文件或文件夹的相对路径。 这些路径相对于构建目录的基路径 - 即从源代码库中检出的目录结构的根目录 - 不一定是包含 AndroidManifest.xml 的目录。

可以指定多个文件/目录,方法是用 ‘,’ 分隔它们。目录将以递归的方式被删除。

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

:逗号分隔的 build/extlib 中外部库(jar 文件)的列表,将被放置在项目的 libs 文件夹下。

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

:逗号分隔的源代码库或 Android 项目列表。每个条目为 name@rev 的形式,其中 name 是预定义的源代码库名称,rev 是在各自版本控制中使用的 revision 或标签。

对于 Ant 项目,
你可以选择在 srclib 项目的开头加上一个带冒号的数字,
以自动将其放在 _project.properties_ 中
作为指定编号下的一个库。
例如,如果你指定 `1:somelib@1.0`,
F-Droid 会自动执行传统做法 `prebuild:echo "android.library.reference.1=$$somelib$$">> project.properties`的等效操作。

每个 srclib 有一个元数据文件,
位于存储库目录中的 `srclibs/` 下,
源代码存储在 `build/srclib/` 中。_
[_RepoType_](#RepoType)和 [_Repo_](#Repo)指定方式和应用相同;
_Subdir_:目录被上游重命名时,可以是英文逗号分割的列表;
_Update Project:_更新工作目录以及下一级目录中的项目;
_Prepare:_可用于任何类型的准备,
如果你需要指定目录进行更新,
接着你也可以用 [`init`](#build_init)/[`prebuild`](#build_prebuild)/[`build`](#build_build)中的`$$name$$`替换库目录的绝对路径。

目前 srclib 只在上游使用 jar 文件或从不受信任的存储库中提取依赖关系时使用。
因为 srclibs 不能自动更新,
git 子模块是一个更好的选择。
patch: x

应用一个或多个补丁。 ‘x’ 指定一个 (或多个 - 用英文逗号分隔) metadata 下方目录中的文件,文件名与 metadata 文件相同,区别是没有 扩展名。这些补丁中的每一个 都被依次应用到代码中。

prebuild: xxxx

指定一个 shell 命令(或几个命令 - 用 && 连接) 在构建前运行。 反斜线可以作为转义字符来插入逗号, 或者在行尾连接该行和下一行。 在其他情况下,它没有特殊含义; 特别是,字面的反斜线不应该被转义。

该命令使用 bash 运行。

请注意,在此预构建阶段不应构建任何内容 - 比如,扫描代码和构建 source tarball 在 这之后发生。对于实际执行构建或生成二进制文件的自定义操作, 请使用 ‘build’。

可以使用 $$name$$ 将路径替换为引用的 srclib - 有关详细信息,请参阅 srclib 目录。

你可以使用 \$\$SDK\$\$$$NDK$$分别替换 Android SDK 和 NDK 目录路径。比如,当你 需要显式运行 android update project 时。此外,下列 不同构建的变量也可用: $$VERSION$$$$VERCODE$$$$COMMIT$$

设置后,这运行于 subdir:

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

:允许从扫描过程中排除一个或多个文件/路径。这应该只在有很好的理由的情况下使用,并且或许可以附加一条评论,解释为什么这是必要的。

扫描源代码树中的问题时,相对路径以此处给出的任何路径开始的相应文件将被忽略。
scandelete: <path1>[,<path2>,...]

运行扫描过程时, 任何触发错误的文件 - 如二进制文件 - 将被删除。 它与 scanignore作用一样, 但是它不会忽略这些文件,而是删除它们。

用于当源代码存储库包含二进制文件或其他构建不需要的文件。 相比于通过 rm手动删除它们, 使用scandelete 更容易。

build: xxxx

类似prebuild,但在实际构建阶段期间运行 (不过在主 Ant/Maven 构建前)。 请只对进行实际构建的操作使用它。 任何的源码准备都应使用 initprebuild来完成。

build之前发生的任何构建都将被忽略, 因为在运行 build(或最终构建)之前 Ant、mvn 或 gradle 将被执行以清理构建环境。

你可以使用 SDK$$NDK$$ 分别替换 Android SDK 和 NDK 目录路径。以下 不同构建的变量同样可用:$$VERSION$$$$VERCODE$$$$COMMIT$$

设置后,这运行于 subdir:

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

执行主 Ant 构建前,通过 ndk-build 脚本启用本地代码的构建。 值可以是由相对于主应用的多个目录组成的列表, 在这些目录中运行 ndk-build 命令,或者是 对应于 ‘.’ 的 ‘yes’。 使用明确的列表对构建多组件项目很有用。

如果此参数未定义,却存在一个 jni 目录的话, 构建和扫描过程会抱怨 (拒绝进行构建) 。如果 本机代码正由 Gradle 任务等其他方式构建, 你可以在此处指定 no 来避免这种情况。不过,如果实际上本机代码 不是必需的或不被使用,那么请删除该目录 (比如使用 rm: jni)。当 jni 代码既未被使用也未被 构建时使用 buildjni:no 会导致一条错误信息,表示 生成的包中预期有本地库。

ndk: <version>

在本次构建中使用的 NDK 版本。 该值是 NDK 的版本,是一个字符串,支持两种官方版本方案, 例如 r21e21.4.7075529 。支持 NDK r10e 或更高版本。 这也可以是一个版本字符串列表, 所有列出的版本都会被安装。 ANDROID_NDKANDROID_NDK_HOME环境变量将被设置为列表中的第一个版本。

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

:用 Gradle 而不是 Ant 进行构建,指定要使用的 flavour。Flavour 是区分大小写的,因为输出 APK 的路径是也是如此。

如果只给定一种 flavour 而且是 'yes' 的话,则没有 flavour 会被
使用。请注意,对于有 flavours 的项目,你必须指定至少
一种有效的 flavour, 因为 'yes' 会分别
构建所有的 flavor。

此架构构建的 Fastlane 元数据可放在 `./src/<buildFlavor>/fastlane/metadata/<locale>/` 而非 `./fastlane/metadata/<locale>/`。
maven: yes[@<dir>]

用 Maven 而不是 Ant 构建。 一个额外的 @<dir> 告诉 F-Droid 在该相对子文件夹下运行 Maven。 有时需要使用 @..才能正确地进行构建。

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

:在 Gradle 项目构建中,在 assemble 任务之前要运行的 Gradle 任务列表。

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

:要通过命令行传递给 Gradle 的 Gradle 属性列表。属性可以是 foo 的形式或 key=value 的形式。

比如说:`gradleprops=enableFoo,someSetting=bar` 将产生 `gradle -PenableFoo -PsomeSetting=bar`。
antcommands: <target1>[,<target2>,...]

指定另一套 Ant 命令 (target) 而非 默认的 ‘release’。它不能被赋予任何标记, 比如 build.xml 的路径。

output: <glob/to/output.apk>

指定构建的未签名版本 APK 应在的 glob 路径。 这可以和像 gradle: yesmaven: yes这样的构建方法结合使用, 但是如果没有指定构建方法, 构建是手动的。 你应该在 build中运行构建命令,例如make

设置后,这运行于 subdir:

postbuild: xxxx

类似prebuild, 但在实际构建阶段之后运行 (主 Ant/Maven 构建)。 仅将此用于对构建输出执行某些后处理的操作。

可以使用 $$name$$ 将路径替换为引用的 srclib - 有关详细信息,请参阅 srclib 目录。

你可以使用 SDK$$NDK$$ 分别替换 Android SDK 和 NDK 目录路径。以下 不同构建的变量同样可用:$$VERSION$$$$VERCODE$$$$COMMIT$$

使用 $$OUT$$ 设置输出 APK 文件的路径。

设置后,这运行于 subdir:

novcheck: true

不要通过查看构建输出来检查生成的 APK 的版本名和代码是否正确

  • 假设元数据是正确的 。这样的做法剥夺了有用级别的 sanity 检查, 应该只有在无法提取数值的情况下才这么做。

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

:这个特定构建的负面特征列表。它们在 AntiFeatures 中有描述。

AllowedAPKSigningKeys

当用 fdroid update 生成自动二进制存储库时,通常很容易找出所收集的 APK 的预期签名密钥。AllowedAPKSigningKeys 让仓库管理员设置预期的签名密钥,然后 fdroid update 将检查 APK 是否由这些密钥之一签署。如果不是,不匹配的 APK 将不被包含在存储库中。如果 fdroid update --delete-unknown 被指定,不匹配的 APK 将被删除。然后,可以使用一个自动程序将较新的 APK 下载到存储库中,只有当它们有一个已知的良好签名时才会被包含在内。该值是签名证书的 SHA-256 指纹的小写十六进制值。这可以用来自 Android SDK 的 apksigner获取:

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

或者用来自 Java 开发工具包(JDK) 的 keytool

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

APK 文件通常只使用一个签署者签名。 需要 多名签署者验证的 APK 当前不被 _AllowedAPKSigningKeys_所支持(这相当罕见)。

AntiFeatures

这是可选的 - 如果存在,它包含一个以英文逗号分隔的列表,列表由下列值中的任意值组成,描述应用具有的 负面特征。最好在描述中说明具有(一个或多个)负面特征的原因:

  • Ads - 该应用包含广告。
  • KnownVuln - 该应用有已知的安全漏洞。
  • NonFreeAdd- 该应用推广非自由附加组件,因此该应用实际上是其他非自由软件的广告。
  • NonFreeAssets - 应用包含并使用非自由资产。最常见情况是应用中使用了在限制商用或进行衍生创作的许可证下授权的艺术作品像是图片、声音、音乐等(比如,任何带 “Non-Commercial” (NC) 或 “No Derivatives” (ND) 限制的 Creative Commons 许可证)。
  • NonFreeDep - 应用依赖于非自由应用(例如 Spotify\Whatsapp)- 也就是说,这个应用要生效的前提是设备上已经安装了这些非自由应用,但该应用本身并不包含这些应用。
  • NonFreeNet - 此应用推广或完全依赖专有的网络服务。
  • NoSourceSince - 这个应用的上游源代码不再可用。要么是该应用已经商业化,要么是存储库被放弃,要么是它已经移到了一个我们目前不知道的地方。这通常意味着不会有进一步的更新,除非源代码重新出现。
  • NSFW - 应用包含用户可能不希望到处公开或可见的内容,来自网络术语“Not safe for work”。
  • TetheredNet - 此应用完全完全依赖不可能(或不易替换)的服务。替换需要对应用或服务进行修改。如果有一个简单的配置选项,允许将应用指向另一个备选的、公开可用的、可自托管的服务器解决方案,那么这个负面特征就不适用。
  • Tracking - 默认追踪用户或泄露活动数据。如果应用或某一功能在不收集和分享这些数据或向数据收集网络服务(不管该服务是否基于自由软件)发出请求的情况下就无法使用,则适用该负面特征。例如,基于活动的天气数据、地图、头像等的下载(数据托管和交付服务),或上传崩溃日志等。

在 XML 文件(index.xml) 中,该字段将被转换为 (<antifeatures>)。

Disabled

如果这个字段存在,该应用不会被放入公开索引。这允许在一个应用被暂时禁用时保留元数据。该值应该是对应用被禁用原因的描述。没有 APK 或源代码档案会被删除:要清除APK,请见_Builds_ 部分的disable,或者手动删除开发者版本。因此,这个字段是在一个应用已经过期的情况下使用的,因为源代码压缩包被保留。

RequiresRoot

如果应用需要 root 权限才能使用,请将此可选字段设置为 true。如果用户愿意,可以让客户端过滤掉它。无论是否需要 root 权限,最好在描述中给出一段可能要求 root 权限的条件及其原因。

在 XML 文件 (index.xml)中,该字段将被转换为 (<requirements>)。

ArchivePolicy(存档政策)

如果配置了一个归档存储库的话,这决定了将应用的旧版本转移到归档存储库的策略。配置设置了一个默认的在主存储库中保留的最大版本数,之后旧版本会被移到归档存储库中。这个特定于应用的策略设置可以覆盖它。

在决定将哪些版本放入存档时,通过 CurrentVersionCode指定的版本始终被视为最新版本。这意味着当_ArchivePolicy_ 设置为 1 时,只保留 CVC 对应的 APK,而不一定是版本号最高的那个。

n 是当前唯一受支持的格式, n是要保留的版本数。 默认值为 3。 对于有VercodeOperation列表的应用,默认计算方法为3 x 操作数。例如, 对于有两个操作的应用,对于两个 ABI,将保留 6 个版本。

AutoUpdateMode(自动更新模式)

这决定了在有新版本时自动生成新构建的方法 - 换句话说,在元数据中添加新的构建版本行。这与UpdateCheckMode功能共同进行 - 也就是说,当一个更新被检测到时,它也会被此功能处理。

有效模式是:

  • None - 自动更新被禁用。
  • Version - 已启用自动更新。

    UpdateCheckMode被设为Tags,那么这个应设为 Version,不带任何正则模式。 勾选的标签被直接使用。

    UpdateCheckMode 设为 HTTP, 那么应在 Version 之后添加一个模式。 该模式用来生成一个用于新构建块 commit:属性的值(标签名)。 它是简单的文本, 其中 %v%c 分别被替换成所需的版本名称和版本代码。 产生的字符串必须与应用存储库中的现有标签相匹配, 然后 F-Droid 将使用该标签来构建相应的版本。

    例如,如果一个应用总是有一个标签 2.7.2 对应于 2.7.2 版本, 你可以简单地指定 Version %v。 如果一个应用总是有一个标签 ver_1234 表示版本代码为 1234 的版本, 你可以指定 Version ver_%c

    此外,在这个阶段, 可以在版本名称中添加一个后缀, 以区分 F-Droid 的构建和原始版本。 继续上面的第一个例子,你可以将其指定为 Version +-fdroid %v, 其中 -fdroid是构建 APK 时将被附加 到比方说build.gradle中指定的versionName的后缀。

对于带 VercodeOperation列表的应用, 构建数等于列表中项目数。

UpdateCheckMode(更新检查模式)

这决定了用于确定何时有新版本 - 换句话说,由 fdroid checkupdates 进程更新元数据中CurrentVersionCurrentVersionCode字段。

有效模式是:

    • None - 不进行检查,因为没有恰当的自动检查方法。应该手动检查更新。使用这种方法的情形包括,部署不稳定或 patched 版本;当在不同于 AndroidManifest.xml 所在目录进行构建;如果开发者使用 Gradle 构建系统并在单独文件内存储版本信息;如果开发者未每个新发行都创建一个新分支且不打标签;或者你已更改了包名或版本代码逻辑。
    • Static - 不进行检查 - 要么开发已经停止或者新版本不令人满意。这一方法在没有其他检查方法可用且上游开发人员让我们随时了解新版本的情况下也被使用。
  • RepoManifest - 最新代码提交会在离眼下时间最短构建中发现_AndroidManifest.xml_ 和 build.gradle 文件的目录内寻找这两个文件。这种方法是否合适,取决于应用的开发者所使用的开发过程。你不应该指定这种方法除非你确定它是合适的。例如,有些开发者在开始开发时而不是在发布时提高版本。如果 _AndroidManifest.xml_被移到了不同的目录,或者包的名称发生了变化,它将返回一个错误。它给出的当前版本可能不准确,因为不是所有的版本都适合发布。因此,在构建之前,通常有必要检查当前版本是否已经被上游开发者发布在某个地方,可以通过检查他们发布的 APK 或者源代码存储库中的标签。

    目前,它在不同程度上适用于除了 srclib 存储库类型以外的每种存储库类型。 对于 gitgit-svnhg 存储库类型, 你可以用 RepoManifest/yourbranch 作为 UpdateCheckMode, 这样 “yourbranch” 就会被用来代替默认分支。 git 的默认值是 “master”,hg 的默认值是 “default”, git-svn 的默认值是 none(它保持在同一分支)。 另一方面,分支支持还没有在 bzrsvn 中实现, 但RepoManifest 仍然可以在没有它的情况下使用。

  • Tags - 检查源代码存储库中所有被标记的 revision 中的 AndroidManifest.xmlbuild.gradle 文件,寻找最高版本代码。这种方法是否合适,取决于应用的开发者所使用的开发过程。你不应该指定这种方法,除非你确定它是合适的。如果开发者喜欢标记不稳定的版本,或已知忘记标记发布版本,就不应该使用这种方法。像 RepoManifest 一样,如果_AndroidManifest.xml_ 被移动到另一个目录,它将不会返回正确的值。尽管有这些注意事项,它往往是最受欢迎的 UpdateCheckMode

    目前它只适用于 githgbzrgit-svn存储库。 在后者的情况下,存储库的 URL 必须包含通往trunktags的路径, 否则将找不到标签。

    要只检查匹配特定正则表达式的标签, 只需在末尾添加相应的正则模式即可, 不同模式间用空格隔开 。 这在应用标签为非发布版本(如 X.X-alpha)时非常有用, 你可以用 .*[0-9]$ 这样的正则表达式来筛掉不是以数字结尾的标签名。 示例:UpdateCheckMode: Tags .*[0-9]$

    可选地, 可以明确 UpdateCheckData来从你指定的存储库文件 而不是依靠默认值(在大多数情况下是 build.gradleAndroidManifest.xml)中 提取版本代码和名称。

  • HTTP - HTTP 请求被用来确定当前的版本代码和版本名称。这由 UpdateCheckData字段控制, 它的形式是 urlcode|excode|urlver|exver

    首先,如果 urlcode 不为空,则获取该 URL 中的文档, 并与正则表达式 excode 匹配, 以第一组作为版本代码。

    其次,如果 urlver 不是空的, 则获取该 URL 中的文档, 并与正则表达式 exver 进行匹配,其中第一组成为版本名。 urlver 字段可以简单设置为 ‘.’, 表示和版本代码使用同一文件而不是获取另一个。

VercodeOperation(版本代码操作)

对通过定义的 UpdateCheckMode获得的版本代码进行操作。%c 将被实际的版本代码替换,整个字符串将被传递给 python 的 eval 函数。

对于想为不同的 ABI 编译,但其版本代码并不总是有拖尾零的应用尤其有用。例如,通过多个 VercodeOperation ,我们能够跟踪更新,并为每个上游版本构建最多四个不同的版本,也即四种架构:

版本代码操作:
  - 100 * %c + 1
  - 100 * %c + 2
  - 100 * %c + 3
  - 100 * %c + 4

从上面复制了四个构建块并添加为一个更新,通过进行数学操作计算它们的版本码。

UpdateCheckIgnore(更新检查忽略)

当检查更新时(通过UpdateCheckMode),这可以用来指定一个正则表达式,如果与版本名称相匹配,将导致该版本被忽略。例如,可以指定 “beta” 以忽略包含该文本的版本名称。

只在 UpdateCheckModeHTTP 中可用。

UpdateCheckName

当检查更新时(通过 UpdateCheckMode),这可以用来指定要搜索的软件包名称。当应用有一个静态的包名但在某些 flavor 中以编程方式改变它,例如在包名的末尾加上 “.open” 或 “.free” 时很有用。

你也可以使用 Ignore 来忽略包名搜索。这只应在某些特殊情况下使用,例如,应用的 build.gradle 文件不包含包名。

UpdateCheckData(更新检查数据)

UpdateCheckModeTagsHTTP 一起使用。

UpdateCheckData: <vercode-location>|<RegEx-for-versionCode>|<versionName-location>|<RegEx-for-versionName>
  • 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.
  • 此刻不支持正则表达式管道运算符。

UpdateCheckMode: Tags示例:

  • 在存储库根目录中含 pubspec.yaml的 Flutter 应用: pubspec.yaml|version:\s.+\+(\d+)|.|version:\s(.+)\+
  • 将 git 标签用作版本名:app/build.gradle|versionCode\s(\d+)||
  • 可选地,可以指定从标签中提取版本名的正则表达式:app/build.gradle|versionCode\s(\d+)||Android-([\d.]+)
  • 如果未指定版本码文件,码和名称可以从 tag: '|\+(\d+)||Android-([\d.]+)' 中提取
  • 注意:如果你留空 vercode-location确保在整个值前后使用 引号:UpdateCheckData: '|\+(\d+)||Android-([\d.]+)'

UpdateCheckMode: HTTP示例:

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

CurrentVersion(当前版本)

推荐的版本的名称。应用可能会有更新的版本(例如不稳定的版本),而且几乎肯定会有更老的版本。这应该是被推荐用于一般用途的版本。如果当前版本没有源代码,或者使用的是非自由库,那么最好是仍然自由的最新版本,尽管保留自动更新检查可能仍是权宜之计

这个字段通常是自动更新的 - 见 UpdateCheckMode

在 XML 文件 (index.xml) 中,该字段将被转换为 (<marketversion>)。

CurrentVersion(当前版本代码)

CurrentVersion 字段相对应的版本代码。这两个字段都必须是正确和匹配的,尽管只有当前版本代码被 Android 用来确定版本顺序以及被 F-Droid 客户端用来确定应该推荐哪个版本。

这个字段通常是自动更新的 - 见 UpdateCheckMode

如果未设置,客户端将推荐它们能推荐的最高版本,如同 CurrentVersionCode 是无限的。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<marketversion>)。

NoSourceSince

如果我们缺少上游报告的 CurrentVersion的源代码,或者非自由元素已经被引入,这里定义了开始缺少源代码的第一个版本。这里不考虑那些只缺少一个或几个版本的源代码,但提供较新版本的源代码的应用

  • 这个字段旨在说明哪些应用目前没有分发源代码,以及它们从什么时候开始这样做。

已废弃或删除的字段

Provides

此应用提供的应用的 ID 的逗号分隔列表。这个字段只是一个存根,从未用于任何事情。 index-v1.json 和 _ .yml_ 元数据文件中从未支持过它。

在 XML 文件 (index.xml) 中,该字段将被转换为 (<provides>)。