Safe Haven 中文文档 下载 App

Safe Haven 从 F-Droid 和 IzzyOnDroid 同步应用的完整流程

两个上游仓库的区别

F-Droid:最老最大的自由软件应用商店,要求应用必须是自由/开源软件,构建过程可复现,APK 由 F-Droid 重签名(用 F-Droid 自己的密钥)。

IzzyOnDroid:较新但增长很快的开源应用商店,收录开发者原生签名的 APK,强调可复现构建验证(Rebuild-Verified)。

Safe Haven 同时同步这两个仓库的索引,但进自己目录前全部重新过扫描管线。

同步规则(两个仓库共用一套)

Safe Haven 对同步进来的应用有硬过滤条件:

活跃窗口

只收近 12 个月内有更新的项目。超过一年没更新的应用,即使还在上游仓库里,Safe Haven 也不会同步进来。

这个过滤的理由是:旧应用更新频率低、维护活跃度可能存疑,而且开发者验证过期的概率也高。Safe Haven 更愿意把扫描资源花在活跃项目上。

ABI 优先级

arm64-v8a > armeabi-v7a。x86 / x86_64 构建整体排除。

意味着:

体积上限

单 APK 最大 100 MB。超过就跳过。

冲突检测

如果某个包名已经有开发者自己提交的版本在 Safe Haven 目录里了,同步进来的 F-Droid / Izzy 版本会被跳过——开发者自己的提交优先。

同步是怎么跑的

Safe Haven 后台有一个 Unified Upstream Poller(统一上游轮询器),每 6 小时跑一轮:

这个调度设计的目的是不因为单个来源卡顿而阻塞其他来源——200 个并行处理,5 分钟超时,超时了就换下一批。

同步进来之后发生什么

F-Droid / Izzy 的 APK 不是直接进公开目录,而是走完整的 Safe Haven 管线:

上游索引 → 匹配过滤条件 → 下载 APK → 入库 pending_upload →
→ 上传到 staging 存储(临时目录)→ 进扫描队列(pending_scan)→
→ safehaven-scanner 跑完整管线 → pending_review(自动通过)→
→ 复制到 production 存储(apps/{包名}/{versionCode}/)→
→ 更新全局索引 → 出现在公开目录里

整个过程大约耗时:下载(取决于 APK 大小和网络)+ 扫描(秒级)+ 入库(秒级)。

上游标记

同步进来的条目会打上 upstream 字段标记来源:

客户端的搜索页可以按 upstream 字段过滤。

为什么要重扫

直接同步进来不重扫是最简单的做法,但 Safe Haven 选择自己重扫一遍,原因有三:

  1. 签名锁定:Safe Haven 要建立自己的签名基准(F-Droid 同步来的包签名是 F-Droid 的,不是开发者的)
  2. 元数据验证:manifest 里的 versionCode、包名要和索引声明的一致
  3. 统一扫描标准:不管从哪来的 APK,统一过 VX-TITANIUM 引擎和本地威胁库

同步会漏哪些

同步不是 100% 覆盖上游仓库,以下情况会漏掉:

和 Aurora Droid / FoxyDroid 的关系

Aurora Droid 和 FoxyDroid 是F-Droid 客户端的替代品——本质上还是用 F-Droid 的仓库索引,只是换了一个安卓界面。Safe Haven 不一样——它是独立的应用商店,有自己的后端、扫描管线、索引格式,从多个上游同步后重新扫描。

这意味着:Safe Haven 里有的应用 Aurora Droid 里可能没有(因为 12 个月过滤、100MB 上限、签名不同);Aurora Droid 里有的应用 Safe Haven 里也可能没有(因为 Safe Haven 有自己的扫描标准和来源过滤)。