2026 年 9 月，Google 将在巴西、印尼、新加坡和泰国率先实施一项影响深远的政策：所有在认证 Android 设备上安装的应用，无论来自官方应用商店还是侧载渠道，其开发者都必须通过 Google 的「已验证开发者」注册。这一政策将在 2027 年逐步推广至全球，届时数以千计通过 F-Droid 等替代应用商店分发的开源应用将面临无法安装的困境。F-Droid 项目委员会已在公开声明中明确表示：「开发者注册法令如果实施，将终结 F-Droid 项目以及我们所知的其他自由开源软件分发渠道。」
Google 开发者验证政策的技术细节
理解这一政策对 F-Droid 生态的影响，首先需要梳理其技术实现机制。Google 在 2023 年已为 Google Play 商店引入了开发者验证机制，2026 年的新政策将其扩展至所有侧载场景。核心要求包括：所有应用包名（Package ID）与开发者账户绑定，未通过验证的开发者在认证设备上无法安装或更新任何应用。
这一政策的技术实现依赖于 Android 系统的认证设备（Certified Devices）概念。经过 Google 认证的 Android 设备会检查应用的签名证书是否与已验证开发者账户关联。对于 F-Droid 而言，这意味着一旦政策生效，其分发的每一款应用都需要上游开发者单独在 Google 完成注册，否则即使应用本身完全开源、代码可审计，也将无法在普通用户的手机上安装。
F-Droid 官方博客详细阐述了核心矛盾：「F-Droid 项目不能要求开发者通过 Google 注册应用，但同时我们也不能『接管』我们所分发的开源应用的应用标识符，因为这将有效地独占这些应用的分发权。」这一表述揭示了开源分发与传统商业分发模式的根本差异：开源项目通常使用上游开发者注册的原包名，以保持应用身份的一致性和兼容性，而 Google 的政策恰恰要求对包名进行中心化登记。
F-Droid 供应链的工程架构
要理解这场危机的深层含义，需要回顾 F-Droid 作为替代应用商店的工程实践。F-Droid 并非简单的应用分发渠道，而是一套完整的开源应用供应链系统，其核心特征包括：
首先，所有上架应用必须是完整的自由开源软件（FOSS）。F-Droid 团队会对每款应用进行人工审核，检查源代码是否真正开放、是否存在隐藏的跟踪功能或专有组件。这一审核流程虽然相对 Google Play 的自动化检查更为耗时，但提供了不同的安全信任模型。
其次，F-Droid 维护独立的构建流水线。每个应用的 APK 文件都是在 F-Droid 自己的构建环境中从源代码编译生成，而非简单分发上游开发者提供的二进制文件。这种做法确保了用户收到的 APK 确实来自公开的源代码，防止供应链攻击。
第三，F-Droid 推行可复现构建（Reproducible Builds）实践。理论上，任何人都可以在本地环境中使用相同的工具链重新编译 F-Droid 分发的应用，并验证生成的二进制文件与官方发布的完全一致。这意味着即使 F-Droid 服务器被攻破，用户也能通过密码学验证发现篡改。
正是这套供应链工程实践，使 F-Droid 成为 Android 生态中独特的开源应用来源。然而，Google 的新政策直接切断了这一链条的最后一环：当终端用户无法安装未经 Google 验证的应用时，无论 F-Droid 的供应链多么透明、多么可验证，都将失去实际意义。
对开放生态的多维影响
这场危机的本质并非单纯的技术兼容问题，而是 Android 平台治理模式的根本转变。Google 将开发者验证类比为「机场的身份检查」，强调这是为了打击恶意软件和欺诈行为。然而，F-Droid 和其他开源社区成员对此提出了尖锐的质疑。
一个关键的反面论据是：Google Play 商店本身从未彻底消除恶意软件和广告软件。即便在现有的开发者验证框架下，Google Play 仍多次被发现分发带有恶意代码或隐私侵犯行为的应用。F-Droid 在公开声明中指出：「我们不相信开发者注册的动机是出于安全考虑。我们认为这是为了巩固权力、收紧对曾经开放生态系统的控制。」
从工程角度看，这一政策还带来了应用标识符管理的问题。在 Android 生态中，包名不仅是一个技术标识，还承载着应用身份、数据迁移、权限继承等多重语义。当数千款开源应用需要重新在 Google 系统中注册时，会产生一系列复杂问题：开发者是否愿意为维护开源项目而向 Google 提供个人身份信息？多个开源项目使用相同包名的情况如何处理？应用所有权转移的治理机制是什么？
值得注意的是，即使在当前政策下，绕过验证的技术路径仍然存在。root 权限、自定义 ROM（如 LineageOS）、非认证设备都可以继续使用 F-Droid。但这些方案无疑提高了普通用户的使用门槛，将 Android 的开放性从默认状态转变为需要主动选择的状态。
可行的技术应对路径
面对这一政策压力，F-Droid 生态系统正在探索多条应对策略。从工程实践角度，以下几个方向值得关注：
第一，客户端分散化策略。Droid-ify 作为 F-Droid 的现代前端客户端，支持添加多个第三方仓库，这意味着即使 F-Droid 主仓库受限，用户仍然可以访问其他兼容的仓库源。Aurora Store 则提供了访问 Google Play 的匿名客户端，允许用户在保持隐私的前提下获取专有应用。Obtainium 采用更激进的去中心化路线，直接从 GitHub、GitLab 等上游源代码仓库跟踪和更新应用，完全绕过任何应用商店。
第二，政策游说与监管介入。F-Droid 官方呼吁用户向监管机构施压，要求审查 Google 政策的反竞争性质。这一策略的可行性取决于不同司法管辖区的监管力度，欧盟《数字市场法案》可能提供有意义的制衡力量。
第三，技术层面的长期演进。完全去 Google 化的设备（如基于 postmarketOS 或 Ubuntu Touch 的移动设备）可能成为开源社区的长期避风港。虽然这些系统在应用生态丰富度上仍无法与主流 Android 竞争，但为追求完全自主控制的用户提供了可行选择。
现实路径与工程启示
对于关注 Android 生态开放性的工程师和用户而言，2026 年的现实路径可以概括为以下几个层次。在认证设备上，如果需要继续使用 Google 服务，同时希望安装开源应用，唯一的可行方案是确保应用开发者已在 Google 完成验证注册，这通常意味着应用已同时存在于 Google Play 中。
在 de-Googled 设备或自定义 ROM 上，F-Droid 及其生态系统预计将基本维持现有功能。对于技术能力较强的用户，维护一套自定义 ROM 环境可能是保持开源应用生态访问能力的可行方案。
从更宏观的视角看，Google 的开发者验证政策代表了平台型互联网治理的又一次范式转变。当操作系统供应商能够实质性控制侧载应用的安装时，开源软件的分发模式将面临根本性挑战。这一事件也为其他平台和社区提供了警示：在依赖中心化平台分发渠道时，需要预先考虑政策变更带来的供应链风险。
资料来源：本文核心事实依据 PCMag 对 F-Droid 官方声明的报道，以及 F-Droid 项目关于 Google 开发者注册政策的公开回应。