收录指南

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

应用收录提议

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

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

准备和合规检查

提议将应用上架 F-Droid 前，应仔细检查是否符合上架政策 and 存储库风格指南。这里有一份简短的清单。

应用应当有公开的源代码存储库和 FOSS 许可证文件。请确认存储库中有真实的最新源代码，而非无意义的某些虚设文件。
应用应当只有 FOSS 依赖。Firebase 和 GMS 是不被接受的非 FOSS 库的一些显著例子。如果没有这些非自由库应用能够（部分）工作，请创建没有这些库的版本。构建工具也应当是 FOSS 的。如果需要专有的 IDE，那么这样的应用无法上架。F-Droid 从命令行工具构建，构建教程帮助贡献者 3.已经通知了应用作者（且作者不反对上架）。如你并非作者请在应用的代码存储库那里新开 Issue，请求作者的许可。
描述的元数据文件被添加到存储库中。这是个简单的结构，有一些文本文件和图片，在上架前应始终先添加它们。虽然文件夹结构遵循 Fastlane/Triple-T，但无需实际加工处理。

满足这些条件后，此应用就准备好上架了。

将提案发布到提交队列

这是让应用上架的最简单方法。请注意完成这些只是让应用作为候选出现在我们的视野中。取决于贡献者的兴趣，离真正上架可能还有相当长的时间。

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

元数据合并请求的提案

将应用收录进 F-Droid 存储库的一个更高级的替代方法是自己为应用编写一个 F-Droid 元数据文件，并在 F-Droid 应用元数据存储库（fdroiddata GitLab 代码库) 提交一个 git 合并请求来提议收录。这将加快应用收录速度，因为已经可用的元数据文件将减轻审阅者检查你提议的元数据的负担；由提交者来负责提供正确的元数据文件。你可以用 fdroid import 和模板准备构建元数据。_fdroiddata_中的其他元数据也是不错的参考。

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

你对自由软件的含义以及 F-Droid 的用途非常了解。
你已经阅读并理解收录政策。
你已经阅读并理解了版本库风格指南。
你已经阅读并理解了 F-Droid 文档的相关部分。
你知道如何使用 Git VCS，并了解合并请求（在 GitHub 术语中也称为“拉取请求”）的一般工作原理。
你在 GitLab 上有账户 (注意：: F-Droid CI runners 在 Gitlab 的 FOSS 项目中，因此你无需为任何 CI 时间支付费用。如果 Gitlab 开始询问手机号或信用卡号，请不要提交任何信息，只需在合并请求中留下附注，这样我们就知道需要触发 CI 了)
你有 F-Droid 服务器软件的本地实例，并且你知道自己在做什么。

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

应用审核流程

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

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

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

他们将转到你的源代码存储库，并在许可文件（包括 README）中查找版权声明，以检查提议的应用是基于公认的自由软件和/或 OIS 许可证发布的。
他们会查看你的构建脚本，以了解你使用的构建系统，以及 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、构建和发布你的应用通常只是时间问题。

You can confirm the inclusion of your application by looking at the GitLab fdroiddata revision history.

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

In case the inclusion is from a GitLab merge request, the review process is theoretically the same. They are done mostly to confirm that the proposed metadata is consistent with what is really in the application source code. Steps about writing and committing metadata are omitted, as they will use the original metadata file you proposed. Feedback will be given on the original merge request thread that the application was proposed; and once the process is completed, the request will be merged to the master branch of the fdroiddata GitLab repository.

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

可重复构建

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

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

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

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

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

更多信息，请参阅：

构建过程

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

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

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

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

元数据刷新过程

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

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

应用预处理

应用构建过程

APK 签名流程

存储库发布过程

预期的情况

When your application metadata is approved and accepted into the fdroiddata git repository on GitLab, it won’t immediately appear in the main F-Droid repository.

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

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