谷歌将于2026年合并安卓与ChromeOS，因人工智能
谷歌已确认将合并其ChromeOS和安卓操作系统，且移动操作系统将占据主导地位。
这家广告与搜索巨头此前已暗示将整合两大操作系统。本周三在高通峰会活动中，谷歌安卓生态系统总裁萨米尔·萨马特正式宣布：安卓将成为最终赢家，用户将于2026年见证成果。
“我们看到的核心机遇在于：如何加速安卓平台上的人工智能技术发展，并将其快速引入笔记本形态设备？同时实现笔记本与整个安卓生态系统的无缝协同？”他周三表示。
“简而言之，我们将以Chrome OS体验为基础，在安卓系统底层重构技术架构。这种融合让我们对明年充满期待。”
Chromebook系列产品助力谷歌在笔记本市场开辟了细分领域，主要通过向学校销售低价设备供学生使用。这家搜索巨头还推出了高端高性能Chromebook机型。
但随着谷歌——以及科技领域所有企业——将人工智能融入万物，安卓系统迎来了闪耀时刻，他如是说。
萨马特指出，转向安卓代码库意味着谷歌能将Gemini人工智能服务部署到更多设备上。
为佐证安卓系统适用于笔记本电脑的论点，萨马特指出该操作系统在平板电脑领域已取得“巨大成功”。
高通在谷歌新战略中的角色，似乎是将智能手机SoC适配笔记本电脑，或确保其为Windows系统生产的笔记本芯片也能兼容安卓系统。
萨马特表示，安卓还为将XR技术(虚拟现实、增强现实及其他扩展现实系统)集成到各类平台提供了机遇。他认为安卓将实现这一目标。
但萨马特强调，谷歌两大操作系统的融合主要关乎人工智能——正如今年所有事物的核心所在。®
我很高兴他们将专注于在更多设备上采用单一操作系统，但非常担心无法绕过安装“不可信”应用的限制。若用户无法完全掌控设备，这些设备终将沦为广告/影响工具。
更糟的是监控工具。欧盟很快可能强制推行客户端扫描应用，英国或将推行数字身份认证。
这为强制远程验证和强制安装软件创造了绝佳条件。
我认为这正是发展方向。谷歌所有变革都在为此铺路。
科技巨头正用温水煮青蛙的策略，试图让我们习惯将Linux视为运行在授权设备上的普通“应用”——这些设备不受我们管理。
谷歌会指着安卓系统的Linux终端应用说：“看吧，我们推行侧载变更没问题——你完全可以在虚拟机里运行Linux(在没有root权限的设备上)。” WSL同样让我们习惯了Linux只是应用程序的观念。
准备好迎接人们不察言观色就盲目接受的局面吧，届时地毯将被抽走。我们将看到硬件OEM厂商锁死引导程序，不再允许安装替代操作系统；即便勉强安装了其他系统，也因无法通过设备认证检查而无法访问任何互联网服务。
没错。一两年后可能出现这样的未来：访问绝大多数网站时，系统必须从固件层级向上证明其未经篡改，且用户持有合法授权(甚至可能要求年满18岁)。
只需Cloudflare等公司将其作为免费选项提供给所有CDN客户，谁会拒绝启用？尤其当替代方案是自行处理身份验证时，对吧？
巴西现行法律已要求在线服务和“终端操作系统”必须采用政府批准的方式进行年龄验证。
高通Arm架构PC支持硬件嵌套虚拟化技术，可运行pKVM L0及KVM L1虚拟机监控程序，与Pixel设备功能相似。这意味着开发者可在虚拟机中运行Debian Linux系统——类似Pixel设备现有的“Linux终端”功能，虚拟机内可访问全部Debian Arm软件包并拥有root权限。
“终端应用现可在最新版Android Canary中运行完整图形化Linux应用”，https://news.ycombinator.com/item?id=44681858
“摆脱笔记本的编程体验：两周实践AR眼镜与安卓Linux系统”，https://news.ycombinator.com/item?id=43985513
> 这可能实现虚拟机中的Debian Linux，
这如同在公共场合发生性行为。虽可行却危险。
黑客圈速递：基于Android与GrapheneOS的Google Pixel开发者终端虚拟机，提供逾5万个经Debian软件包维护者签名的开源软件包。这些维护者作为Ubuntu、Devuan等Linux发行版的上游“根发行版”备受信任。在安卓手机上使用单个Debian Linux软件包无需依赖应用商店身份注册、财务支付或Google Play服务遥测数据。
得益于SoC在虚拟机边界实现的CPU/内存虚拟化，Debian软件包与设备其他部分的隔离性，远强于应用商店分发的任意两个Android软件包——后者仅在单一虚拟机环境中运行。这有效防止了开发者终端虚拟机中的Debian Linux软件产生副作用。
相较现状，此方案更安全可靠。
> 可行但危险
错误。该方案隔离性更强、危险性更低、安全性更高、开发者灵活性更大，并能提升用户功能体验。
所以呢？
技术能力往往与产品实际运作方式关联甚微。
我怀念那些企业只售工具、消费者能以制造商从未设想的灵活创意方式使用产品的时代。
同感。但企业发现通过寻租能赚更多钱。归咎于增长文化——可持续经营已不足够，必须快速扩张并规划明确退出路径，要么IPO要么被收购。
例如Android官方推荐的NDK使用方式：仅限于为Java/Kotlin实现原生方法，或开发纯粹的游戏应用，且必须严格遵循官方支持的API列表。
任何超出许可范围的行为，要么勉强运行，要么彻底崩溃。
他们认定让单一事物恶化比同时搞砸两件事更高效。
若设备支持adb解锁且非封闭机型，用户便可运行F-Droid安装应用。这意味着无需通过APK手动下载安装的“侧载”方式，即可运行独立路径代码。对谷歌而言，F-Droid本身就是侧载行为。
若解锁后仍无法运行谷歌钱包或银行应用，这便成了封闭系统，欧盟反垄断诉讼仍可能适用。但若能编造出关于执法机构合法解码权限的“可信”故事，此事或许就能不了了之。
我认为关于Fuchsia等系统的预测结果不如某些人期待的那么有趣：但让两个操作系统同时出现在公众视野中(若算上Android TV以及Nest和Chromecast上运行的封闭系统，实际是三个或更多)始终是个错误。
我能在Termux环境中工作，但有些功能它难以胜任(比如tcpdump？以及因沙盒规则导致的外部数据交互)，而这些正是我急需的。
我不喜欢Android处理可移动存储的方式，这完全是反模式。
> 我可以在Termux环境中工作，但有些功能它难以实现，
因为这些功能不属于NDK允许调用的API范围。
https://developer.android.com/ndk/guides/stable_apis
Termux能实现的任何超出该列表的功能，更多是侥幸——毕竟Android团队尚未关闭特定的Linux系统调用。
最初Android在2.0版本才引入NDK，这源于游戏开发者的压力，加上Dalvik虚拟机性能太差，它从来就不是为编写完整应用而设计的。
我热爱Termux，但它绝非完整Linux的替代品。Linux软件的运行预期存在太多不兼容性，无法满足开发工作流需求(除非你的工作流是立即SSH到其他系统)。
我发现兼容性最佳的方案是通过proot-distro进入Alpine系统，借助musl库既能绕过大量Android限制，又能解决bionic-libc的不兼容问题。不过性能会有所牺牲。
我认为如果他们阻止F-Droid存在，其计划就违背了《数字市场法案》。他们似乎押注特朗普能迫使欧盟彻底废除该法案。
> (50) […] 为确保第三方软件应用或应用商店不会危及守门人提供的硬件或操作系统完整性，相关守门人应能采取相称的技术或合同措施实现该目标——前提是守门人能证明此类措施必要且合理，且不存在更少限制的替代方案来保障硬件或操作系统完整性。
> (54) 守门人可能阻碍终端用户获取在线内容与服务(包括软件应用程序)。因此应制定规则，确保终端用户访问开放互联网的权利不受守门人行为侵害。守门人还可能通过控制硬件或操作系统等技术手段，限制终端用户在不同互联网接入服务提供商间有效切换的能力。这扭曲了互联网接入服务的公平竞争环境，最终损害终端用户利益。故应确保守门人不得不当限制终端用户选择互联网接入服务提供商的权利。
[https://eur-lex.europa.eu/legal-content/EN/TXT/? uri=uriserv%…]](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2022.265.01.0001.01.ENG&toc=OJ%3AL%3A2022%3A265%3ATOC)
毫无疑问，大多数政府都强烈关注维护安卓系统侧载应用的能力，这关乎软件开发、信息安全研究，以及维护众多参与者基于此条款投入资金的开放竞争生态系统。
开源软件开发者应能继续在其[基于AOSP分叉版本，搭载多个二进制闭源树外内核模块]的设备上编写和运行应用程序，此项能力必须受到保护，以防止反竞争行为摧毁社区共同构建的开放平台。
如今Google Play商店要求提交DUNS编号并完成注册。
F-Droid则无需DUNS编号即可上传应用。
(F-Droid是众多第三方APK注册库及安装服务之一。其网络服务托管签名的Android“APK”软件包及更新，注册用户可上传内容，未注册用户亦可无需登录直接下载。F-Droid应用程序通过其网络服务安装APK文件；但由于Android系统缺乏添加带密钥的第三方软件仓库的功能(该功能在现代Linux软件包管理系统中属标准配置)，安装或更新多个软件包时需额外操作步骤。)
Android应用开发者现已可自主决定：其应用是否允许在未通过Play Integrity验证的设备上安装或运行。
若近期安全补丁级别的非root第三方AOSP分支无法通过Play Integrity验证(例如无法运行零售银行应用)，那么已停止更新的旧版Android系统同样应被判定为不符合Play Integrity要求。
现代软件管理的开放标准包括：schema.org/SoftwareApplication、W3C可验证凭证、Sigstore、SLSA及OCI工件注册表——这些平台均已支持签名验证。
某些工具通过HTTPS旁加载APK时完全不进行校验和或签名验证(例如从GitHub发布版而非OCI注册表获取)，其风险程度堪比直接执行curl | sh命令。
bash 和 zsh 能否在 container2wasm 的 WASM 容器中运行？该容器无需安装即可在浏览器标签页中运行，并像 Android 4.4+ 后的所有应用那样拥有独立的 SELinux 安全上下文？
ls -Z 命令在 Android 终端(或 Termux、ChromeOS 终端)中是否有效？
目前学生账户和家庭链接账户无法访问Chromebook上的容器。
因此在Chromebook上，相同课程只能通过WASM中的JupyterLite实现——该方案虽能在浏览器近乎离线运行，却无法使用本地repo2docker容器或devcontainer.json(因为学生除预配设备外，无法获得服务器资源(如shell、CI、GitLab+k8s资源配额))。
container2wasm: https://github.com/container2wasm/container2wasm :
我猜这些工具会支持虚拟化框架，这样就不必依赖 tmux 了。
目前 Android 终端在 Pixel 设备上运行良好，希望合并后的版本在 ChromeOS 风格的笔记本和平板上也能完全可用。
谷歌早在2016年就曾尝试通过名为Andromeda的项目合并Android与ChromeOS：https://www.neowin.net/news/google-has-reportedly-killed-its…
我的意思是，当前Pixel设备启用开发者选项并通过USB连接显示器、键盘和鼠标后，就能运行“桌面模式”。
不难想象这其实是同一套方案，所以这次是桌面版安卓系统，而非ChromeOS的合并版本。
好奇他们是否会放弃对ChromeOS Flex的支持——那个可安装在任意设备的版本。要是能为我闲置的各种x86机器提供半官方的安卓系统，倒挺有意思。
据我所知，多数Chromebook采用x86架构(这点总让我觉得有趣，毕竟ARM架构才是最佳选择，但无所谓了)。因此我认为，任何基于Android的新版ChromeOS系统很可能运行在x86平台上。当然，现有的x86 Chromebook并未采用标准UEFI，这确实存在技术鸿沟…但既然已在相同硬件平台上为相同CPU构建相同系统，投入…顶多几天工作量…添加UEFI引导程序以大幅扩展硬件兼容性，绝对物有所值。额外好处是这将使开发者更轻松地在虚拟机中运行系统。
综上所述：我其实相当乐观，认为最终会推出官方Android x86版本。
听起来更像是他们要终结ChromeOS，转而为Android打造笔记本体验。
不知这对投资Chromebook的学校意味着什么。
我猜他们会继续支持现有设备直至约定终止服务期。届时新设备虽在使用层面基本相同(运行Chrome系统)，但底层将被锁定(面向教育场景)，使其更接近ChromeOS而非Android。
普通用户很可能察觉不到差异。方案看似可行，但细节决定成败。若谷歌未能实现，传闻苹果将推出约599美元的MacBook。未来苹果重返该领域竞争并非没有可能。
所有已售出的Chromebook均可解锁启动加载程序并更换系统软件，此操作将使其脱离学校设置的管理体系。
我认为ChromeOS的融合进程已持续推进多时，因此Chrome应用商店被Android应用商店取代。过去一年每次更新Chromebook时，其系统都更趋近于Android风格。
他们看到了进军Windows桌面市场的契机并正在把握。我个人支持这条路线，因为目前唯一优秀的笔记本+手机整合方案只有苹果。希望他们别在剪贴板共享等整合功能上搞砸机会。
ChromeOS支持服务已签订合约，因此有保障。
但终有一天支持期满必须切换系统。据我所知，支持周期通常为7-10年不等。
我预感到即将发生合并冲突。
说真的，这其实是必然趋势——随着Fuchsia项目逐渐收尾，而Android在Windows平台上运行已充分证明其价值(这算是个不错的实验吧)。
Fuchsia每周仍接收数百次提交，开发异常活跃，包括向Android本体迁移(尽管Fuchsia本身仍与Android解耦，可用于其他场景)
Windows上的Android？
其实是Windows上的Google Play商店。
好吧，但你到底在说什么？
我所知的唯一Windows版安卓系统是子系统，但它被捆绑在亚马逊应用商店上，最终随着亚马逊放弃应用商店而终止。
https://play.google.com/googleplaygames/
微软曾两次尝试：首次仍在Windows 8.x时代，其废墟中诞生了WSL。
搭载亚马逊商店的版本是第二次尝试。
> 为佐证安卓能在笔记本运行的论点，萨马特指出该系统在平板电脑上“极其成功”。
大概是2015年吧？后来所有OEM厂商发现平板没有手机那样的升级周期就失去兴趣了？如今安卓平板市场不就是靠三星偶尔更新机型维持生命吗？
> 安卓平板市场基本靠维持生命
我不这么认为，近年市场相当活跃。中国知名品牌推出了许多优质平板：小米、联想、vivo、OPPO和一加都推出了“旗舰级”平板(搭载高端处理器，配备顶级屏幕和工艺品质)
确实，从市场占比看平板始终是小众领域——绝对数量不算少，但相较手机就显得微不足道。况且生产平板的公司通常也做手机，自然优先资源都倾注在手机业务上。
不尽然，在美国以外的安卓主导市场，多数人同样选择安卓平板，如三星、小米或华为。
我认为只见到iPad的人群，通常来自苹果主导的少数市场。
我并非美国用户，安卓在我国手机市场占据主导，但平板领域并非如此。
如图所示，苹果在欧洲市场份额仅约46%，全球占比49%，其余份额由所有安卓厂商瓜分。
https://gs.statcounter.com/vendor-market-share/tablet/europe
若参考另一组全球数据，其份额约为54%
https://www.bankmycell.com/blog/global-tablet-market-share/
即便采用更乐观的统计数据，全球平板销量中仍有半数并非iPad。
情况相当糟糕。唯一勉强维持的领域是亚马逊平板和安卓电子阅读器。
据我所知，这些设备均基于安卓9或10系统。
你真的几乎不如直接把Windows平板改造成Linux设备。
触控与Linux的组合体验依然糟糕(相较于W8/W10)。Windows 11竟用广告小工具取代了W10实用手势(边缘屏幕滑动)，我对微软已不抱期待。
如今Linux拥有多种触控界面，包括Phosh、Plasma Mobile以及即将推出的GNOME Mobile。这些界面本身运行良好，与AOSP体验相当(有时甚至更优)。但基于桌面版Firefox定制的移动浏览器体验，以及软件键盘等组件，仍逊于AOSP提供的解决方案。
我已许久未尝试。虽然Ubuntu在Ubuntu Touch项目上投入不少，体验应该有所提升，但老实说我无法判断改善程度。
> 据我所知，它们都基于安卓9或10系统。
但我在查询平板时看到的并非如此。我那台旧款廉价三星Tab S6 Lite(2022版)运行Android 14，安全补丁更新至2025年5月。
我伴侣本月购入的廉价小米平板搭载Android 15，安全补丁更新至2025年8月。
我用的是三星安卓平板
我买了个联想平板。体验很差——我只用它看乐谱，但卡顿得厉害。虽然便宜，但感觉当初买台二手iPad更划算。
好奇安卓系统是否会为大屏设备升级窗口化界面，还是会像三星Dex那样？
过去三四年谷歌似乎活跃了许多。不知发生了什么。毕竟系统整合本该早就完成。
中国正在崛起。
《The Register》竟“确认”谷歌移动操作系统将“凯旋而归”？
实际上将采用Fuchsia操作系统。
希望同时用Fuchsia取代Linux？
Fuchsia是死胎。他们曾尝试将其移植到Nest和智能音箱上，最终在2023年放弃了该项目。
它显然并未消亡，谷歌仍在持续发布实质性更新[0]。
0. https://fuchsia.dev/whats-new/release-notes
Fuchsia每周仍接收数百次代码提交，正处于极其活跃的开发阶段，包括向Android系统内部迁移(尽管Fuchsia本身仍与Android解耦，可应用于其他场景)
那么它的实际目标是什么？具体应用于哪些领域？
虽非发起者，但我有自己的推测。
即谷歌可能在某个节点将Android从Linux底层迁移至Fuchsia。
这合乎逻辑，毕竟他们已将Android运行时移植至该系统。
谷歌Nest Hub仍在使用Fuchsia系统。
可惜，我认为ChromeOS在基础架构方面做得比Android出色。反向合并或许更合理，但政治上绝无可能。
确实如此。反向合并恐怕也是糟糕主意，两者应当保持独立。
对此持怀疑态度。大量K-12教育版Chromebook支持周期已延长至2032年后。实际使用过两者后，我认为系统合并仍是艰巨任务。
关键在于“支持”的定义。
这可能指仅限新近Chromebook设备专属的“新一代”ChromeOS，而谷歌对“旧版”设备仅提供安全补丁更新。据我所知，谷歌从未明确承诺所有受支持的Chromebook都能获得最新功能更新，仅提及“更新”一词。
当然这纯属猜测，期待被事实推翻。
所以ChromeOS 26要用液态玻璃材质设计了？ :trollface: