Safe Haven 重复版本与 APK 哈希，三种自动拒绝规则
Safe Haven 的三个去重关卡
一个 APK 进入 Safe Haven 扫描管线后，会按顺序过三个去重检查。任何一个触发，直接进 rejected 状态：
| 关卡 | 检查什么 | 触发后果 |
|---|---|---|
| SHA-256 重复 | 这个 APK 的哈希和数据库里已有的某个 live 版本完全一样 | 拒绝 |
| versionCode 重复 | APK manifest 里的 versionCode 和同包名下某个 live 版本的 versionCode 相同 | 拒绝 |
| 包名不匹配 | APK manifest 里的包名和应用条目记录的包名不一样 | 拒绝 |
这三个关卡是 Safe Haven 最基础的去重逻辑，机器可判定、不需要人工介入。
SHA-256 重复是什么意思
你上传了一个 APK，扫描管线算它的 SHA-256，发现数据库里同一个包名下已经有某个 live 版本的 SHA-256 完全相同 → 直接拒绝。
SHA-256 是"碰撞概率可以忽略"的强哈希——两个不同 APK 文件产生相同 SHA-256 的概率接近零。所以这个检查几乎 100% 准确。
可能误触发的场景：
- 你以为自己做了新版本，但实际只是重新打包了一遍（加了签名证书、没改内容）→ APK 字节序列完全相同 → SHA-256 一样 → 被拒
- 同步管线拉到的上游 APK 和 Safe Haven 已经收的版本一样 → 自动跳过，不进公开目录
versionCode 重复是什么意思
从 APK manifest 里真实提取 versionCode（安卓内部版本号，整数），和数据库里同包名下所有 live 版本的 versionCode 做比对。有一样的 → 拒绝。
这个检查只比 versionCode（整数），不比 versionName（字符串）。所以：
- v2.0.0 → versionCode 40
- v2.0.1 → versionCode 41 ✅
- v2.0.1（开发者忘了改 versionCode，还是 40）→ versionCode 40 → 重复 → 被拒
manifest reconciliation：扫描管线会自动用 manifest 里提取的 versionCode 覆盖开发者可能填错的值。但如果覆盖后发现和已有版本撞了 → 还是被拒。
包名不匹配是什么意思
从 APK manifest 里提取真实包名，和应用条目记录的包名比对。不一样 → 拒绝。
这个检查防的是：
- 开发者选错应用条目上传（把 A 的 APK 传到了 B 的条目下）
- 社区投稿的临时占位符没被正确替换（这种情况扫描管线会自动替换，不会触发拒绝）
三种重复的实际含义
开发者遇到 rejected 状态时，Safe Haven 会记录触发了哪个规则：
| 触发规则 | 含义 | 修正方法 |
|---|---|---|
| APK SHA-256 重复 | 你上传的 APK 和已有版本一模一样 | 不要重复上传，确实有新版本就换一个 APK |
| versionCode 重复 | 新版本和已有版本的内部版本号一样 | 改 manifest 里的 versionCode 再重新构建 |
| 包名不匹配 | APK 和条目不是同一个应用 | 检查你是不是传错了条目 |
retired 状态：live 之后的淘汰
除了 pending_upload → pending_scan → scanning → pending_review → live 的正向路径，还有一个 live → retired 的回退路径。触发条件通常在复扫管线里：
- 复扫时发现 APK SHA-256 和另一个 live 版本完全相同（和扫描管线的拒绝逻辑类似，但触发时机在已上架后）
- 复扫时发现 manifest versionCode 比已有的 live 版本还低（过时版本）
retired 不是删除——数据库记录还在，只是从全局索引里移除。客户端下次同步时会删除对应的版本记录。
版本记录里怎么区分重复
进入公开目录的应用，在详情页的版本历史区能看到：
- 每个版本的 versionName / versionCode
- 每个版本的 APK SHA-256
- 扫描时间
如果你注意到"两个版本的 SHA-256 一样"，说明那个重复版本被 retired 处理掉了——你可能只看到一个（不是两个），因为版本记录里只保留不重复的版本。
为什么要三重去重
三个关卡各有侧重：
- SHA-256 检查：最严格、最准确（文件级别的唯一性）
- versionCode 检查：安卓系统语义（安卓内部用来排版本先后的标准）
- 包名检查：最基本的身份确认（确保你上传到对的条目）
任何一个能过但另一个通不过的场景都是有意义的边界情况，三个一起查是最保险的做法。