Linux

为 Waydroid 配置独立的音量增减快捷键

背景 在 Linux 桌面环境中运行 Waydroid 时，宿主机的音量控制与 Android 容器内部的媒体音量并不总是完全一致。 Waydroid 内部的 Android 媒体音量可以通过下面的命令直接设置： 其中： 但固定设置音量并不适合绑定键盘快捷键。更自然的方式是像物理音量键一样，每按一次增加或降低一级。 对应命令为： 以及： 问题在于，waydroid shell 通常需要 root 权限。如果直接将这两个命令绑定为桌面快捷键，系统无法在快捷键触发时交互式输入 sudo 密码。 最简单但风险很高的做法，是把密码写入脚本。更合理的方案，是通过 sudoers 仅放行两条完整、固定的音量命令。 设计目标 整个配置需要满足以下要求： 最终结构只有三项： 没有修改主 /etc/sudoers 文件，也没有修改 Waydroid 程序本身。 一、确认环境 首先确认当前用户名、sudo 路径以及 Waydroid 路径： 典型输出可能为： 在编写 sudoers 规则时，应使用实际查询到的绝对路径，而不是依赖 PATH 环境变量。 还可以先读取当前 Android 媒体音量： 输出类似： 这说明媒体音量命令可正常工作。 …

Linux

KDE Plasma Wayland 下 Fcitx5 输入法状态异常：一次由 Waydroid 崩溃引出的双启动竞态排查

问题现象 在 Arch Linux、KDE Plasma Wayland 和 Fcitx5 环境中，出现了一个很奇怪的输入法问题： 更奇怪的是，某次调整 Waydroid 独立窗口模式并启动 Android 应用时，整个桌面环境发生崩溃。Plasma 和 KWin 恢复后，原本无法正常切换输入状态的应用突然全部恢复正常。 随后正常关闭并重新打开 Brave，输入法仍然正常。但整机重启后，问题又重新出现。 这个现象提供了一个很重要的线索： 问题不是浏览器进程本身的临时状态，而更可能发生在 KDE Plasma Wayland 会话启动阶段。 最初的判断 由于桌面崩溃后输入法恢复，而浏览器重启后仍然保持正常，可以初步排除： 更合理的解释是： 但这仍然只是推测，需要日志和配置证据进一步验证。 只读排查 为了避免继续扰动系统，首先进行了严格的只读审计，没有修改配置、没有重启进程，也没有重新运行 Waydroid。 重点检查了以下内容： 最终发现，系统中同时存在两条 Fcitx5 启动路径。 第一条启动路径：KWin Wayland Input Method KDE Plasma Wayland 中，Fcitx5 被配置为 KWin 的输入法组件，KWin 使用类似下面的 desktop 文件启动它： …

Linux

在 KDE Wayland 中优化 Waydroid Full UI：从固定 16:10 窗口到沉浸式大屏布局

在 4K 显示器和 KDE Plasma Wayland 环境中运行 Waydroid 时，默认的 Full UI 往往会铺满整个可用桌面。对于将 Waydroid 长期作为“大尺寸横屏 Android 平板”使用的场景，这种显示方式很自然，但也可能因为界面过宽，导致部分应用布局不够协调。 一次优化尝试将 Waydroid 改成了固定的 16:10 窗口。尺寸和比例虽然更接近平板设备，但随后出现了新的问题：窗口固定在屏幕左上角，右侧和下方留下明显空白，整体观感反而不如最初的铺满状态。 最终没有继续强行控制窗口坐标，而是取消固定尺寸，并结合 KDE Panel 的 Dodge Windows 模式，实现了更自然的沉浸式显示效果。 一、环境与目标 使用环境大致如下： 显示器的物理分辨率为： 在 150% 缩放下，KDE 使用的逻辑分辨率约为： 左侧 Plasma Panel 原本固定占用： 因此普通最大化窗口最初会从： 开始显示。 二、将 Waydroid 改成 16:10 固定窗口 为了让 Waydroid 更接近常见大屏 Android …

Linux

把 Waydroid Full UI 真正变成横屏 Android 平板

前言 Waydroid 在 Linux 桌面上运行 Android 时，常见用法有两种： 本文讨论第二种场景：不启用多窗口模式，而是让整个 Waydroid 窗口表现为一台大尺寸横屏 Android 平板。 测试环境具备以下特点： 最终问题并不在分辨率、DPI 或旋转角度，而在于： Waydroid 虽然拥有足够大的屏幕尺寸，却仍向应用报告自己是普通设备，而不是平板设备。 解决办法是在 Waydroid 持久配置中，将设备类型声明为 tablet。 一、问题表现 Waydroid Full UI 本身已经可以横屏显示，Android 桌面、搜索栏和底部导航也都处于正确方向。 但部分应用仍然存在异常： 这说明问题不能简单归结为“应用不支持平板”。 二、先明确目标：不是桌面多窗口模式 Waydroid 支持让 Android 应用分别显示成 Linux 桌面窗口，例如： 但这种模式并不适合将 Waydroid 当作完整平板使用。 正确目标应当是： 因此应保持多窗口模式关闭： 三、旋转设置的误区 Android 的 user_rotation 支持四个值： 需要注意： 0 并不固定代表竖屏，它代表设备自身定义的自然方向。 如果 …

Linux

Waydroid 应用声音过小的排查与修复

问题现象 Waydroid 安装、网络和应用兼容问题处理完成后，Android 应用已经能够正常打开，视频和音乐也可以播放。 最初观察时，容易误以为 Waydroid 完全没有声音。进一步确认后发现，声音实际上存在，只是音量非常小。 宿主机本身的音频输出正常，其他 Linux 应用音量也没有异常。因此，问题并不在 PipeWire、PulseAudio、扬声器或宿主机输出设备，而在 Waydroid 内部的 Android 媒体音量。 最终检查发现，Android 的媒体音量只有： 也就是大约三分之一。 将其调整为： 之后，Waydroid 内应用音量恢复正常。 Waydroid 中存在两层音量控制 Waydroid 的声音至少涉及两层控制： 如果 Android 内部媒体音量只有 30%，即使宿主机已经设置为 100%，最终听到的声音仍然可能很小。 因此，一种比较稳定的使用方式是： 这样可以避免 Android 内部音量和 Linux 宿主机音量同时缩小，导致实际输出过低。 为什么键盘音量键可能无效 在普通 Android 手机或平板上，按音量加键通常可以直接调整媒体音量。 但在 Waydroid 独立窗口模式下，键盘上的音量键不一定会正确传递给 Android 容器。 即使 Waydroid 窗口已经获得焦点，也可能出现以下情况： 这种情况下，直接通过命令行调整 Android …

Linux

在 Arch Linux 的 Waydroid 中启用 ARM 应用兼容：从“可以安装但无法启动”到完整修复

前言 Waydroid 可以在 Linux 桌面环境中运行接近原生体验的 Android 系统。完成基础部署后，通常可以正常启动 Android、连接网络、登录 Google Play，并安装一部分应用。 但在 x86-64 Linux 主机上，经常会遇到一种典型问题： 这类问题的核心通常不在网络、Google 账号或 Play 商店，而在于 CPU 指令集架构不匹配。 本文完整记录一次在 Arch Linux、KDE Wayland 和 Waydroid Android 13 环境中，为 Waydroid 安装 Intel Houdini ARM 转译层的过程，包括： 文中的用户名、主机名、个人目录和时间戳均已替换或泛化。 一、问题现象 Waydroid 已经完成以下配置： 然而，一些常用阅读类应用在 Google Play 中显示： 此应用与当前设备不兼容。 首先检查 Linux 主机架构： 输出： 再检查 Waydroid …

Linux

Waydroid 多窗口模式导致 KDE Wayland 黑屏：为什么最终选择回退

引言 Waydroid 的多窗口模式很有吸引力。 启用后，Android 应用可以像普通 Linux 软件一样，以独立窗口出现在 KDE Plasma 桌面中。应用能够单独移动、最小化、切换和管理，不必始终面对一个完整的 Android 桌面。 理论上，这正是桌面 Linux 使用 Android 应用时最自然的体验。 然而，在某些 KDE Plasma Wayland、显卡驱动和 Waydroid 图形栈组合中，多窗口模式可能触发严重兼容问题。本次测试中，打开一个 Android 应用后，整个 KDE 桌面立即黑屏，Waydroid 随后异常退出。 最终只能关闭多窗口模式，恢复完整 Android 主界面。 一、完整界面模式与多窗口模式的区别 Waydroid 常见的两种使用方式如下。 完整界面模式 执行： 会打开一个完整的 Android 桌面。 它包含： 这种模式更接近平板电脑或安卓虚拟机。 多窗口模式 设置： 重启 session 后，Android 应用会被映射成独立的 Linux 桌面窗口。 例如： …

Linux

Waydroid 能启动却无法联网：一次从 DHCP 抓包到 firewalld 修复的完整排障

引言 Waydroid 已经能够启动，Android 桌面也能正常显示，Google 应用和系统组件均存在，但状态始终显示： Android 内部的网络接口处于 UP 状态，却没有 IPv4 地址、默认路由和 DNS 配置。浏览器、Google Play 和其他联网应用自然全部不可用。 这类问题很容易被误判为 Android 镜像损坏、Waydroid 安装不完整，甚至被建议重新初始化或重装。实际上，本次故障最终与 Android 镜像、LXC 容器和 Waydroid 本身都没有直接关系，而是宿主机防火墙没有正确放行 Waydroid 的虚拟网络接口。 整个排查过程的关键，不是反复修改配置，而是逐层确认 DHCP 数据包究竟消失在哪里。 一、故障现象 宿主环境为： Waydroid 启动后可以观察到： Android 系统本身已经完成启动： 图形界面、启动器、系统服务和应用管理器均可使用。 宿主侧也能看到： 但 Android 内部没有： 这说明问题集中在 DHCP 获取阶段。 二、不要被 FROZEN 状态误导 Waydroid 空闲时可能将容器置于冻结状态： 这并不等于容器崩溃，也不等于安装损坏。 只有在进行实时网络测试、抓包或进入 …

Network

把 DNS-01 做成一个真正可用的 Web 工具：从命令行脚本到安全的证书申请平台

为域名申请 HTTPS 证书时，HTTP-01 往往是最省事的方式。但在一些环境中，DNS-01 更合适： DNS-01 的基本原理很简单：证书机构要求申请者在指定域名下添加一条 TXT 记录，查询到正确值后，即可确认申请者拥有该域名的 DNS 控制权。 Certbot 已经能够在命令行中完成这一流程，但命令行操作并不适合所有用户。尤其是在申请根域名、多个子域名和通配符证书时，TXT 记录的管理、验证顺序、失败恢复和证书下载都会迅速变得复杂。 因此，一个围绕 DNS-01 构建的 Web 工具，价值并不在于“把命令搬到网页上”，而在于把整个异步验证过程变成一个安全、清晰、可恢复的状态机。 本文已对域名、主机、目录、端口、服务名、接口路径、文件名和部署拓扑进行抽象处理，不包含实际生产环境中的可定位信息。 一、工具的目标是什么 这个工具面向无法或不愿直接操作 Certbot 命令行的用户。 用户只需要完成几件事： 系统负责： 二、为什么不能只是给 Certbot 套一个表单 最简单的实现似乎是： 这种设计很快就会遇到问题。 Certbot 的 DNS-01 流程需要等待用户手动修改 DNS。这个过程可能持续几分钟，也可能更久。如果 HTTP 请求一直保持连接： 正确的设计应该是： 也就是说，Web 请求只负责触发和查询，不能承担整个证书申请生命周期。 三、整体架构 该工具采用常见的多层 Web 架构： 应用进程只监听本机回环地址，不直接暴露给局域网或公网。 外部入口使用现有网站下的一个应用子路径，而不是单独建立新域名。这样可以复用既有的 HTTPS 入口、访问控制和反向代理体系。 真实部署中，外部路径、内部端口、配置文件和服务名称都应视为敏感运维信息，不应出现在公开文章、截图、错误页面或前端源码中。 …

Server

在 Linux 服务器上制作一个单页自动刷新的系统监控脚本

小型服务器在同时运行 AI 服务、终端会话、备份任务和其他常驻程序时，偶尔可能出现响应迟缓，甚至完全失去连接。 服务器卡死后再查看日志，往往只能知道系统曾经发生过异常，却难以直观看到卡死前的内存、Swap、CPU 压力、I/O 压力和进程状态。 一种简单有效的办法，是制作一个固定的命令行监控脚本，在单个终端页面中集中显示关键状态，并每隔几秒自动刷新。 本文介绍一种不依赖额外监控平台的实现方式，适用于 Debian、Ubuntu、Arch Linux 等使用 systemd 的 Linux 系统。 监控内容 这个监控页面主要显示以下信息： 相比单独运行 top、free、ps 和 systemctl，单页监控更适合观察系统是否正在逐渐接近卡死状态。 创建固定脚本 以下示例将脚本安装到： 默认监控一个名为： 的 systemd 用户服务。 实际使用时，可以通过环境变量指定需要监控的服务名称。 在具有管理员权限的终端中执行： 这段安装命令会完成以下操作： 运行监控页面 假设需要监控的用户服务名为： 可以这样启动： 页面默认每两秒刷新一次。 退出时按： 修改刷新间隔 刷新间隔通过 SERVER_MONITOR_INTERVAL 环境变量控制。 每秒刷新一次： 每五秒刷新一次： 一般情况下，两秒刷新一次已经足够，同时不会产生明显额外负载。 查看一次静态快照 脚本也支持只输出一次当前状态，不进入自动刷新模式： 这种方式适合： 例如保存当前状态： 页面中的关键指标 Load average uptime …