Android 17 首次在未发布 AOSP 的情况下新增 API

近期，隐私安全操作系统项目 GrapheneOS 发布的一条消息在技术圈引发关注：Android 17 成为自 Android 3.x（Honeycomb）以来，首个在没有向 AOSP（Android Open Source Project）发布源代码的情况下就新增 API 的版本。这条消息在 Hacker News 上获得了 343 分和超过 150 条评论，成为开发者社区热议的焦点。

事件背景：AOSP 与 Android 开放生态

AOSP 是 Android 的开源核心，长期以来被视为 Android 生态开放性的基石。设备厂商、定制 ROM 开发者以及 GrapheneOS、LineageOS 等注重隐私与安全的第三方项目，都依赖 AOSP 及时同步 Google 发布的新版本代码与 API 变更。

通常情况下，当 Google 发布一个新的 Android 主版本时，会同步或在较短时间内将对应源代码推送到 AOSP，让整个生态能够跟进新特性、新接口。这种同步机制正是 Android 区别于封闭系统的关键之一。

而 GrapheneOS 指出，Android 17 打破了这一惯例——它是自 Android 3.x 时代以来，第一个在新增 API 的同时却没有随之开放 AOSP 源代码的版本。这意味着相关的接口变更暂时停留在 Google 的封闭开发环境中，尚未进入公开的开源代码库。

值得注意的是，Android 的「开放」从来都是相对而言的。AOSP 只包含 Android 系统的基础框架，而普通用户日常使用的 Google 地图、Gmail、Play 商店等应用，以及 GMS（Google Mobile Services，谷歌移动服务）框架，均属于闭源的私有组件。设备厂商若要预装这些服务，需要与 Google 签署授权协议并通过兼容性测试（CTS）。这意味着从 Android 诞生之初，「开源的 AOSP」与「完整的 Android 商业生态」就是两个不完全重叠的概念。近年来，Google 将推送通知、定位服务、安全更新补丁等越来越多的关键功能从 AOSP 迁移至 GMS，进一步加深了这种分裂——即便拿到全部 AOSP 源代码，没有 GMS 授权的设备在功能完整性上仍与主流 Android 设备存在明显差距。

为什么 Android 3.x 会成为历史参照

了解这一表述的分量，需要回顾 Android 3.x（代号 Honeycomb）的特殊历史。Honeycomb 是专为平板设备设计的版本，Google 当时选择推迟其源代码的公开发布，理由是这一版本并未针对手机做完整优化，担心厂商将其强行移植到手机上影响用户体验。

Honeycomb 因此成为 Android 历史上一个罕见的、未及时开源的版本，长期被开源社区作为「AOSP 开放性受限」的典型案例引用。GrapheneOS 将 Android 17 与之类比，实际上是在提醒外界：这可能是十余年来 Android 在开源同步节奏上的又一次显著偏离。

对第三方 ROM 与隐私项目的潜在影响

对于 GrapheneOS 这类高度依赖 AOSP 的项目而言，新增 API 却不开放源代码，会带来现实的适配困难。开发者无法及时获取完整的实现细节，也就难以在自己的系统中支持新特性、修补潜在的安全问题，或者验证接口的行为逻辑。

这种延迟或缺失的源代码发布，可能拉大第三方系统与官方 Android 之间的功能差距。对于强调透明与可审计的隐私操作系统来说，无法查看源代码更是直接触及其核心价值主张——用户和开发者都无从确认这些新 API 究竟做了什么。

GrapheneOS 与 LineageOS 等项目的生存逻辑，建立在「可以从 AOSP 获取足够完整的基础实现」这一前提之上。前者专注于强化安全模型，引入了诸如内存分配随机化加强、网络权限沙箱、可撤销的传感器权限等特性；后者则以广泛的设备支持和长期维护著称。两类项目都依赖 AOSP 的及时同步来跟进系统级安全补丁，一旦源代码发布滞后，这些项目不仅面临功能适配难题，更可能面临已知漏洞无法及时修复的安全风险。对 GrapheneOS 的用户群体而言，他们选择该系统往往正是出于对官方 Android 闭源组件的不信任，若连 AOSP 的开放性也开始打折，其替代价值将受到根本性质疑。

社区争论：这是趋势还是个例

在 Hacker News 的讨论中，开发者们对这一变化的解读存在分歧。一部分人担心这标志着 Google 正在逐步收紧 Android 的开放程度，将更多核心功能移入闭源的 Google Play 服务与私有代码中，长期看会削弱 AOSP 的独立价值。

也有观点认为，不应急于将其解读为战略转向。可能只是特定版本、特定 API 的发布节奏问题，源代码或许会在稍后正常释出。在缺乏 Google 官方明确说明的情况下，这一事件的性质仍存在不确定性。

需要说明的是，本文所依据的核心信息来自 GrapheneOS 的社交平台发布以及 Hacker News 上的社区讨论，尚未看到 Google 方面的正式回应或详细技术文档予以佐证。

值得持续关注的信号

无论最终结论如何，Android 17 的这一动向都触及了一个长期议题：Android 究竟还有多「开放」。过去数年间，Google 已被多次批评将越来越多功能从 AOSP 迁移到闭源组件中，AOSP 逐渐被指「空心化」。此次 API 与源代码发布脱节的现象，为这一讨论再添一个具体注脚。

对关注 Android 生态、隐私安全以及开源治理的开发者和用户而言，接下来值得观察的是：Google 是否会补齐这部分源代码、这一做法是否会延续到后续版本，以及 GrapheneOS 等项目将如何应对由此带来的适配挑战。

AOSP「空心化」的批评由来已久，有研究者曾统计 AOSP 在完整 Android 系统代码中的占比随版本迭代持续下降。2018 年前后，Google 将系统 WebView、Chrome 等组件转为独立更新，2021 年又推动了 Project Mainline（又称 Google Play 系统更新），使得越来越多的系统模块可以绕过厂商 OTA 直接由 Google 推送更新——这既提升了碎片化问题的应对能力，也意味着这些模块从 AOSP 的完整版本发布流程中被剥离。Android 17 的此次 API 与源代码发布脱节，放在这一更长的历史弧线下观察，其象征意义或许不亚于实际的技术影响。