提交应用到 F-Droid:从 RFP 到构建发布的完整流程
前置条件
要上架 F-Droid,你的应用必须:
- 是自由开源软件(FOSS) — 使用 FSF/OSI 认可的开源许可证(GPL、Apache、MIT 等)
- 公开源码 — 托管在 GitLab/GitHub 等公开仓库
- 能在干净环境中编译 — 构建过程不依赖非公开的服务或闭源组件
- 满足反特性透明要求 — 如果有广告/追踪/非自由依赖等,能接受被标注
流程概览
准备应用 → 提交 RFP → 编写元数据 → 本地构建测试 → 提交 MR → 维护者 review → 合并 → 官方构建 → 发布
第一步:本地准备
确保你的应用:
- 源码公开到 GitLab/GitHub
- 打了明确的 release tag(如 v1.0.0)
- 有可重复的构建方式(
./gradlew assembleRelease能成功) - 知道
AndroidManifest.xml和build.gradle在哪个子目录
第二步:本地安装 fdroidserver 并测试构建
# 快速用 Docker 跑
docker run -it -v $(pwd):/repo registry.gitlab.com/fdroid/fdroidserver:latest bash
# 在容器里
cd /repo
fdroid import --url https://github.com/yourname/yourapp
fdroid build yourapp
如果本地构建失败,官方构建一定也失败。先修好再往下走。
第三步:提交 RFP(Request for Packaging)
在 F-Droid GitLab 上提交一个新 issue:
- 打开
gitlab.com/fdroid/fdroiddata/-/issues - 点击「New issue」
- 选择「New Application Proposal(RFP)」模板
- 填写信息:
### App name:
### Source: (GitLab/GitHub URL)
### License: (SPDX ID, e.g. GPL-3.0-only)
### Why is this app free software?
### Link to the App's documentation and/or website:
### APK (optional - link to an apk from the source's releases page)
第四步:两种元数据编写方式
方式 A:你自己写(推荐,更快)
- Fork
gitlab.com/fdroid/fdroiddata - 在
metadata/目录下创建 YAML 文件(文件名 = 应用包名) - 填写完整元数据(参考上一篇 fdroiddata 详解)
- 本地运行
fdroid lint yourapp检查 - 本地运行
fdroid build yourapp验证构建 - Push 你的 fork
- 提交 Merge Request 到 fdroiddata
这种方式最快——维护者只需要 review 和合并。
方式 B:维护者帮你写(慢)
提交 RFP 后等维护者手动编写元数据。维护者工作量有限,可能要等几周甚至几个月。
第五步:Merge Request Review
提交 MR 后,维护者会检查:
- 元数据 YAML 是否合规(
fdroid lint通过) - commit hash 是否精确锁定
- 构建是否能通过(fdroidserver 会自动在 CI 中构建)
- 许可证是否合规
- 应用是否真的能编译成功
CI 构建失败 → 维护者会在 MR 中评论问题原因。修复后重新 push 即可。
第六步:合并与发布
MR 被合并到 fdroiddata 后:
- F-Droid 构建服务器拉取最新的 fdroiddata
- 批量构建所有新增/更新的应用
- 签名、生成仓库索引
- 推送到 f-droid.org/repo
- F-Droid 客户端下一次同步时就会看到你的应用
从 MR 合并到正式发布通常需要几天时间(构建服务器排队处理)。
常见被拒绝的原因
| 原因 | 解决 |
|---|---|
| 许可证不明确 | 在项目根目录放 LICENSE 文件,并在元数据中正确标注 SPDX ID |
| 构建依赖非公开服务 | 确保构建过程不需要网络下载闭源组件 |
| 有非 FOSS 代码 | 移除闭源依赖,或隔离到可选模块 |
| 应用功能过简单 | 确保有实际功能,不是 hello world 级项目 |
| 维护者太少 | 等维护者处理,或自己写元数据加快速度 |
加速 RFP 的建议
- 自己写元数据 — 方式 A 比方式 B 快很多
- 本地先验证 — fdroid build 本地过了再提交 MR
- 提供 APK 链接 — 在 RFP 中附上 release 页面的 APK 下载链接
- 关注 GitLab issue — 维护者可能会问问题,及时回复
- 清晰的 release tag — commit hash 和 release tag 对应
后续维护
你的应用上架后:
- 发布新版本时,更新 fdroiddata 中的元数据(或开启 AutoUpdateMode)
- F-Droid 会自动跟踪新版本
- 如果不再维护,通知 F-Droid 归档你的应用