开源 Android 应用开发者的 F-Droid 上架最佳实践

上架前清单

提交 RFP 前，逐条检查：

代码层面

• [ ] 源码托管在 GitLab 或 GitHub（其他平台也可以，但这两个最好）
• [ ] 有明确的 LICENSE 文件（放在项目根目录）
• [ ] 许可证是 FSF/OSI 认可的开源许可证（GPL、Apache、MIT、BSD 等）
• [ ] Gradle/Maven 构建配置中版本号用代码声明（不是硬编码在 APK 里）
• [ ] Release 版本可以用一行命令从源码构建（./gradlew assembleRelease 成功）
• [ ] 没有硬编码的构建时间戳或随机数（为了可重现构建）
• [ ] 不依赖闭源 SDK 或非公开服务

发布层面

• [ ] 每个版本有明确的 release tag（如 v1.0.0）
• [ ] 每个 release tag 附带 changelog
• [ ] Release tag 和 commit hash 一一对应
• [ ] 源码仓库能稳定访问（不是私有仓库或频繁变更地址）

文档层面

• [ ] 有简明的 README.md 介绍应用
• [ ] 有应用 logo/icon（至少一个 512x512 的 PNG）
• [ ] 有截图（至少 3 张不同界面）
• [ ] 有问题跟踪入口（GitHub Issues 或 GitLab Issues）

本地验证层面

• [ ] fdroidserver fdroid import 能成功导入
• [ ] fdroidserver fdroid build 能成功构建
• [ ] 生成的 APK 能在 Android 设备上正常安装和运行

加速 Review 的技巧

自己写元数据

最有效的加速手段。维护者平均处理一个新 RFP 可能需要几周到几个月，但如果你自己写好元数据并通过 MR 提交，review 通常在几天到一两周内完成。

提供清晰的 RFP

好的 RFP issue 应该包含：

### App name: My App
### Source: https://github.com/yourname/myapp
### License: GPL-3.0-only
### APK: https://github.com/yourname/myapp/releases/tag/v1.0.0
### Why FOSS? 项目从一开始就是 GPL v3 许可，没有任何闭源组件。
### Why useful? 这个应用解决了什么问题。
### Build instructions: 在项目根目录运行 `./gradlew assembleRelease`

在 MR 中提供构建日志

如果本地 fdroid build 成功，把构建日志的关键输出粘贴到 MR 描述中。维护者可以快速判断构建环境是否正确。

及时回复维护者的问题

维护者可能在 MR 中问一些问题（构建失败、许可证细节、字段含义等）。如果几天后还没回复，MR 会被标记为 stale。

上架后的维护

更新元数据

当你发布新版本时，有两种方式更新元数据：

方式一：AutoUpdateMode（推荐）

设置元数据中的：

AutoUpdateMode: Version
UpdateCheckMode: Tags

F-Droid 会自动检测新的 release tag 并更新元数据。

方式二：手动提交 MR

每次发新版后手动 fork fdroiddata、更新 YAML、提交 MR。适合版本号结构复杂的情况。

保持构建可重现

每次发版后，确认：

• commit hash 精确锁定
• 本地 fdroid build 仍然成功
• 没有引入新的非自由依赖

响应反特性标注

如果 F-Droid 给你的应用标注了反特性（如「非自由网络服务」），有两种态度：

• 接受 — 如果你认为这个反特性是合理的（比如 NewPipe 解析 YouTube 专有 API），可以在 issue 中说明，维护者会根据情况保留或修改标注
• 修复 — 如果可以去掉闭源依赖，修复后维护者会移除反特性标注

维护者沟通渠道

• GitLab Issues — 技术问题、构建失败反馈
• forum.f-droid.org — 社区讨论
• IRC #fdroid on OFTC — 实时聊天（需要能访问 OFTC）
• team@f-droid.org — 邮件联系

不推荐的做法