加载失败
F‑Droid（一个开源 Android 应用仓库）发起的“Keep Android Open”讨论，起因是 Google 提出的开发者验证/应用签名与 Play Integrity 策略及其媒体公关，社区担心这会把侧载（sideloading）和替代商店变成需 Google 批准的“高级流程”。技术争论集中在 AOSP（Android Open Source Project）与闭源 Play Services/Play Integrity 的区别、remote attestation（远程证明）与厂商密钥、以及锁定 bootloader 与 anti‑rollback 的实际影响。法律与政治维度牵涉到欧盟的 Digital Markets Act（DMA）与反垄断诉讼，社区同时在评估 GrapheneOS、/e/OS、postmarketOS 等替代方案在银行、DRM 与硬件驱动层面的可行性。总体讨论把安全防护、用户自由、技术实现与监管路径纠缠在一起，既有现实的诈骗与银行合规压力，也有对平台滥权的深刻不信任。
大量评论认为谷歌提出的“开发者验证/签名”并把侧载放入所谓的“高级流程”（advanced flow）实际上把分发权限收回到 Google 手里，削弱或扼杀像 F‑Droid、Aurora 这样的替代商店与个人通过网站分发 APK 的渠道。具体担忧包括要求开发者实名/账户绑定、为学生/爱好者设立受限账号、以及官方文档仍指向 2026 年 9 月强制验证，这些都会使安装软件需要“Google 批准”。有人强调不应把正常安装行为妖魔化为“sideloading”，把分发默认化为“商店”本身已经把权力交给平台门卫。社区已组织 KeepAndroidOpen 等请愿并号召向监管机构反馈以阻止这一趋势。
一部分评论者接受谷歌以防诈骗、阻止胁迫安装为由收紧分发的动机，援引谷歌声明要“resist coercion”、为学生/爱好者设立专门账号，并依靠 PlayProtect/Play Integrity 做扫描与提示来保护弱势用户。反对者指出 Play Store 本身历史上也有大量诈骗、假冒应用和政策漏洞，集中化白名单或证书认证只会把单点失败放大且容易被滥用；他们主张教育用户、黑名单与更细粒度权限作为替代。讨论还包含地区维度的现实理由（例如某些地区账号被盗或手机诈骗高发），这使得平台方把安全摆在优先位置变得更有政治与商业压力。
多条评论强调技术上真正能强制限制侧载的并不是 AOSP（Android Open Source Project）源代码本身，而是闭源的 Play Services、Play Integrity API 与厂商／证书体系，因此替代 ROM 在理论上可避开，但在实践中被生态、证书和硬件限制拖累。具体技术点包括 remote attestation/verified boot keys、Play Integrity 的完整性检查、厂商锁定 bootloader、anti‑rollback（降级保护）导致刷机风险，以及 Google 在 API（如 Android 36.1）中加入相关接口但尚未在主流发行版中完整落地。GrapheneOS 等项目已实现特定的 attestation 支持，但要让银行或大厂服务认可必须把其验证密钥加入白名单，实际互操作仍需额外工作。
许多评论把希望寄托于监管与反垄断：欧盟的 Digital Markets Act（DMA）被视为对抗平台滥用门槛的一条路径，社区也在号召用户向监管机构、欧盟机构反馈并签署请愿。有人指出司法判决（如 Epic 案）与法官的解释会影响平台策略，但法律推进缓慢且充满解释空间；同时存在司法辖区差异，平台可能在不同市场采取不同合规策略。实际例证包括用户向 EU DMA 团队投稿并收到人工回复、以及围绕苹果在 EU 的侧载合规做法的持续法律争议。
讨论大量聚焦替代技术路线：加速 GrapheneOS、/e/OS、postmarketOS、Librem/Pine64 等 Linux‑on‑phone 项目，或采取双设备策略（主用受管设备 + 脱谷歌的备用机/Pixel 刷机）以兼顾服务可用性与软件主权。现实阻碍包括硬件驱动与相机/GPU/电池等性能不足、开发者生态缺失、以及银行/支付与 DRM 等服务对 attestation 的依赖；短期实用方案被建议为用廉价“备机”或专门设备处理需 Play Integrity 的功能。评论既有乐观（封闭会推动 Linux 手机生态成长）也有现实悲观（主流银行与大厂不会轻易支持非 Google 认证的平台）。
大量评论对谷歌宣布的“advanced flow”和口头承诺持怀疑态度：媒体报道把谷歌博客的缓和措辞当作“已回撤”，但开发者文档、Android 16/17 beta 与实际发布中并未见到可试验的功能，社区要求谷歌用代码或可用的实现来证明。评论还指出以“抗胁迫”为名的复杂流程可能变成阻碍替代渠道的暗模式，或把侧载放在艰难的菜单与多级确认之后，从而削弱竞争对手。总体呼吁是不要只看宣传文字，要看代码与实际用户体验变化。
更深层的讨论围绕“我买的手机是否真属于我”：一派坚持买设备即应拥有在硬件上运行任何软件的权利（解锁 bootloader、运行自签名 APK、安装自有 ROM）；另一派则强调平台出于保护非技术用户免受诈骗的现实理由，会设立默认安全约束。评论中列举了 SafetyNet/Play Integrity、厂商锁 bootloader、闭源驱动等机制作为用户实际控制力被削弱的证据，并有人主张通过监管或法制保障用户对硬件的最终控制权。这个话题把技术实现、法律权利与伦理立场交织在一起，难以用纯技术或纯法律单一维度解决。
sideloading（侧载）: 绕过官方应用商店直接下载并安装 APK 的行为；讨论焦点在于是否应把此行为置于平台审核或签名机制之下。
AOSP（Android Open Source Project）: Android 的开源代码库，OEM 和社区可基于 AOSP 构建系统，但 Google 的 Play Services/认证并非纯 AOSP 的一部分。
Play Integrity / Play Protect: Google 提供的设备/应用完整性检查与应用扫描服务，用于判定设备状态与 APK 是否可信并在应用层限制造成不同策略。
developer verification（开发者验证/签名）: 谷歌提议的开发者身份绑定与 APK 签名制度——要求可追踪的已登记签名以降低伪造/轮换恶意应用的风险。
remote attestation（远程证明 / verified boot keys）: 一种证明设备引导链和系统镜像未被篡改的机制，第三方（如银行）可验证设备的密钥指纹以决定是否授权敏感功能（例如支付）。
bootloader / OEM unlocking（引导加载器与 OEM 解锁）: 引导加载器控制能否刷入第三方系统；锁定 bootloader 会阻止用户安装自定义 ROM，解锁常伴随数据清除或遇到降级保护风险。
GrapheneOS: 一个以隐私与安全为主的 Android 衍生系统，通常在 Google Pixel 设备上运行，并提供不同于闭源 Play Services 的替代策略与 attestation 支持。
EU DMA（Digital Markets Act）: 欧盟数字市场法，旨在限制大型平台滥用支配地位、强制开放互操作性与第三方接入，是应对平台垄断的一条监管路径。