将桌面 Linux 图形界面引入 Android：图形应用支持的下一步

Android长期专注于运行移动应用，但近年来面向开发者和高级用户的特性正不断拓展其边界。其中一个令人振奋的前沿领域是：在Android设备上运行完整的Linux图形界面(GUI)应用程序

 💬 59 条评论 |  安卓/android/linux | 

Android长期专注于运行移动应用，但近年来面向开发者和高级用户的特性正不断拓展其边界。其中一个令人振奋的前沿领域是：在Android设备上运行完整的Linux图形界面(GUI)应用程序。曾经的新奇尝试如今正逐步走向成熟，近期进展表明Android平台将迎来更流畅、支持GPU加速的Linux图形界面体验。

本文将追溯Linux应用在Android平台的运行历程，解析实现GPU渲染的新架构变革，展示早期演示成果，探讨现有技术瓶颈，并展望该功能的发展前景。

当前Android平台Linux运行现状

Linux终端应用

谷歌的 Linux终端 应用是Android上运行Linux环境的核心接口。它启动虚拟机(VM)——通常加载Debian或类似系统——允许用户进入shell环境、安装软件包、运行命令行工具等。

元素周期表

最初该应用仅支持 文本/终端模式 的Linux程序，图形化应用基本无法正常运行。近期谷歌在实验性通道中引入了启动图形化Linux应用的支持。

局限性：渲染与性能

即便在当下，Android平台上的多数图形化Linux应用仍采用 软件渲染——即所有绘制操作均通过CPU(借助软件渲染器)完成，而非利用设备GPU。这导致界面响应迟缓、CPU占用率高、发热压力增大及电池续航缩短。

受此限制，运行大型图形化应用(如图像编辑器、游戏、桌面级工具包)仍处于实验阶段，实用性有限。

变革方向：GPU加速渲染

重大突破在于从CPU渲染转向 GPU加速渲染，让设备图形硬件承担核心运算任务。

Lavapipe(当前基准方案)

现阶段Linux虚拟机采用 Lavapipe(Mesa软件光栅化引擎)在CPU上解析GPU API调用。该方案虽能运行，但效率低下，尤其在处理复杂GUI或动画时更为明显。

gfxstream技术导入

谷歌计划将 gfxstream 集成至Linux终端应用。该GPU虚拟化/转发技术无需软件层重新解析图形调用，而是直接将客户机(Linux虚拟机)的调用转发至主机GPU，从而规避CPU开销并实现近原生渲染速度。

事实上，开发者已在Android金丝雀版本(如2509版)的终端设置中发现“图形加速”选项。虽然可见开关仍默认显示为“软件渲染器”，但代码分析表明隐藏的“GPU加速渲染器”开关已预先嵌入。

正确启用后，该路径可让Linux图形界面应用通过GPU渲染，从而实现流畅的用户界面、降低系统负载并提升电池效率。

早期实验与应用场景

Pixel手机与Canary版本

使用Pixel 6及更新设备运行最新Android金丝雀版本的实验者，已成功在Linux终端环境中运行完整图形界面Linux应用(如 GIMP 或 LibreOffice)。该过程通常涉及安装精简桌面环境(XFCE等)、启动合成器(例如Weston)，并通过Flatpak或apt运行应用。

由于基于软件渲染器的基准配置，除非启用GPU加速，这类体验通常仍显迟缓。

Galaxy Tab S11(超越Pixel)

值得注意的是，部分新型平板(如搭载联发科芯片的三星 Galaxy Tab S11)已现身支持Linux终端应用。尽管图形界面支持仍在完善中，用户已通过手动配置成功运行Linux图形应用。

这些操作步骤暗示着将平板转变为完整移动Linux设备的可能性——同时支持键盘、鼠标和触摸屏操作。

演示应用：毁灭战士及其他

常被引用的演示案例是在Android的Linux虚拟机环境中，通过激活硬件加速路径成功运行 巧克力毁灭战士(经典毁灭战士引擎的衍生版本)。

这些早期演示展现了可行性与潜力，但诸多关键环节(音频处理、合成器稳定性)仍处于开发阶段。

技术挑战与注意事项

尽管前景可期，仍存在若干技术障碍：

硬件与虚拟机限制

要实现GPU调用转发，设备芯片组必须支持 无保护虚拟机内存 等虚拟化特性。并非所有SoC都支持此功能，部分设备(如特定骁龙型号)存在兼容性缺陷。

尤其当设备不允许虚拟机以GPU预期的方式访问内存时，转发路径可能失败或降级为软件渲染。

稳定性问题与功能缺失

由于GPU渲染仍处于实验阶段，许多环节仍存在脆弱性：

  • 合成器(Wayland/Weston)集成可能崩溃或渲染异常
  • 音频转发功能常缺失或存在缺陷
  • 界面缩放、输入法、窗口管理可能异常
  • 部分图形工具包或库可能无法正确检测硬件加速

功耗、温度与内存限制

即使启用GPU转发，Android设备仍受资源限制：虚拟机内存有限、温度降频及电池约束，可能实际限制重型图形应用的运行能力。

OEM/厂商差异性

由于Android系统经制造商深度定制，不同手机和平板设备的行为可能存在差异。部分OEM厂商可能禁用或屏蔽特定虚拟化功能及设备驱动程序。Linux终端应用的运行表现会因Android版本、内核构建或OEM定制方案而异。

更广泛的影响

这项技术演进不仅是技术创新，更开辟了全新可能性：

  • 移动端开发者：在Android上直接使用桌面级工具(IDE、编译器、GUI)可减少携带笔记本电脑的需求
  • 平板与折叠屏设备的生产力：原生运行Linux图形应用可将Android平板转变为混合生产力设备
  • Android向桌面模式融合：这些特性契合更广泛的发展趋势，使Android在连接底座或外设时能更像完整的操作系统运作
  • 边缘计算/本地AI工作负载：设备端原生运行Linux服务(GUI、仪表盘、机器学习工具)拓展了应用场景

立即体验指南

若您渴望立即体验，可参考以下基于Canary测试版/实验版本的简易指南：

  1. 使用搭载 最新Android Canary测试版 的 Pixel 6及更新机型(或兼容设备)，该版本支持Linux终端的图形界面功能。
  2. 通过开发者选项启用“Linux开发环境/终端”功能。
  3. 启用 GPU 渲染时，请在 /sdcard/linux 目录(或类似路径)创建名为 virglrenderer 的空文件。终端会检测该文件以激活 VirGL(或 GPU 转发)。
  4. 启动终端应用。您应看到提示信息显示“VirGL 已启用”。
  5. 安装或启动图形化Linux应用(例如通过apt、Flatpak)。或启动桌面环境(XFCE、MATE)或合成器(Weston)来管理窗口。
  6. 测试各类应用(优先轻量级应用)，观察响应速度、界面异常及稳定性。

请做好遇到错误、崩溃及性能波动的准备。但这无疑是未来发展的精彩预览。

未来展望

要使该体验真正实用，需改进以下方面：

  • 增强复合器支持，兼容 Wayland / X 协议
  • 实现音频与输入设备转发(如麦克风、键盘)
  • 优化大型应用的内存管理
  • 扩展芯片组与OEM厂商支持
  • 在全设备实现GPU转发(gfxstream)的官方支持
  • 将Linux图形界面支持整合至Android稳定版

若谷歌与OEM厂商持续推进，该功能有望在Android 16 QPR更新或Android 17版本中进入稳定通道。

结论

Android对Linux图形化应用的支持正快速演进。从基于CPU的渲染困境到通过gfxstream实现的GPU加速转发，该平台正逐步实现桌面级Linux应用在移动设备上的流畅运行。早期演示揭示了当前的技术可能性，但在稳定性、兼容性和性能方面仍有待提升。

共有 59 条讨论

  1. 我看到别人也提到过，如果在安卓上通过虚拟机运行自选软件比直接安装apk更容易，那可就太讽刺了。不过我还是希望看到GPU加速得到良好支持。现在能模拟运行这么多老游戏已经够疯狂了，能运行桌面版应用更是棒极了。

    回复

    1. > 若在安卓系统上通过虚拟机运行自选软件比直接安装APK更便捷，这未免有些讽刺

      我们似乎正朝着这个方向发展，但我认为其中部分设计或许是刻意为之。这既能让用户无法掌控操作系统，又能平息大众的抱怨。

      谷歌的套路是“看，我们'允许'你运行Linux了”，但同时让人们习惯于将Linux视为普通“应用”——底层操作系统依然被牢牢锁死。谷歌变革的危险之处不仅在于无法运行自定义软件，更在于设备认证机制赋予其(及政府)的权力——能操控计算机的运行边界。

      若微软对Windows实施类似变革，我将以相同视角看待WSL。

      这不过是安抚极客群体的自由幻象。

      回复

      1. 这就是我们身处的现实。现代计算机的操作系统本质上不过是固件运行的沙盒化应用程序。

        在低端手机中，固件运行的操作系统通常已是实时虚拟机管理程序，它通过复用Android系统与更高优先级的实时操作系统来驱动无线电模块。

        > 设备认证及其赋予厂商(及政府)的权力，能控制你的计算机可执行与不可执行的操作。

        设备认证或许是最不令人恐惧的形式。你依然能运行任意软件，唯一损失的是无法与要求认证的外部服务交互。这种DRM实现方式比直接锁死计算机更倾向消费者权益——而锁死计算机曾是行业多年来的发展方向。

        回复

        1. > 你唯一失去的是与要求认证的外部服务交互的能力。

          问题在于“除非使用经批准的设备或操作系统，否则将丧失在现代社会正常运作的能力”。我实在不愿看到这样的世界：必须随身携带两部手机——一部是“政府及银行服务专用机”，另一部才是真正属于我、由我掌控的设备。

          > 这比直接锁死电脑的DRM方案更符合消费者利益

          根本不存在什么“消费者友好型DRM”，这本身就是自相矛盾的。

          而谷歌正在锁死电脑——要求身份验证，强制所有安卓应用通过谷歌签名才能运行，他们随时可以撤销签名权限。

          当在线服务连官网都停止运营，强制用户使用移动应用时会怎样？突然间所有Linux(以及Mac和Windows)电脑都被隔绝在商业网络之外，你被迫携带追踪设备才能生存。

          或许这只是“两害相权取其轻”，但本质仍是邪恶，不该被我们轻易妥协接受。

          回复

          1. > 至少是真正由我拥有并掌控的设备。

            如今何处能寻得此类设备？搭载石墨烯操作系统的Pixel？还是存在我未知的优质移动Linux硬件？

            回复

              1. /e/os只是Lineage OS的分支？比起我的OnePlus跑Lineage OS有什么优势？而且如果彻底脱离谷歌生态，银行应用恐怕就用不了了。

                回复

      2. Termux是让安卓具备极客实用性的唯一途径，而谷歌只需调整权限设置(例如增加限制应用访问文件系统的手段)就能随时使其失效。我无法接受没有便捷SSH或rsync支持(或git/fossil)的手机，更不愿为替代Termux提供的命令行工具另寻应用。

        虽然目前体验尚可，我暂时不急于回归更开放的Linux手机系统，但无法深度集成到操作系统中确实是个硬伤。

        回复

  2. 有人知道运行新安卓虚拟机的优质方案吗？我想让智能手机充当哑终端，远程登录家里的实体手机。荷兰网络速度极快，这应该可行。目前尚未找到理想的模拟器。

    回复

    1. 具体取决于你的需求，waydroid或许能帮上忙。它是否算虚拟化安卓存在语义争议，但确实能在普通桌面运行大量安卓应用，并通过VNC等方式远程访问。

      回复

    2. 我一直想运行一个Android虚拟机。这是在Linux手机(或平板)上隔离Android应用的变通方案。

      但这个领域确实没什么进展。似乎没人能在虚拟机上运行Android……或者那些做到了的人不愿分享方法。

      回复

  3. 最糟糕的做法就是开始依赖Android/iOS进行桌面工作。一旦桌面环境禁止运行未经应用商店认证的代码成为常态，那就完了。

    回复

  4. 很好，但我期待的是反向操作：在Linux上运行Android图形界面。

    回复

      1. 不，不是这样。不是通过容器在Wayland上显示。而是原生替代Wayland。

        回复

        1. 容器本身是原生的。它们通常不是模拟器。它们确实将整个操作系统与可运行程序打包分发，但可运行程序最终仍需与宿主内核及宿主内存空间协作。

          至于Wayland与X11的对比。过去一年左右Wayland已相当完善。相比老旧繁琐的xorg.conf配置文件，其操作逻辑直观得多。

          回复

          1. > 关于Wayland与X11的对比。过去一年左右Wayland已相当完善，相较于繁琐的xorg.conf配置文件，其操作逻辑更为直观。

            我认为他们并非想要Xorg，而是要求SurfaceFlinger直接渲染至硬件，省去中间层。

            回复

        2. 原生方案而非Wayland的实现，本质上就是Android系统。

          回复

        3. 在cage设备上运行waydroid作为完整桌面系统并不困难，届时两者已无实质区别。

          回复

    2. > Android图形界面运行于Linux

      这不正是Android的本质吗？基于Linux内核的图形界面？

      回复

  5. Android时代已终结。移动端的Linux才是未来。

    回复

    1. 但愿如此。我愿意购买配备显示屏的眼镜和操作手套，用来操控手机端的用户界面。

      回复

  6. “摩托罗拉moto g play 2024智能手机，搭载Android 14操作系统，通过Termux及cryptsetup实现：无需root权限、无需proot-distro、无需QEMU即可实现Linux统一密钥设置(LUKS)加密/解密及ext4文件系统管理”： [https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot…](https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_ moto _g_ play _2024_ smartphone _android_ 14/) (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_ g_play_ 2024_smartphone_ android_14/)

    回复

    1. 该死 今天我才知道 Termux 其实并非通过 Proot 运行，也不是像用户空间那样的模拟器，而是通过 Android NDK 原生实现的

      我之前用的用户空间据我所知是模拟环境，我手机不知为何通过 Termux 运行不了，但现在我有点想用 Termux 修改个应用什么的，然后发布到 F-Droid 上 :p

      回复

  7. 这一切不过是为未来安卓驱动的“Chromebook”添加锁定功能，给你一个封闭的Linux命令行花园，然后宣称它“和直接在硬件上运行原生系统一样好”。

    回复

  9. 桌面交互模式(鼠标/键盘)和界面布局在手机上毫无意义。

    回复

    1. 直到我遇到用Termux搭配图形界面的人，他们通过USB-C扩展坞直接将普通显示器/鼠标/键盘接入安卓手机

      回复

    2. 通过USB-C集线器，可将键盘、鼠标和外接显示器连接至安卓设备。

      回复

    3. 微软通过触控屏PC版Windows证明：问题不仅在于小屏幕，更在于鼠标导向界面中触控目标过小。

      问题的另一面在于，当所有人都试图将AI功能塞进现有的触控界面时，触控目标不断缩小，按钮和难以区分的手势被过度使用。过去我总能告诉人们触控界面很棒，因为幼儿都能轻松掌握它。现在你试试给幼儿解释边缘手势吧。那些日子一去不复返了。

      回复

      1. > 触控目标不断缩小，按钮与难以区分的手势

        iOS 26在这方面走得太远，尤其在iPad上。他们把曾经出色的触控体验改造成只能用鼠标键盘操作。交通灯按钮和屏幕顶部的菜单都是糟糕的触控目标。

        即便在iPhone上，长按菜单也因内容堆砌和字号缩小而变得难以触控。

        这个曾完美适配3.5英寸屏幕的系统，如今在6.5英寸大屏上操作困难。我们完全倒退了。

        回复

      2. Windows 8试图通过重新设计界面来改变这种状况，它大幅增大了多数触控目标的尺寸，并在周围添加了大量缓冲区。Windows(及其他微软应用)中许多醒目的部分至今仍保留着这些设计妥协。这种设计是可行的，许多人甚至称之为“现代”和“简洁”的设计。

        回复

    4. Gnome在触控模式下完全可用。作为键盘操作者我本就不喜欢触控模式，但亲眼见过孩子用触控屏操作Gnome时相当满意。至于单个应用，我预计要么会出现移动友好型界面，要么会诞生全新应用。预测开源领域虽难，但这是我的直觉判断。

      回复

      1. 可惜Gnome至今没有一款可用的触屏视频应用，这正是我使用它的主要原因(准确说是Phosh)。浏览器视频播放效果良好，说明技术上完全可行。

        回复

    5. 这可能主要针对笔记本上的Android系统。它们正在取代ChromeOS。

      回复

      1. 还有连接桌面扩展坞的安卓手机。

        回复

    6. “桌面交互范式(鼠标/键盘)和界面布局在手机上毫无意义。”

      恰恰相反，当用户将相关HID设备连接至性能足够的智能手机时，这些范式反而至关重要。这还包括脱离线缆状态下的高精度操作，例如通过适配触控笔实现等功能。

      回复

    7. 核心优势远不止于此。真正价值在于将手机连接底座后，能在设备上直接通过桌面级环境编辑当日拍摄的照片或视频，彻底免除文件传输至独立编辑系统的环节。手机本身便成为完整的创意工作站，可随时同步至云端。

      回复

    8. 何乐不为？融合式桌面应用能在小屏幕显示时自动调整界面布局。

      回复

    9. 安卓在平板上简直糟糕透顶！虽然我不太喜欢Linux，但若能在带触控笔的平板上用它替代安卓，那绝对是种享受。

      回复

  10. 天啊，光是把桌面版Linux的图形界面移植到桌面Linux系统都够呛

    回复

  11. 注意谷歌不允许你安装自选发行版——只能用他们准备的Debian系统。今天你可能有虚拟机内的root权限，明天就可能没了。

    当然，要运行虚拟机(比如开发竞争应用时)，你需要特殊系统权限——而获取该权限必然导致设备失去“完整性”状态。

    回复

  12. 迫不及待想用GrapheneOS处理桌面任务啦 😀

    回复

  13. 遗憾的是，Android 16的Linux应用开发者已屏蔽了GPU支持。

    回复

  14. 界面流畅何时需要GPU加速？Linux桌面显然不需要。如今许多智能手机已是性能强劲的(非通用型)计算机；难道仅因能耗/电池限制就无法成为实用计算机？

    但更关键的是：这有什么意义？Android已是死生态。智能手机生态同样垂死。谷歌刚宣布禁止任何人开发应用——除非支付保护费，否则普通用户无法运行你的程序，还得冒着个人信息泄露和政府打压的风险。这和苹果如出一辙。在“自己的”智能手机上，你甚至无法运行自主开发的软件。

    唯一可能促使开发者继续为这类平台编程的动机，就是有人付钱。这必然导致软件质量低劣。智能手机平台将彻底商业化，所有“为解决自身需求而开发的软件”都将消失。它们终将成为你无法掌控的华丽银行/视频/导航/购物终端。

    回复

    1. >安卓是个死去的生态系统。智能手机是个死去的生态系统。

      智能手机即将成为我们的法定数字身份。虽然对此我并不十分欣喜，但确实看到其必然性——毕竟尚未出现更好的替代方案。至少目前存在两个平台而非单一选择。

      回复

      1. > 毕竟尚未出现更好的替代方案。

        其实始终存在一个绝佳的替代方案：那就是根本不需要“数字身份”。

        网络匿名与伪匿名机制始终有效，并将持续发挥作用。我们无需通过设备认证来验证你是否运行特定厂商的特定操作系统、是否安装特定应用(或未安装)才能与数字世界交互。自90年代起，人们便通过计算机网页浏览器在缺乏此类技术的情况下使用数字服务。

        若数字身份确属必需(我认为并非如此)，至少不应将其捆绑在专有硬件上运行的专有封闭操作系统——这种硬件既非你所有也非你掌控。我宁愿将“法定数字身份”设为由我掌控的公私钥对，而非绑定于特定设备。

        回复

        1. > 我们无需通过设备认证来验证你是否运行特定厂商的特定操作系统，是否安装特定应用(或未安装)才能与数字世界交互。

          这些都不需要。只需你的身份凭证。

          回复

      2. > 智能手机将成为我们的法定数字身份。

        这绝非“板上钉钉”之事，如此表述实属谬误。即便生活因此极度不便，我个人也必将拒绝此类强制要求。(我认识的其他人正纷纷弃用科技巨头智能手机，且无意回归。)

        我们不能将身份证件这类核心事物交给巨头企业掌控，这只会加剧它们对政府(即民众)的支配力。尽管我对近期许多政府举措不满，但至少它们名义上还需承担责任！

        回复

        1. 我说的是必然趋势而非既定事实。政府可能会提供某种替代方案——就像现在乘飞机时，你可以拒绝面部扫描，但替代方案就是去另一条队伍排队。

          我能想到的唯一替代方案就是记住一个长密码。

          回复

    2. 我理解你的观点，但> 智能手机生态已死。这句话并不准确。

      谷歌和苹果之所以敢这么做，是因为他们深知自己处于双寡头垄断地位。当他们持续采取此类举措时，我期待会有其他力量挺身而出，为用户提供更优质的服务。

      > 开发者坚持为这类平台开发软件的唯一动机就是有人付费支持。你听说过F-Droid吗？至少在安卓生态中，这种说法并不成立。我们不能让负面案例成为唯一范例。

      回复

    3. 据我所知，你说的至少一半内容根本不属实。安卓系统并未消亡。或许基于你的价值观它已死，但这改变不了大量用户仍在使用并持续开发的事实。请别再夸大其词了。

      回复

      1. >沦为你无法掌控的华丽银行/视频/导航/购物终端

        咦？我明明已对观点做了限定，你却在附和我的限定条件。没错，人们会继续使用它们，企业也会持续开发。但它们已不再是通用计算机。如果你是个真正的极客，我怀疑你根本不想用它们来搞计算。不过大家需要时间才能意识到新形势。就像当初大家意识到社交媒体问题也花了些时间。https://xkcd.com/743/

        回复

    4. > 在Linux桌面环境中绝非如此。

      …事实并非如此，你上次尝试日常使用llvmpipe渲染的桌面是什么时候？

      回复

      1. 是的，直到上个月我才发现自己一直在这么做——因为搞砸了驱动却浑然不觉。其实挺好的。说真的，直到偶然打开KDE的“关于”对话框，它欢快地告知我正在使用llvmpipe时才注意到。后来修复后真正启用了GPU…现在我完全感受不到差异了。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：