Termux 安卓终端环境搭建与后台保活指南

Termux 是一个运行在 Android 上的终端模拟器与 Linux 环境，它让手机可以执行 pkg、apt 风格的包管理命令，运行 Python、Node.js、Rust 等语言工具链，并通过 SSH 对外提供访问入口。它解决的问题很具体：把每天随身携带的手机变成一台随时在线的小型服务器，用来跑脚本、处理本地文件、托管轻量服务，或者承载一个能在命令行里直接读写文件、执行命令的 CLI Agent。适合的读者是手头有一台 Android 手机、不打算 root 也不打算刷机、希望用命令行完成日常开发或自动化任务的人。需要注意的是，Termux 的能力边界受 Android 系统本身的进程管理策略限制，环境搭好只是第一步，让它不被系统杀掉才是长期可用的关键。

准备工作

设备与系统前提

整个过程不需要 root 权限，也不需要解锁 Bootloader 或刷入第三方 ROM。需要确认的是：

• Android 版本较新，能够访问「开发者选项」中的子进程限制开关。较老的系统可能没有这一项，属于正常现象。
• 手机有稳定的网络连接，首次安装依赖包时需要下载数百 MB 的内容。
• 预留足够的存储空间。Python、clang、rust 这些包体积不小，加上后续的 nodejs 与各类工具，建议至少留出数 GB 空闲空间。

安装 Termux 与配套插件

安装来源是这一步唯一需要留心的地方。应用商店里的版本已经停止维护，而不同分发渠道的安装包使用不同的签名私钥。如果先装了某个渠道的版本，之后再去装 Termux:API、Termux:Boot 这类插件，会因为签名不一致而安装失败。因此建议统一从同一个来源获取终端本体和全部插件。

需要安装的组件有三个：

• termux-app：终端本体，提供 shell 环境和包管理。
• termux-api：插件，让终端可以调用手机的通知栏、剪贴板、震动等系统能力。
• termux-boot：插件，用于在开机后自动拉起后台服务。

三个组件必须来自同一签名来源，否则插件无法被终端识别。

初始化环境

首次打开 Termux 后，先做三件事：申请存储权限、切换软件源、升级基础组件。

# 1. 申请存储权限，允许终端访问手机本地文件
termux-setup-storage

# 2. 更换软件源，在列表中选择国内镜像后回车确认
termux-change-repo

# 3. 升级基础系统组件
pkg update && pkg upgrade -y

termux-setup-storage 执行时系统会弹出权限对话框，需要手动允许。执行成功后，手机共享存储会以符号链接的形式出现在 ~/storage 目录下，之后脚本读写手机文件都通过这个路径。

termux-change-repo 会给出一个可选的镜像列表，用方向键移动、空格键选中，回车确认。换源的意义在于后续 pkg install 的下载速度，源选得合适，装依赖的时间会明显缩短。

操作步骤

第一步：安装 Python 与编译依赖

很多命令行工具在 Android 上没有预编译包，需要本地编译，所以编译器和构建工具要提前装好。

pkg install -y python clang cmake rust git

这一步耗时较长，rust 和 clang 的体积都不小。安装过程中如果出现询问是否继续的提示，输入 y 确认。

第二步：部署 CLI Agent

在手机的小屏幕上逐条敲命令配置环境比较费劲，更省事的思路是先把核心 Agent 装好，剩下的工具链交给它自己去装。以 Hermes Agent 为例，它自带终端执行、任务规划和文件读写能力，并且针对 Termux 环境做了适配。

# 拉取源码
git clone ~/.hermes/hermes-agent
cd ~/.hermes/hermes-agent

# 使用 termux 特性安装，避免拉取不兼容的桌面依赖
pip install -e .[termux] -c constraints-termux.txt

安装时指定 [termux] 这个 extra 很关键。桌面环境下的依赖在 Android 上通常无法编译或运行，直接全量安装会引入一堆不兼容的包。约束文件 constraints-termux.txt 的作用是锁定那些在 Termux 上有已知兼容问题的依赖版本。

安装完成后直接运行：

hermes

首次启动会进入交互式引导流程，依次完成：选择模型提供商、填入 API Key、选择具体模型。这些配置会写入本地配置文件，之后不需要手工编辑。想切换模型或调整参数，在对话中输入 /config 或 /model 即可。

关于模型提供商的选择，不同服务在计费方式、推理能力和代码能力上各有侧重，按量计费的方案通常更适合这种低频、突发式的使用场景。具体价格与可用模型请以各服务商官网当前信息为准。

第三步：用 Agent 安装开发工具链

环境配好后，可以直接在终端里用自然语言让 Agent 批量安装工具。例如输入这样一段指令：

帮我把日常开发需要的工具装上：nodejs、rust、uv、git、jq、ripgrep、yazi、tmux、neovim，以及 openssh、termux-services、termux-api 几个系统包。

Agent 会在后台自动执行对应的 pkg install 命令并处理过程中的确认提示。其中几个包的作用值得说明：

• openssh：提供 sshd，让手机可以作为 SSH 服务端被外部连接。
• termux-services：提供类似 systemd 的服务管理能力，用于让 sshd 等进程常驻。
• termux-api：命令行侧的支持包，配合前面安装的 Termux:API 插件才能调用通知、剪贴板等能力。
• tmux：会话保持，SSH 断开后进程不中断。
• ripgrep、jq：文本搜索与 JSON 处理，处理日志和结构化数据时很常用。

第四步：配置后台保活

Android 的进程查杀机制是让手机充当服务器时最主要的障碍。典型表现是手机息屏几分钟后，后台进程被冻结，SSH 连接断开，正在跑的脚本被直接掐断。要让它稳定在线，需要同时处理三个层面。

省电策略设为无限制。长按 Termux 图标进入应用信息，找到省电策略，改为「无限制」。这一步阻止系统在息屏后对应用做省电级别的限制。

关闭锁屏清理。在系统自带的手机管家或电池设置中，找到「锁屏后清理内存」一类的选项并关闭。很多设备息屏十几分钟就掉线，根因就在这个开关上。

停用子进程限制。进入开发者选项，找到「停用子进程限制」（Disable child process restrictions）并打开。这一项对应 Android 底层的 Phantom Process Killer，它会在应用派生出过多子进程时强制终止，对需要 fork 大量进程的编译任务和 Agent 执行流程影响很大。

第五步：静音音频保活方案

如果完成上述三层配置后仍然遇到后台留存问题，还有一条思路：利用 Android 对媒体音频应用的天然后台豁免。让 Termux 在后台循环播放一段静音音频，借此获取音频焦点，从而获得更宽松的后台存活条件。

这个方案有一个明确的副作用需要处理。如果无脑循环播放，当用户戴着蓝牙耳机听歌或看视频时，这段静音音频会抢占耳机的 A2DP 蓝牙通道，表现为耳机突然没声音，或者音频输出设备来回跳。因此脚本里必须加入蓝牙状态判断：检测到当前连着蓝牙耳机就暂停播放，把通道让出去；耳机断开后再恢复播放。

先生成一段 1 分钟的静音音频：

ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono -t 60 -q:a 9 -acodec pcm_s16le ~/.termux/quiet_1min.wav

参数含义：anullsrc 生成空音频源，采样率 44100 Hz，单声道；-t 60 指定时长 60 秒；-q:a 9 是音频质量参数；输出为 PCM 16 位小端格式的 WAV 文件。文件放在 ~/.termux/ 目录下便于统一管理。

接着编写保活脚本 ~/.termux/scripts/keepalive.sh，逻辑上包含三部分：

• 循环检测蓝牙连接状态。可以通过 termux-api 提供的蓝牙相关命令，或者读取系统状态文件来判断当前是否有蓝牙音频设备连接。
• 未连接蓝牙时，用播放器循环播放静音文件。播放器可以选择 termux-media-player 或 ffplay，前者更轻量。
• 检测到蓝牙连接时，先终止播放进程，等待一段时间后重新检测；蓝牙断开后重新启动播放。

脚本需要赋予执行权限：

chmod +x ~/.termux/scripts/keepalive.sh

如果希望开机自动运行，可以配合 termux-boot 插件，把脚本放到 ~/.termux/boot/ 目录下。该目录中的脚本会在设备启动后被自动执行。

一个完整示例

下面把从零开始到环境可用的完整流程串一遍。假设手机已经装好 Termux 本体、Termux:API 和 Termux:Boot 三个组件，且签名一致。

# 1. 初始化：存储权限、换源、升级
termux-setup-storage
termux-change-repo
pkg update && pkg upgrade -y

# 2. 安装 Python 与编译依赖
pkg install -y python clang cmake rust git

# 3. 部署 Agent
git clone ~/.hermes/hermes-agent
cd ~/.hermes/hermes-agent
pip install -e .[termux] -c constraints-termux.txt

# 4. 首次启动，按引导选择提供商、填 Key、选模型
hermes

# 5. 在 Agent 对话中让它安装工具链
#    输入：帮我把日常开发需要的工具装上：nodejs, rust, uv, git, jq,
#    ripgrep, yazi, tmux, neovim，以及 openssh、termux-services、termux-api

# 6. 生成静音保活音频
ffmpeg -f lavfi -i anullsrc=r=44100:cl=mono -t 60 -q:a 9 -acodec pcm_s16le ~/.termux/quiet_1min.wav

# 7. 编写并授权保活脚本
chmod +x ~/.termux/scripts/keepalive.sh

# 8. 启动 SSH 服务，从其他设备连接
sshd
ssh -p 8022 用户名@手机IP

完成之后，手机就具备了被外部 SSH 连接、在后台持续运行脚本、以及通过 Agent 自动执行命令的能力。实际使用中，可以在笔记本或平板上敲一行 ssh 连进来，直接测试或修改代码。

注意事项

安装来源必须统一。不同渠道的 Termux 安装包签名不同，混装会导致插件无法安装。这是整个流程里最容易踩、也最容易在后期才暴露的坑。

后台保活的三层配置缺一不可。只改省电策略而不关锁屏清理，或者只关清理而不停用子进程限制，都可能出现「看起来配好了但息屏还是掉线」的情况。建议三层全部处理完再观察。

静音音频方案会干扰蓝牙音频。这是该方案固有的副作用，不是配置错误。脚本中的蓝牙状态判断是必需的，否则用户戴耳机听歌时会遇到突然没声或音频设备跳变的问题。

Android 上的底层兼容问题客观存在。部分命令行工具依赖的底层能力在 Android 上并不完整，安装或运行时可能失败。这也是为什么安装 Agent 时要指定 [termux] 特性并使用约束文件，而不是直接全量安装依赖。

API 调用仍然需要网络。本地环境解决的是文件处理、脚本执行和工具链的问题，模型推理本身依然走网络请求。断网状态下 Agent 无法完成需要模型参与的任务。

本地处理能减少上传量。对于代码包、日志归档、开源测试集这类体积较大的文件，可以在本地用 unzip、tar、grep 先解包和过滤，只把需要分析的核心片段发给模型。这在小屏幕设备上操作起来也更方便。

termux-api 提供的能力依赖插件。通知栏弹窗、剪贴板读写、震动提醒这些功能，需要 Termux:API 插件与 termux-api 命令行包同时存在才能工作。只装其中一个不会生效。

版本、价格与配额信息请以官网当前信息为准。模型提供商的计费方式、可用模型列表、各软件包的版本号都会随时间变化，本文不涉及具体数字。