Safe Haven 中文文档 下载 App

认领 Safe Haven 里社区跟踪的应用，F-Droid 来源要额外提供签名

什么是"社区跟踪的应用"

Safe Haven 目录里的应用条目，来源有三种，其中两种是非开发者自己提交的：

这些条目都可以被原始开发者认领——认领后，条目的 trustLevel 会变成 verified_source，后续的自动同步会从开发者自己的仓库拉，不再从 F-Droid / Izzy 同步。

认领 vs 新注册

如果你的应用已经在 Safe Haven 目录里了（不管来源是什么），不要重复创建一个新条目——会导致同包名条目冲突。应该走认领流程。

认领流程和新注册应用的前两步几乎一样：都需要 .safehaven 文件握手验证。区别在于：

普通来源的认领流程

适用于社区贡献、自动发现、IzzyOnDroid 来源的应用：

第一步：找到你的应用条目

打开 store.colourswift.com 的 Web 前端，搜你的应用包名或显示名。找到后点进去，确认：

第二步：做 .safehaven 验证握手

和新注册一样，在你的源码仓库根目录放 .safehaven 文件，文件内容是 Safe Haven 给你的唯一仓库验证 token。

但这个 token 从哪来？ 在 store.colourswift.com 的开发者后台，应该有一个"认领应用"入口——输入你的应用包名，Safe Haven 生成认领用的 token。或者在应用详情页如果有"Claim this app"按钮，点它也会生成 token。

第三步：等 Safe Haven 后台抓取

后台会定期（几小时内）去抓 .safehaven 文件。比对 token 成功 → 认领完成，条目的 trustLevel 更新，自动同步切换到你自己的仓库。

F-Droid 来源的认领（特殊）

F-Droid 同步进来的 APK 有一个特殊情况：它是用 F-Droid 的签名密钥重打包的，不是开发者原生签名。

所以认领 F-Droid 来源的应用，除了 .safehaven 验证握手，还有一个额外要求：你必须提供新的签名密钥哈希（你自己的签名密钥 SHA-256）。

认领成功后 Safe Haven 会：

  1. 清除所有旧的 F-Droid 来源的提交记录和版本条目
  2. 移除 F-Droid upstream 标记
  3. 存入你新提供的签名哈希作为签名锁定基准
  4. 后续自动同步改为从你的源码仓库拉，用你的原生签名而不是 F-Droid 的

为什么要换签名

因为如果你认领后还是用 F-Droid 签名的 APK，那用户从 Safe Haven 装的版本签名和你自己从 GitHub Release 发布的版本签名不同——又会回到混装签名冲突的问题。认领的意义就是"把这个条目切成我自己的发布渠道"。

认领失败的可能原因

.safehaven 文件没被抓到

可能原因：

Safe Haven 后台用 GitHub raw.githubusercontent.com 平台的 main 分支路径去抓 .safehaven 文件，格式为 raw.githubusercontent.com/仓库 owner/仓库名称/main/.safehaven。你可以自己在浏览器里按这个格式拼出完整 URL 访问，看看能不能正确下载到文件。

包名对不上

你认领时输入的包名和 Safe Haven 条目里记录的包名必须完全一致（安卓包名是大小写敏感的）。如果社区贡献时用了临时占位符（{owner}-{repo} 格式），扫描管线应该已经替换成真实包名了——但如果没替换成功，你需要手动联系 Safe Haven 管理员修正。

已经被其他人认领了

如果另一个开发者先于你认领了同一个包名的条目，你再认领会失败——系统认为第一个验证成功的就是合法所有者。这种情况需要 Safe Haven 管理员介入仲裁。

认领后需要做什么

认领成功不代表结束，你还需要：

  1. 检查条目元数据：描述、截图、分类等是不是你想要的，不满意就在开发者后台编辑
  2. 开启自动提交：让 Poller 每 6 小时检查你的仓库 Release，自动拉新版本
  3. 提交你的第一个原生签名版本：如果之前只有 F-Droid 版本，提交一个你自己签名的版本，签名锁定会以你的哈希为准
  4. 检查版本历史：旧的 F-Droid 版本记录可能需要手动清理（管理员操作）

认领成功后的效果