Termux 是什么

系列上一篇文章介绍了 ADB：一条由 PC 指向手机系统层的调试通道，适合安装应用、注入输入、修改系统设置这类系统级操作。如果目标是把旧手机当成一台长期运行的 Linux 工作机，在上面跑 Python 脚本、定时任务、自建服务，ADB 就不够了——系统层通道没有提供开发环境，系统的 SELinux 沙箱（Android 强制访问控制框架，限制每个应用能访问的文件与系统资源）也不允许常规方式安装 GNU 工具链。这个需求由 Termux 补上：一个普通的 Android 应用，安装后提供完整的 Linux 终端环境，内置 bash、apt 包管理器和上百个常用工具，还能通过 apt 继续安装 Python、git、openssh 等几乎所有主流命令行软件。

初次接触容易把 Termux 理解成虚拟机，实际上它比虚拟机轻巧得多。虚拟机需要模拟硬件、运行独立内核，Termux 没有任何虚拟化层，拆开看只有三层：

  • 内核层：Termux 里的所有进程（bash、python、sshd）在内核眼中就是普通 Android 进程，与微信属于同一类，共享同一个 Linux 内核，没有独立内核，性能接近原生。
  • 用户空间层：Termux 的 APK 里打包了一整套 Linux 用户空间，bash、coreutils、apt 以及后续安装的 Python、git 都是针对 Android 交叉编译的 ARM 原生程序，安装在应用私有目录下。
  • 隔离边界：限制 Termux 的不是虚拟化技术，而是 Android 的应用沙箱——它被限制在自己的数据目录内，读不了其他应用的数据，写不了系统分区，这就是无 root 环境的物理含义。

准确的类比是 Windows 上解压即用的便携版 Linux 工具链（Git Bash、msys2 这类），外加一个完整的包管理器。它带来的体验之所以像一台新系统——独立的文件树、独立的用户、独立的软件仓库——全部来自目录层面的组织方式，而不是系统层面的隔离。

Termux 的目录结构有一个关键约定：它的根不是系统根目录，而是应用私有目录下的 $PREFIX（通常是 /data/data/com.termux/files/usr），$HOME 指向旁边的 files/home。配置软件源、装包、写脚本时记住这个前缀，就能理解为什么某些 Linux 教程里改 /etc/xxx 的步骤要换成改 $PREFIX/etc/xxx。这些路径与手机本身文件系统的关系，下一节展开。

文件系统：共用与隔离

Termux 没有独立的文件系统。Termux 里的所有路径都是 Android 数据分区上的真实路径：$PREFIX 就是 /data/data/com.termux/files/usr，与微信等应用的数据目录位于同一分区、同一棵文件树上。上一节说的”独立文件树”，本质是把应用私有目录组织成 Linux 的目录层级，而不是挂载出另一套存储。这个事实带来一个容易忽略的后果：Termux 的数据就是普通应用数据，卸载 Termux 时 /data/data/com.termux 整个被 Android 清空，”独立系统”并不能保护里面的文件。

与手机系统共用一棵文件树的同时，Termux 的可见范围分三类区域：

  • 私有区：$HOME 与 $PREFIX 所在的 /data/data/com.termux，仅 Termux 自己可读写，完整支持权限修改、设备文件和可执行位，Termux 的脚本与软件都应放在这里。
  • 共享区：即手机相册、下载目录所在的共享存储（/sdcard），运行 termux-setup-storage 授权后即可访问，与所有应用共用；受 Android 存储模拟层限制，这里的文件不支持权限修改，也没有可执行位。
  • 系统区：/system 分区全程只读，其他应用的私有目录完全不可见；/proc、/dev 这类内核提供的目录与全系统共用。

共享区的访问通过 termux-setup-storage 完成，它申请存储权限并在 $HOME 下生成一组软链接：

1
2
3
4
5
termux-setup-storage   # 手机上会弹出存储权限申请，允许即可
ls -l ~/storage
# shared -> /storage/emulated/0      # 共享存储根目录
# downloads -> /storage/emulated/0/Download
# dcim、pictures、music、movies      # 照片、视频、音乐等标准目录

两个实战提醒：从电脑 push 到手机或从相册拿到的脚本、二进制，必须先移到 $HOME 下再执行，共享存储上的文件没有可执行位；反过来，想让 Termux 里的产物（照片、下载的文件）被其他应用看到，要写到 ~/storage 对应目录里，而不是 $HOME。

安装与基础配置

安装渠道的选择比安装本身更重要。Termux 曾经上架 Google Play，但自 Android 10 后 Play 商店版本不再更新，处于废弃状态，官方推荐渠道是 F-Droid（一个只收录开源应用的 Android 应用商店，无需账号即可下载）与 GitHub Releases。这两个渠道的版本可以直接通过上一篇文章的 adb install 安装，推荐直接下载 APK：在电脑上从 GitHub Releases 页面下载对应架构的 APK，执行：

1
2
# 手机已按 ADB 文章开启无线调试并连接
adb install termux-app_v0.118.3+github-debug_arm64-v8a.apk

F-Droid 与 GitHub 版本签名一致，可以互相覆盖升级，不要与 Play 商店旧版本混装。Termux 之外还有一系列以”Termux:”命名的官方插件（下一节展开），它们的 APK 同样必须与主应用来自同一渠道。

首次打开是一个纯净终端，先更新软件源并升级全部软件包：

1
pkg update && pkg upgrade -y   # pkg 是 apt 的薄封装，参数一致

国内网络环境下官方源速度慢，换成国内镜像（以清华 TUNA 为例，地址见参考资料）：

1
sed -i 's@^\(deb.*stable main\)$@#\1\ndeb https://mirrors.tuna.tsinghua.edu.cn/termux/apt/termux-main stable main@' $PREFIX/etc/apt/sources.list

默认源之外还有扩展仓库，按需启用：

1
pkg install root-repo x11-repo   # 启用扩展仓库，proot（一种无 root 的用户空间虚拟化工具，可模拟 root 文件系统权限）等包位于其中

然后安装常用工具：

1
pkg install openssh python git vim termux-api

这里的 termux-api 是一个软件包（命令行工具集），与下一节介绍的 Termux:API 插件是配套关系，装齐两者设备功能调用才能工作。

官方插件

围绕 Termux 本体，官方维护了一系列以”Termux:”命名的插件应用。它们各自是独立的 APK，却全部声明共享用户 ID com.termux 并使用同一证书签名——Android 规定共享用户 ID 的应用必须同签名，因此插件与主应用共享同一个 Linux UID，可以直接互访 /data/data/com.termux 私有目录、通过 intent（Android 进程间通信机制，用于在不同应用间传递请求与数据）互相调用。这个机制解释了两条安装纪律：插件必须与主应用来自同一渠道（F-Droid 与 GitHub 的签名不同，混装直接安装失败），且主应用必须先行安装。按功能划分，官方插件覆盖四类需求：硬件访问、生命周期钩子、人机入口与外观定制。

Termux:API

Termux 应用本身运行在沙箱里，没有权限直接使用摄像头、麦克风等设备。Termux:API 插件单独成 app 的原因正在于 Android 的权限模型：敏感权限按应用授予，摄像头、麦克风、位置这些权限由 Termux:API 持有，Termux 通过它代为调用设备能力。使用时两端都要装：手机上装 Termux:API 插件 APK，Termux 里再装同名软件包提供命令行工具：

1
pkg install termux-api

调用链路是：终端里的 termux-camera-photo 等命令解析参数后，把请求发送给 Termux:API 插件，插件通过 Android 标准接口完成实际操作，再把结果交回终端。摄像头拍照、麦克风录音、扬声器语音合成都靠这套桥接完成：

1
2
3
4
termux-camera-photo -c 0 photo.jpg    # 调用摄像头拍照
termux-microphone-record -d           # 停止麦克风录音
termux-tts-speak "Hello"              # 调用扬声器文字转语音
termux-battery-status                 # 查询电量与充电状态

只装其一无法工作：没装插件，命令会永久挂起等待响应；没装软件包，命令根本不存在。这套设计也划出了能力上限：普通应用能做的事（拍照、录音、通知、传感器）都可以从命令行驱动，普通应用不能做的事（读取其他应用数据、修改系统设置）Termux 同样做不到，那部分仍属于 ADB 的领地。

Termux:Boot

Android 重启后一切应用进程归零，Termux:Boot 补上开机自启：它注册了系统开机广播，开机时按文件名顺序执行 ~/.termux/boot/ 目录下的脚本。使用分三步：

  • 安装 Termux:Boot 插件 APK，装完必须点开一次它的图标，开机广播接收器才会注册生效，漏掉这步是最常见的”配好了却不执行”。
  • 在 Termux 中创建 ~/.termux/boot/ 目录，放入启动脚本，多个脚本按文件名顺序执行。
  • 脚本第一行放 termux-wake-lock，让设备开机即持有唤醒锁，与保活机制衔接。

一个典型的开机脚本（启动 sshd 并防止休眠）：

1
2
3
#!/data/data/com.termux/files/usr/bin/sh
termux-wake-lock
sshd

需要说明它的能力边界：Termux:Boot 只在开机时刻执行一次脚本，进程之后被系统杀掉时它不会负责重新拉起——防杀靠的是保活配置，自启只管重启后的第一棒。

其他插件

剩余官方插件按用途选择安装：

  • Termux:Widget：在桌面生成小部件与快捷方式，一键运行 ~/.shortcuts/ 下的脚本。
  • Termux:Float：让 Termux 以悬浮窗形式运行，在其他应用上方使用终端。
  • Termux:Styling：为终端提供配色方案与字体，纯外观定制。
  • Termux:Tasker：让 Tasker 等自动化应用触发 Termux 脚本，衔接手机自动化流程。

社区生态里还有 Termux:GUI（命令行程序调用原生 Android 界面组件）与 Termux:X11（在手机上运行完整 X server 以承载 Linux GUI 程序）两个活跃插件，本篇场景用不到，留待需要图形界面的后续文章再展开。

SSH 远程连接

手机改造的典型工作方式是电脑写代码、手机常驻运行，SSH 是这条工作流的入口。在 Termux 中启动 sshd：

1
sshd    # 无输出即启动成功，监听 8022 端口

8022 是 Termux sshd 的默认端口。Android 规定普通应用不能绑定 1024 以下的特权端口，所以 Termux 的服务一律使用高位端口，8022 是社区形成的惯例，可以在 sshd_config 中修改。在手机上用 ifconfig 或 termux-wifi-connectioninfo 查询局域网 IP 后，电脑即可连接：

1
ssh -p 8022 <手机局域网IP>    # 用户名无需指定，sshd 直接落到 Termux 用户

Termux 的 SSH 与常见服务器 SSH 有一个细节差异：它默认开启密码认证，用 passwd 设置密码后即可登录，但公钥认证是更安全的方式，推荐配置公钥后关闭密码认证。把电脑公钥追加到手机的 authorized_keys（Termux 支持 ssh-copy-id 时也可以直接用它）：

1
2
# 在电脑上执行，HOST 换成手机 IP；Termux 默认开启密码认证，首次可用密码登录
cat ~/.ssh/id_ed25519.pub | ssh -p 8022 <手机IP> "cat >> ~/.ssh/authorized_keys"

配好公钥后建议关闭密码认证：编辑 $PREFIX/etc/ssh/sshd_config 将 PasswordAuthentication 改为 no，执行 pkill sshd 后重新运行 sshd 生效。

连上之后就是一个完整的 Linux 用户空间：跑 Python、装 pip 包、git 拉代码都与普通服务器一致。需要认清的是连接的边界：登录的是 Termux 用户空间，用户是应用专属的 u0_a 系列 UID，而不是系统 shell——装不了 APK、改不了系统设置、看不了完整系统日志，这些操作回到 ADB 通道完成。

理解了两条通道的分工，就能解释它们为什么经常成对出现：ADB 负责把应用装进手机，Termux 负责让应用持续干活。上一篇文章中通过 adb install 装入 Termux 后，先在手机屏幕上点开 Termux 完成初始化，再通过 adb shell input 系列命令盲打完成 sshd 启动，之后的工作就全部转入 SSH 通道进行。

保持后台常驻

Android 为省电设计了激进的进程管理，内存紧张时随时可能回收后台应用，而 Termux 里跑的 sshd 与长驻脚本都依附于 Termux 应用进程。保活的目的不是绕开系统机制，而是按照 Android 提供的正规手段声明重要性：

  • wake lock：执行 termux-wake-lock 获取 CPU 唤醒锁，防止 CPU 息屏后休眠，对应通知栏出现的 Termux wakelock 通知。
  • 前台服务：保持 Termux 通知栏通知存在。Android 对带前台服务通知的进程最宽容；从最近任务里划掉 Termux 会终止前台服务，sshd 与其中的进程全部退出。
  • 电池优化白名单：在系统设置、电池中把 Termux 设为不受限制（或无电池优化），避免系统对后台应用额外的限制。
  • 开机自启：由上一节介绍的 Termux:Boot 承担，重启后自动执行 ~/.termux/boot/ 下的启动脚本。

四项配置的效力不同：wake lock 解决息屏休眠，前台服务解决内存回收，白名单解决额外节流，Termux:Boot 解决重启后的自启。长期无人值守的旧手机四项都需要，缺一不可。即便如此也不能掉以轻心，部分厂商 ROM（华为、小米等）有超出原生 Android 的杀后台策略，必要时在厂商自家的自启动管理中额外放行。

手机的网络环境会被 Termux 直接继承：Termux 进程的流量与普通应用走完全相同的路由，手机层用 Tailscale 建立的虚拟局域网、用 Clash 配置的代理分流，对 Termux 内的 apt、git、curl 全部自动生效，无需在 Termux 内单独配置。旧手机的远程管理（Tailscale）与网络代理（Clash）都可以在 Android 层一次配置、全局生效。

参考资料