Google 似乎正在改变 Pixel 内核与驱动源码的交付方式：过去，开发者可以通过 AOSP 相关 Git 仓库和 tags 获取对应版本；现在，GrapheneOS 团队称，相关源码不再以 Git tags 的形式推送，而是需要提交表单、等待数周，之后通过 Google Drive 获得代码。
这不是一个普通的下载入口调整。对依赖公开、可自动化源码流程的第三方 ROM 来说，源码何时到手、内容是否完整、版本是否可追溯，都会直接影响系统发布和安全补丁节奏。
变化的核心：从可追踪仓库变成审批式交付
Git tags 的价值不只是“方便下载”。它通常同时提供了几个工程能力：
- 版本有明确的提交和 tag，可以复现某个构建输入。
- CI 可以自动拉取源码、检查差异并触发构建。
- 开发者可以比较相邻版本，定位内核和驱动变化。
- 社区能够独立镜像、审计和验证公开内容。
如果流程变成“填表后等待，再接收一个云盘链接”，这些能力就会变得不稳定。等待时间会进入发布流水线，云盘文件也需要额外的校验、归档和权限管理。更重要的是，第三方 ROM 无法仅凭一个公开 Git tag 判断源码是否已经完整发布。
需要注意的是，现有信息主要来自 GrapheneOS 团队的公开说法。具体哪些 Pixel 型号、Android 分支、驱动包或内核组件受到影响，仍应以 Google 的正式说明和实际交付内容为准。
为什么第三方 ROM 会直接受到影响
像 GrapheneOS 这样的 AOSP 衍生系统，需要同时处理通用 Android 代码、设备专属内核、厂商驱动和安全补丁。设备专属部分晚到，影响的不只是编译时间：
- 发布节奏变得不可预测。 Android 月度更新或 Pixel 固件更新发布后，ROM 团队可能还在等待源码。
- 构建可复现性下降。 公开 tag、提交哈希和源码快照之间的对应关系更难自动验证。
- 审计成本上升。 团队需要检查 Drive 中的压缩包、目录结构、版本标识和文件清单。
- 社区协作受限。 依赖 Git 的补丁审查、自动化测试和差异分析都不适合围绕一次性文件分发来组织。
这也会把一个本来属于发布基础设施的问题，转化成项目排期风险。即使最终拿到的代码没有减少，交付过程本身也可能拖慢维护者响应漏洞和支持新固件的速度。
可以这样实践：把源码获取当作供应链输入
在流程尚未稳定前，维护 Pixel 或其他厂商设备的团队可以把源码包视为一个需要记录和验证的供应链制品。下面的 Bash 示例会计算下载文件的 SHA-256，并把压缩包内容保存为清单。将 pixel-kernel-source.zip 替换为实际文件名即可运行。
#!/usr/bin/env bash
set -euo pipefail
archive="${1:-pixel-kernel-source.zip}"
manifest="${archive}.sha256"
[[ -f "$archive" ]] || {
printf 'missing archive: %s\n' "$archive" >&2
exit 1
}
sha256sum "$archive" | tee "$manifest"
unzip -Z1 "$archive" | LC_ALL=C sort > "${archive}.files.txt"
printf 'recorded: %s and %s\n' "$manifest" "${archive}.files.txt"
在 CI 中，还可以把来源信息单独写入构建元数据，例如：
source_artifact:
provider: google-drive
requested_at: "2025-01-15T09:00:00Z"
received_at: "2025-02-03T14:20:00Z"
filename: pixel-kernel-source.zip
sha256: REPLACE_WITH_SHA256
upstream_reference: REPLACE_WITH_VERSION_OR_COMMIT
这些字段不能解决源码延迟，但能让团队回答几个关键问题：当前构建使用了哪一份文件？它何时收到？是否被替换？下一次构建是否使用了同一输入？如果来源没有公开提交哈希，upstream_reference 应明确记录可获得的版本号、固件版本或请求编号，而不是伪造一个 Git 提交。
维护者应该关注的边界
最现实的应对不是假设每个 Drive 文件都等价于完整 Git 仓库，而是建立发布闸门：验证压缩包校验和，记录目录和文件数量，检查许可证与构建脚本，比较内核配置和导出符号，并在设备上运行最小启动与硬件回归测试。
同时，项目需要评估是否保留旧源码、是否能够延后支持某个固件、以及是否要把源码等待时间纳入安全更新承诺。对用户而言，透明说明“某个版本正在等待厂商源码”通常比给出一个看似完整、但无法复现的构建更可靠。
结语：源码公开的关键不只是可下载
源码是否能下载只是第一层问题。对操作系统维护者而言，真正重要的是公开方式是否稳定、可追踪、可自动化，并且允许社区验证版本之间的关系。
如果 Google 最终恢复 Git 形式的公开发布，影响会逐步降低；如果表单和人工交付成为长期流程，AOSP 衍生项目就需要把等待、校验、归档和延期发布设计成正式的工程流程。Pixel 生态的风险因此不在某个下载链接本身，而在源码交付从公共版本控制转向不可预测的人工流程。