# Android 17 is the first since 3.x to add new APIs without releasing to the AOSP

> 来源：[HackerNews](https://grapheneos.social/@GrapheneOS/117282080803799576)

# Android 17 打破十年惯例：新 API 不再同步开源到 AOSP，这对开发者意味着什么？

## 背景与概述

长期以来，Android 的开源模式一直是其生态竞争力的重要基石。Google 通过 Android Open Source Project（AOSP）向外界释放大部分平台源代码，厂商、ROM 开发者以及社区贡献者可以基于这些代码进行定制、移植和二次开发。每当一个新版本 Android 发布，AOSP 通常会同步或稍后跟进对应的源码分支，开发者可以从中查阅新增 API、系统服务实现以及底层框架变化。

然而，这一延续多年的惯例在 Android 17 上出现了明显变化。根据 GrapheneOS 官方社交账号披露的信息，**Android 17 是自 Android 3.x（Honeycomb）以来，首个在未向 AOSP 发布源码的情况下就引入新 API 的版本**。这意味着 Google 在 Android 17 中新增的部分 API，目前只存在于其内部或合作伙伴渠道的代码库中，AOSP 社区无法第一时间获取对应实现。

对于依赖 AOSP 进行 ROM 开发、系统定制、安全加固（如 GrapheneOS）以及第三方兼容性适配的团队来说，这是一个值得高度关注的信号。它不仅影响代码获取的时效性，也可��改变 Android 开源生态的协作节奏与透明度。

## 核心内容

### 1. 事件的核心事实

GrapheneOS 的这条信息点出了两个关键要素：一是“新增 API”，二是“未发布到 AOSP”。换句话说，Android 17 在 API 层面已经向前演进，但 AOSP 侧并没有同步获得这些新接口的源码。这与过去“先开源、再跟进”或“发布即开源”的模式形成了鲜明对比。

### 2. 为什么 Android 3.x 是一个参照点

Android 3.x（Honeycomb）是 Android 历史上一个特殊版本，主要面向平板设备，且当时 Google 并未立即将其源码完全开源。此后从 Android 4.0（Ice Cream Sandwich）开始，AOSP 的开放节奏逐渐稳定。因此，将 Android 17 与 3.x 相提并论，说明这次的变化在开源策略上具有“断代”意义。

### 3. 受影响的群体

- **ROM 与定制系统开发者**：如 LineageOS、GrapheneOS 等，需要基于 AOSP 进行安全补丁和功能移植。
- **设备厂商与芯片厂商**：需要提前适配新 API，但若 AOSP 缺失，可能更依赖 Google 的合作伙伴渠道。
- **安全研究者**：无法及时审计新 API 的实现细节，可能影响漏洞发现与修复。
- **普通应用开发者**：短期影响较小，但长期可能面临 API 行���文档与实现不一致的风险。

### 4. 可能的原因推测

Google 可能出于以下考虑：
- 加强对其核心平台代码的控制，防止竞争对手快速复制；
- 配合新硬件或新服务（如 AI、隐私计算）的发布节奏；
- 减少早期源码泄露带来的安全风险；
- 推动厂商更紧密地依赖 Google 的官方合作流程。

### 5. 社区反应与潜在风险

GrapheneOS 作为以安全与隐私著称的第三方系统，其发声具有代表性。社区担忧的是：如果 AOSP 的开放滞后成为常态，Android 的“开源”标签将逐渐名不副实，第三方系统的生存空间会被压缩，用户的选择权也会受到影响。

## 技术分析

从技术架构角度看，Android 的 API 通常分为几类：公开 SDK API、系统 API（@SystemApi）、隐藏 API（@hide）以及内部实现。AOSP 源码的缺失，主要影响的是系统 API 和隐藏 API 的可见性。

过去，开发者可以通过 AOSP 中的 `frameworks/base`、`system/core` 等模块，查看新 API 的声明与实现。例如，一个新增的系统服务接口，往往能在 AOSP 中找到对应的 AIDL 文件和 Java 实现：

```java
// 示例：AOSP 中常见的系统服务接口声明
public interface IMyNewService extends IInterface {
    void doSomething(int param) throws RemoteException;
}
```

如果这些代码未同步到 AOSP，第三方开发者只能依赖官方文档或反编译系统镜像来推断行为，效率和准确性都会下降。对于 GrapheneOS 这类需要重写或加固系统组件的项目，缺少源码意味着无法进行深度审计和定制。

此外，Android 的兼容性测试套件（CTS）和供应商测试套件（VTS）通常也会参考 AOSP 实现。若 AOSP 滞后，测试与实现之间可能出现“时间差”，增加适配成本。

## 实践建议

1. **关注官方文档与 API 级别变化**：即使 AOSP 未同步，`developer.android.com` 上的 API 参考和版本说明仍是第一手资料。
2. **谨慎使用未公开 API**：对于未在 AOSP 中出现的新 API，避免在生产环境中依赖，以免行为不稳定。
3. **加强反编译与动态分析能力**：ROM 开发者可通过 `jadx`、`frida` 等工具分析系统镜像，弥补源码缺失。
4. **参与社区协作**：关注 GrapheneOS、LineageOS 等项目的讨论，共享逆向工程成果。
5. **评估长期策略**：如果 AOSP 开放持续收紧，团队应考虑与 Google 建立官方合作渠道，或调整对 AOSP 的依赖程度。
6. **应用开发者**：优先使用公开 SDK API，保持 `targetSdkVersion` 与官方节奏一致���减少对系统内部实现的假设。

## 总结

Android 17 未向 AOSP 同步新 API，是 Android 开源历史上一个值得警惕的转折点。它提醒我们，Android 的“开源”并非一成不变，而是随着 Google 的商业与安全策略动态调整。对于中国开发者而言，既要保持对官方 API 的跟进，也要提升自主分析与适配能力，以应对可能到来的“半开放”时代。开源生态的价值在于透明与协作，希望这一变化只是暂时的节奏调整，而非长期趋势的开端。