最近我做了一件挺有意思的事：把完整的 OpenClaw 直接跑进了一台安卓手机里。不是电脑上跑一个主服务，再拿手机去连。也不是“装了个壳，算是能用”。我的目标从一开始就很明确：我要让 OpenClaw 真正运行在安卓本机上，CLI 能用，Gateway 能起，WebChat 能连，模型能正常调用。装进手机的目的就是减少运营成本、做到真正的口袋Openclaw，可以直接使用手机蜂窝摆脱各种配置，最后它确实跑通了。但这个过程跟“装个 Termux 然后 npm install”完全不是一回事。真正难的地方在于：安卓不是标准桌面 Linux，很多默认成立的运行假设，到这里都要重新验证。如果你也想把全量 OpenClaw 塞进安卓手机，希望这篇能帮你少踩很多坑。一、我的目标不是“装上”，而是“真的能用”
先说清楚标准。
我这里说的“跑起来”，不是指某条命令能执行，而是至少满足下面几件事：
openclaw
CLI 能正常工作
Gateway 能稳定启动
WebChat / Dashboard 能连接
模型配置可用
整体尽量在手机本机完成运行
也就是说，我要解决的不是安装问题，而是落地问题。
二、我的前置环境
我这次的机器是一台已经完成这些前置条件的安卓手机：
Bootloader 已解锁
已 Root
已安装 Termux
可通过 adb 从电脑辅助操作
这里我不展开 Root 教程，因为本文重点不是刷机，而是：
Root 以后，怎么把 OpenClaw 真正修到可用。
Root 的意义很直接：后面我需要处理安卓上的进程环境、目录权限、兼容层和本地服务，如果没有 Root，很多地方会非常被动。
三、先确认设备和 Termux 环境
我习惯先从最基础的连通性确认开始，避免后面排障时把问题归错地方。
先看设备是否在线：
adb devices
如果能看到设备状态是 device，说明 ADB 通路正常。
接着确认 Termux 已安装，并能以 Termux 用户身份执行命令。我这次为了稳定复用环境，统一使用了一层干净的环境变量包装。下面这个写法我后面会反复用到：
adb shell <<'EOF'su 10385 -c'env -i \HOME=/data/data/com.termux/files/home \PREFIX=/data/data/com.termux/files/usr \TMPDIR=/data/data/com.termux/files/usr/tmp \PATH=/data/data/com.termux/files/home/.openclaw-android/bin:/data/data/com.termux/files/home/.local/bin:/data/data/com.termux/files/usr/bin:/data/data/com.termux/files/usr/bin/applets:/system/bin \TERM=xterm-256color \/data/data/com.termux/files/usr/bin/bash -lc '"'"'pwd && node -v && npm -v'"'"''EOF
这里有个注意点：我用的是 su 10385，这是我这台机器上Termux 应用用户的 UID。你的机器不一定一样，不能无脑照抄。如果 UID 不同，要先自己确认。
四、安装 OpenClaw：这一步不难，难的是后面
安装本身其实没那么戏剧化。关键是别把“装上了”误判成“能用了”。
我在 Termux 里把 OpenClaw 安装好之后，先确认版本：
然后初始化配置，确认配置文件位置：
openclaw config fileopenclaw config validate
如果你已经准备接模型，这一步就可以先把提供商和模型写进去。以 DeepSeek 为例，我当时的做法是把 Key 配成 provider，然后指定默认模型。为了安全，下面我用占位符表示：
openclaw configsetproviders.deepseek.apiKey'"sk-你的Key"'openclaw configsetagents.defaults.model'"deepseek/deepseek-v4-flash"'
注意这里不要把真实 Key 写进公开文章、截图或者 Git 仓库。这类内容一旦公开，后面就是纯粹的善后劳动。
五、第一次真正的障碍：Gateway 启动不起来
到这一步，CLI 是能跑的，配置也能写。但问题来了：Gateway 起不来。
我先看状态：
再直接前台启动，观察日志：
openclaw gateway run --bindloopback --port 18789 --verbose
我习惯这样看问题，因为“起不来”本身没意义，关键是它卡在哪一层。
后来我定位到第一个核心问题：OpenClaw 的绑定地址探测逻辑，在安卓环境下误判了。
正常情况下，程序会探测某个 Host 是否可绑定，再决定最终监听地址。但在安卓 Termux 里，这层探测并不可靠，结果是它把本该老老实实监听本地回环地址的服务，导向了错误分支。
我的处理方式很直接：不要再让它在安卓上做这类不可靠探测，而是让它明确返回我们指定的绑定地址。
我实际修的是这个文件：
/data/data/com.termux/files/usr/lib/node_modules/openclaw/dist/net-Cm4muceK.js
我在动手前先做了备份：
cp/data/data/com.termux/files/usr/lib/node_modules/openclaw/dist/net-Cm4muceK.js \ /data/data/com.termux/files/usr/lib/node_modules/openclaw/dist/net-Cm4muceK.js.bak_codex
这里的注意事项很重要：
目录下是编译后的产物，升级后可能被覆盖
所有修改前一定先备份
这类补丁最好记清楚文件名和原因，后面方便回滚
六、第二个坑更隐蔽：127.0.0.1 居然监听失败
本来我以为第一个问题修完，Gateway 就该起来了。结果继续追日志时发现，事情没有那么简单。
服务在监听 127.0.0.1 时居然出现了异常，典型表现就是类似 EADDRNOTAVAIL 这种错误。这个信号很不对，因为本机回环地址本来应该是最稳的一层。
我干脆写了一个最小 Node 监听测试，绕开 OpenClaw 主逻辑，直接测系统行为：
node -e'require("node:net").createServer().listen(18789, "127.0.0.1", ()=>{console.log("OK"); setTimeout(()=>process.exit(0),300)}).on("error", e=>{console.error(e); process.exit(1)})'
正常情况下，它应该直接输出 OK。但我这边没有。
这就说明问题不在业务逻辑，而在运行环境。
继续往下查，我发现真正的元凶是安卓兼容层里的一个 shim，它错误接管了部分 DNS / 地址解析逻辑，结果把原本应该监听 127.0.0.1 的行为，拐到了一个根本不该去的地址上。
我最后修的是这个文件：
/data/data/com.termux/files/home/.openclaw-android/patches/glibc-compat.js
同样，先备份：
cp/data/data/com.termux/files/home/.openclaw-android/patches/glibc-compat.js \ /data/data/com.termux/files/home/.openclaw-android/patches/glibc-compat.js.bak_codex
修完之后，我重新跑最小监听测试，终于正常输出 OK。这一刻我基本就确定：网关终于有条件正常启动了。
七、Gateway 真正启动：从“能装”进入“能用”
修完上面两层问题后，我重新启动 Gateway：
openclaw gateway run --bindloopback --port 18789 --verbose
这一次，日志里终于开始出现我真正想看到的关键词：
starting HTTP serverhttp server listeninggateway ready
如果只是临时前台调试，到这一步已经很鼓舞人了。但我还需要它以服务方式稳定跑着，所以我继续看服务状态：
我这边最后确认到的结果大概是这样的：
监听地址：127.0.0.1:18789
Dashboard 地址：http://127.0.0.1:18789/
连通性探测：ok
这说明它已经不是“勉强起了一下”，而是真的作为本地服务跑起来了。
八、最后一个实际问题：WebChat token 不匹配
Gateway 起来以后，我以为基本结束了。结果打开 WebChat，又碰到了一个很现实的问题：
token mismatch
这个问题比前面的兼容性问题简单得多，本质上就是：WebChat 端保存的旧 token，和当前 Gateway 使用的 token 不一致。
我先确认当前认证模式：
openclaw config get gateway.auth
如果是 token 模式，那么最省事的方式不是继续猜旧值，而是直接重置一个新的 token。
我这边先生成一个新 token：
比如生成出来的是：
0031d92ff3fd4546d3832ad6a5d35f35b1f4b7fed7c
然后写回配置：
openclaw configsetgateway.auth.token'"0031d92ff3fd4546d3832ad6a5d35f35ba29f41f4b7fed7c"'
接着重启网关：
openclaw gateway restart --force
再检查状态：
最后在 WebChat / Control UI 里：
清掉旧 token
粘贴新 token
重新连接
到这里，WebChat 就可以正常连上了。
九、我最后跑通后的状态
到这一步，我的整条链路已经是闭环的：
OpenClaw 已安装在 Termux
CLI 正常
Gateway 正常启动
监听在本机回环地址
WebChat 可连接
token 鉴权可用
DeepSeek 模型配置完成
换句话说，这已经不是“手机上装了点东西”，而是：
我把一整套本地 AI 运行框架，真正搬进了安卓手机。
十、如果你也准备做，下面这些注意事项很重要
这部分我建议你一定保留，因为它能直接帮读者避坑。
1. 不要把“命令能跑”当成“部署成功”
openclaw --version 能输出，不代表你已经跑通了。真正的标准应该是：
openclaw gateway status 正常Dashboard 能打开WebChat 能鉴权模型能出响应2. 安卓上的问题，很多不是 OpenClaw 本身的问题
这次最难排的地方，不是 OpenClaw 配置写错了，而是：
地址绑定探测在安卓上误判
兼容层错误改写 loopback 监听行为
所以如果你碰到类似问题，优先怀疑环境差异，而不是先怀疑自己手滑。
3. 所有补丁都先备份
我这次手改的是安装目录下的产物文件。这类改动一旦出错，最怕的是你连原文件都回不去。
所以动手前至少做这两件事：
以及记下：
改了哪个文件
为什么改
改完解决了什么问题
4. Key 和 token 不要公开
教程可以写，截图可以发，思路可以讲。但下面这些内容不要原样公开：
模型 API Key
Gateway token
任何带权限的 SecretRef
Telegram / Bot 相关凭据
这不是形式主义，是真会出事。
5. 升级后要有心理准备重新补丁
我这次修的是：
OpenClaw 的分发产物
安卓兼容补丁层
一旦 OpenClaw 升级，或者相关运行层有变化，补丁很可能需要重新验证。这也是为什么我更愿意把这次过程记成“移植与排障”，而不是“安装指南”。
十一、这次折腾后，我对这件事的真实结论
回头看，我最大的感受不是“Root 真自由”，也不是“手机也能跑大活”。
而是：
把一个完整项目塞进安卓手机，最难的从来不是复制文件，而是让它原本依赖的整套运行逻辑，在另一个环境里继续成立。
这次我做成了。不是因为 OpenClaw 天然就完美适配安卓，而是因为我把那些不成立的前提，一个个找出来，再一点点补平。
所以如果要用一句话概括这次经历，我会这么说：
我不是把 OpenClaw 安装到了安卓手机上。我是把它修到了能在安卓手机上真正工作。
这两句话，差别非常大。
十二、装进手机以后，到底有什么好处
把全量 OpenClaw 装进安卓手机，最大的意义不只是“能跑”，而是把一套原本更偏桌面端、本地服务器形态的 AI 能力，真正变成了随身可携带、随时可调用的个人智能中枢。手机本身就具备常在线、随身、即时交互、传感器完整、通信能力强这些天然优势，一旦 OpenClaw 直接落在手机本机运行，它就不再只是一个聊天入口，而更像是一个长期在线的个人代理系统。这样做的好处很直接：我不需要额外带电脑，不需要总依赖远端主机，很多本地能力、消息能力和设备能力都能更自然地接进来，真正做到“人在哪，AI 就在哪”。
从应用场景上看，这种形态其实很有想象力。最基础的一层，是把手机变成一个随身 AI 工作台，我可以直接在本机调用模型、接入 WebChat、管理配置、做轻量自动化；再往上一层，它可以变成一个常驻在线的个人消息和任务中枢，比如接入 Telegram 这类渠道，让 AI 作为我随时可用的入口存在；而更有意思的一层，是OpenClaw 不只是跑在手机上，还能反过来理解和调用手机本身的能力，也就是把手机从“运行容器”变成“可操作对象”。这意味着未来它不仅能在手机里响应我，还能围绕设备本身做更多事情，比如协调本地文件、处理中转任务、联动设备功能，甚至在合适的插件和能力支持下，进一步形成“我通过 OpenClaw 使用手机，OpenClaw 也通过手机服务我”的闭环。
如果让我用一句更直白的话总结这件事，那就是：把 OpenClaw 装进手机，不只是多了一个安装位置，而是把 AI 从一个固定在桌面端的工具，变成了一个真正跟着我走、还能理解并调动我这台设备能力的移动智能节点。
