Question

本页记录了如何将新应用收录到 F-Droid 主存储库，包含了提交者应注意的技术细节信息。

应用收录提议

要提议将新应用收录到主 F-Droid 存储库中，你可以将此应用的相关信息发布到提交队列中。更高级的替代方法是自己编写一个完整的元数据文件，测试并直接向 fdroiddata Git 存储库提出收录（合并请求），这样可以加快收录进程。下面将详细描述这两种方式。

注意，即使你不是所提议的应用本身的开发者或维护者，也可以提议收录。关于这部分的政策，请参见收录政策和版本库风格指南。

将提案发布到提交队列

这是收录应用的最简单方法。但是由于每个应用都需要大量的审阅工作，这也是最慢的方法。

为此，请在 GitLab 上的 F-Droid 提交队列 中创建新 ticket，添加最小问题模板所需的所有详细信息；并等待 F-Droid 团队的人员审核应用，并为你执行所有必要的步骤。

元数据合并请求的提案

将应用收录进 F-Droid 存储库的一个更高级的替代方法是自己为应用编写一个 F-Droid 元数据文件，并在 F-Droid 应用程序元数据存储库（fdroiddata GitLab 代码库) 提交一个 git 合并请求来提议收录。这将加快应用收录速度，因为已经可用的元数据文件将减轻审阅者检查你提议的元数据的负担；由提交者来负责提供正确的元数据文件。

当以这种方式提议收录时，假设：

• 你对 自由软件 的含义以及 F-Droid 的用途非常了解。
• 你已经阅读并理解 收录政策。
• 你已经阅读并理解了 版本库风格指南。
• 你已经阅读并理解了 F-Droid 文档的相关部分。
• 你知道如何使用 Git VCS，并了解合并请求（在 GitHub 术语中也称为“拉取请求”）的一般工作原理。
• 你在 GitLab 上有一个帐户。
• 你有 F-Droid 服务器软件的本地实例，并且你知道自己在做什么。

F-Droid 应用元数据存储库 上写了建议以这种方式包含的建议步骤。

应用审核流程

提交包含提案后，应用将进入审核流程，F-Droid 工作人员将查看应用的源代码并确定它是否适合收录（如果不是，则确定所有必要的步骤）。

由于 F-Droid 是一个向用户承诺免费软件的软件存储库，审查过程是为了确保从 F-Droid 主存储库分发的所有应用都是免费软件。

这是一个非详尽的列表，列出了审核者会做什么：

• 他们将转到你的源代码存储库，并在许可文件（包括 README）中查找版权声明，以检查提议的应用是基于 公认的自由软件许可 发布。
• 他们会查看你的构建脚本，以了解你使用的构建系统，以及 F-Droid 构建服务器是否可以处理它（Ant 和 Gradle 是最常见和最简单的）。
• 他们将尝试下载你的源代码的副本。
• 他们会查看所有的源代码文件，以验证其许可证是否与相应的许可证/README文件一致。
• 他们将检查应用是否使用任何预编译的库或二进制 blob。
• 它们会查看你的非源代码文件来识别用于你的应用中的非自由资源.
• 他们将浏览源代码，以查看你的应用是否使用非自由依赖项、显示广告、跟踪用户、推广或依赖非自由服务/应用程序，或执行任何对用户有害或不受欢迎的操作。
• 他们将列出你的应用中所有 负面特征 的摘要。
• 他们将尝试修补你的应用，以移除对第三方私有软件（若有）的使用。
• 他们将尝试为你的应用确定一个合适的更新过程（例如，通过查看你的版本与 VCS 标签和/或 AndroidManifest.xml 中的版本信息的关系）。
• 他们将尝试为你的应用编写合适的元数据文件，并将其添加到本地 F-Droid 构建服务器实例。 （fdroid rewritemeta, fdroid lint 用于确保元数据格式良好）
• 他们将尝试在隔离的环境中构建你的应用，以查看该过程是否成功并产生功能正常的 APK。
• 如果一切顺利，他们将向本地 fdroiddata git 存储库添加一个新的元数据文件，并将更改同步到 GitLab。

如果申请没有通过审核的某些步骤，将在发布提案的原始提交队列主题中给出反馈。

一旦 fdroiddata 存储库在 GitLab 上更新，F-Droid 的官方构建服务器将在主 F-Droid 存储库上 fetch、构建和发布你的应用通常只是时间问题。

你可以通过查看 GitLab fdroiddata 修订历史 来确认包含你的应用。

元数据合并请求的特殊注意事项

如果是来自 GitLab 的合并请求，审查过程理论上是一样的。他们主要是为了确认提议的元数据与应用的源代码中的内容是一致的。有关编写和提交元数据的步骤被省略了，因为他们会使用你提议的原始元数据文件。 反馈将在提出该应用的原始合并请求中给出；一旦该过程完成，该请求将被合并到 fdroiddata GitLab 存储库的 master 分支。

为了优化流程，当你提议通过元数据合并请求包含时，F-Droid 工作人员依赖于几个假设（上面概述）。因此，审查过程在几个方面的强度会大大降低，并且消耗的时间也会少得多。以这种方式偷偷摸摸的违反政策的应用将在事后得到处理。

可重复构建

要在 F-Droid 上发布应用，可重复构建不是必需条件。但我们的确认使用可重复构建是最佳实践。不幸的是，因为 Android 不允许签名密钥不同的更新，切换到可重复构建不是那么容易。这意味着切换后用户必须重新安装应用。因此，我们主要鼓励新应用使用可重复构建。

可重复构建的好处是开发者的签名（来自所发布的 APK）确保我们的构建和开发者的相同（因而不包含任何不应包含的东西），与此同时我们的构建服务器验证开发者的构建与所发布的源代码相匹配（因此同样不包含任何不应包含的东西）。

这么做可增加信任度并加大供应链攻击难度。此外，也确保不会有只存在于 F-Droid 版本的故障（反过来也一样）。 使用开发者密钥还意味着开发者在我们出于某些原因（暂时）无法向用户提供更新时可选择自行向用户提供更新。

可重复构建对于某些应用，尤其是那些没有原生代码，仅使用 Kotlin/Java 语言的应用，非常容易。其他应用可能需要更多努力才能做到。令人难过的是，某些应用根本无法实现可重复构建。

我们希望开发者认同我们的观点，即鉴于各种好处，至少值得试着让应用变得可重复，但要是开发者无法或不愿意在这上面花时间/精力，我们当然尊重开发者的决定。

更多信息，请参阅：

• 向着可重复的 F-Droid 前进
• F-Droid 的可重复构建文档
• 可重复构建项目
• HOWTO: diff & fix APKs for Reproducible Builds

构建过程

将应用的元数据添加到 fdroiddata GitLab 存储库后，下一步是让主 F-Droid 构建服务器获取应用源代码和相关组件，构建应用，并将其发布到主 F-Droid 存储库上。

这个构建过程 每天 完成，应用是批量处理的。由于步骤是在幕后完成的，而且大多是自动的；提交者需要做的就是等待它完成。

一则某个应用成功构建过程的记录可以在该特定应用的 F-Droid 网站页面上找到 (如 查看 F-Droid 客户端的构建日志）。

你可在 F-Droid Monitor - Running 页面查看本周期构建失败的应用的日志, 上一周期构建失败的应用的日志可在 Build 页面上找到。 这有助于在构建意外失败时帮助诊断问题。

元数据刷新过程

当预定的构建时间到达时，F-Droid 构建服务器将从 fdroiddata GitLab 代码库中获取更改并将其合并到本地代码库。然后，将对所有应用执行更新检查。如果发现新版本，其元数据文件将由作者 F-Droid Builder <admin@f-droid.org> 更新并提交到存储库。

元数据文件更新后，F-Droid 服务器将根据已发布的 APK 列表检查它们，以构建需要构建的新应用和/或版本列表。然后它将进入应用预处理过程，然后是每个应用的构建过程。

应用预处理

应用构建过程

APK 签名流程

存储库发布过程

预期的情况

当你的应用元数据被批准并接受到 GitLab 上的 fdroiddata git 存储库时，它不会立即出现在主 F-Droid 存储库。

如果你的应用没有任何构建问题，那么从 fdroiddata 合并到应用出现在主存储库中，大约需要 24 到 48 小时。1 这个时间限制是由于构建过程的 APK 签名部分，这需要人为干预密钥库访问步骤。 2

尽管如此，你的应用还不会出现在 f-droid.org 的最新应用列表中，即使人们现在已经可以搜索和下载它：一旦应用出现在 F-Droid 主存储库中，它需要一天的时间才能出现在最新应用列表。

外部链接

• GitLab上的F-Droid应用提交队列 (用于新的提交)
• 论坛上的 F-Droid 应用提交队列 (用于跟进旧的提交)
• fdroiddata GitLab 存储库
• fdroiddata 修订历史