Android 转内部开发谁说是闭源?明明 AOSP 外部 PR 支持也会继续

前几天最热门话题之一不外乎盛传 Android 闭源,可谓「节奏」一开「流量」全来,虽然做媒体的难免「春秋笔法」,但是直接「断章"曲"义」的做法未免有些离谱,总想搞个大新闻,刚好现在风头已过,就简单聊聊始末。

首先本次的的核心是「转内部开发」,怎么理解这个变化?用人话说就是:

我做完了再全部公开出来给你看,没做完之前一般人看不到,当然我兄弟还是能提前看到

至于为什么要这样做,官方点的说法就是:同时维持「公开的 AOSP」和「内部分支」成本越来越高,比如要花费大量时间在两个分支之间合并补丁和处理冲突,因为这个两个分支的代码结构和新旧差异越来越大,合并一个简单的修复,就可能需要处理一系列复杂的冲突。

而如果用人话说,可以简单理解为:

之前的做法越来越费钱了,所以需要想办法「截流」,也许是裁员裁多了,维护不过来了

事实上很多公司在开源方面都会有自己的内部版本和公开版本,不管是需要「脱敏」还是「维持稳定」考虑,对外的公开版本都不可能一股脑就给你提交出来,比如前段时间的字节的 lynx ,内部其实已经支持鸿蒙了,但是初步开源的版本还是不带鸿蒙:

又像 Flutter ,它很多提议性质和草稿性质的代码,也不会直接合并到 main 分支,而是在相对可用,或者确定可尝试落地之后,才会真正进入大众视野,而如果不做好这一点,就像宏落地失败一样,负面影响更深。

况且,像 Android 这样的大型开源项目,它本身的各种依赖也许遵循相对应的开源协议,比如 Linux 内核分支采用的 GPLv2 许可,谷歌仍需遵守开源协议,如果不守规则,作为大企业那可是要收律师函的:

另外,从前几年开始,Andorid 的核心系统框架大部分就已经是在谷歌的内部分支中完成 ,所以这次也就是把剩余部分也转入内部,节省维护成本 ,从这点看,可以大胆猜测谷歌搞 AI 是真的烧了不少钱,用 320亿美元的全现金交易收购 Wiz 也是为了 AI ,一边是开"猿"截流,一边是 AI 的经费燃烧,时代真的变了,Android 现在也只能算是「半老徐娘」,比不得 AI 风华正茂 。

所以从上面部分总结下来就是:为了省钱省人力,Android 开发现在我们先做好,再发出来给你看,当然,这一切都只是针对个人。

而对于和谷歌有合作的厂商,仍可以依照 Early Access Program 和协议获取最新的 AOSP 或 branch(分支),这对 OEM 合作方没有什么影响:

毕竟如果大牌厂商需要等公开 AOSP ,那是真的吃x都赶不上热的了。

接着就是关于 PR,,Google 也表示了 Android 团队会继续接受来自外部开发人员的代码贡献,平台开发人员仍将能够向 AOSP Gerrit 提交补丁,而合作伙伴也可以通过合作伙伴的 Gerrit 权限提交补丁,只是内部渠道的 PR 在完全发之前不会向公众开放。

所以基本上可以看出来,如果硬要说会有影响的话,那就是没权限的普通人,你只能等 final release 之后才能了解到相关内容。

并且,接下来 aosp-main 分支将被锁定并设置为只读,外部开发者将建议使用 android-latest-release 分支,同时提交到 aosp-main 的 PR 更改不会被合并,外部 PR 还是需要依赖于 android-latest-release

之后 aosp-main 的 CI 构建将会被停止,而如 android15-releaseandroid15-tests-dev 等 IC 还会继续分布,谷歌将继续支持现有的 Android 开发者预览版/测试版计划,只是内部 main 分支不会再发布 CI 支持。

所以对于厂商基本没任何影响,受影响的基本上没权限的个人,而谷歌也根据已有数据做出判断,非合作的外部个人贡献者其实 PR 占比很小。

所以作为一般人,如果你想给 AOSP 提 PR ,通过 release 分支提交即可,审核通过后也会并合并,和之前的区别就是,你可能没那么快获取到较新资料,而对于合作方而言,一切都还是老样子。

所以,肯定有人要说,虽然现在没闭源,但是未来你能说就不闭源吗?

嗯,这就是典型的辩论里的「滑坡谬误」,将讨论从现实拉向一个虚构的、未经证实的情景,从而规避对当前事实的直接回应

在论证中假设一个相对较小的初始行动或事件会不可避免地导致一系列连锁反应,最终到达一个极端或不希望的结果,而这种因果链通常缺乏充分的证据支持。简单来说,就是从"如果A发生"跳跃到"那么必然会导致灾难性的Z",忽略了中间步骤的合理性和可能性。

这种手法的问题在于,它往往夸大了未来的风险,跳过了对当前事实的分析,也未提供中间环节的逻辑支持。它依赖于假设和恐惧,而不是严谨的推理。

如果按照这个逻辑,Android 都转内部开发了,你能保证 Android 不是要凉了吗?

参考链接

相关推荐
@大迁世界10 分钟前
1.什么是 ReactJS?
前端·javascript·react.js·前端框架·ecmascript
BJ-Giser1 小时前
Cesium 基于EZ-Tree的植被效果
前端·可视化·cesium
键盘鼓手苏苏2 小时前
Flutter 三方库 p2plib 的鸿蒙化适配指南 - 实现高性能的端到端(P2P)加密通讯、支持分布式节点发现与去中心化数据流传输实战
flutter·harmonyos·鸿蒙·openharmony
加农炮手Jinx2 小时前
Flutter for OpenHarmony:postgrest 直接访问 PostgreSQL 数据库的 RESTful 客户端(Supabase 核心驱动) 深度解析与鸿蒙适配指南
数据库·flutter·华为·postgresql·restful·harmonyos·鸿蒙
加农炮手Jinx2 小时前
Flutter 组件 heart 适配鸿蒙 HarmonyOS 实战:分布式心跳监控,构建全场景保活检测与链路哨兵架构
flutter·harmonyos·鸿蒙·openharmony
钛态2 小时前
Flutter 三方库 http_mock_adapter — 赋能鸿蒙应用开发的高效率网络接口 Mock 与自动化测试注入引擎(适配鸿蒙 HarmonyOS Next ohos)
android·网络协议·flutter·http·华为·中间件·harmonyos
王码码20352 小时前
Flutter for OpenHarmony:Flutter 三方库 algoliasearch 毫秒级云端搜索体验(云原生搜索引擎)
android·前端·git·flutter·搜索引擎·云原生·harmonyos
王码码20352 小时前
Flutter 三方库 dns_client 的鸿蒙化适配指南 - 告别 DNS 劫持、探索 DNS-over-HTTPS (DoH) 技术、构建安全的鸿蒙网络请求环境
flutter·harmonyos·鸿蒙·openharmony·dns_client
键盘鼓手苏苏2 小时前
Flutter 组件 highlighter 适配鸿蒙 HarmonyOS 实战:高性能语法高亮,构建大规模代码分析与文本染色架构
flutter·harmonyos·鸿蒙·openharmony
国医中兴2 小时前
Flutter 三方库 langchain_google 的鸿蒙化适配指南 - 链接 Gemini 智慧中枢、LangChain AI 实战、鸿蒙级智能应用专家
flutter·langchain·harmonyos