原生启动 2.3 秒 · 容器启动 1.33 秒 · 108 条设备路由 · 1354 项权限声明
20 套工具链 · 真 clang / 真 JDK / 真 gradle / 双 rootfs

① 启动快 · ② 手机权限 · ③ 编译环境 · 能力清单 · 安装 · English · Deutsch

一位用户试用后的反馈，成了我们决定往哪个方向做深的依据：
「界面做得挺好，但没有编译环境和 root，能做的事还是有限。」

下面三部分，逐条拆解这三件事背后的实现。

把「快」和「能编」同时做好，是这件事里最难的一档。多数方案会先解决其中一个：

• 原生运行时快，但跑不了 glibc 程序，也没有 apk / apt；
• 容器或 rootfs能编，但启动前要先解压、挂载、初始化软件源，慢十几秒。

我们两条路都做到了快，而且容器这一层几乎不带来额外开销。

整套 Node.js 运行时被编译成 Android 原生（bionic）二进制，直接打进 APK。它不需要「搭建」——没有 rootfs 要铺、没有伪文件系统要挂、没有软件源要初始化。冷启动只剩三件事：解压（仅首启一次）、用 execve 启动 Node、等待回环端口就绪。

作为参照：基于 proot 的方案在中低端设备上容易受限于内存与启动开销，主流机型上启动通常在十几秒量级；首次手工搭建 Linux 环境则需要数分钟。

一台 3 GB 内存的手表能把整套引擎跑起来——同内存下，proot + glibc 连 rootfs 都铺不开。这不是调参调出来的，是架构差异。

从新版本开始，两条路径都注入了 Node.js 编译缓存（NODE_COMPILE_CACHE），把 JS 模块的编译产物落到磁盘，下次启动直接复用，省掉重复解析与编译。

干净 A/B 对照（同一模拟器、x86_64、各 3 轮、每轮清场）：

启动耗时减少 1111.6 ms，约 24.5%，缓存落盘体积为 15 MB。

有一个必须处理的细节：NODE_COMPILE_CACHE 是懒写盘的。不注入刷盘器时，跑完一整轮后，缓存目录也只有 16 KB——缓存等于不存在。所以我们内置了 node-compile-cache-flusher.cjs，在原生与容器两条路径中都注入它，让缓存真正落盘，达到 15 MB。

这是当前唯一还有正收益的启动优化项，已进入产线。

这是最反直觉的一条数据。

在自研容器 dsh_alpine 里，跑一条命令只要 2.4 ms；「从零 → 进 Linux → 引擎就绪」的端到端耗时中位数为 1.33 秒。

拆开看这 1.33 秒花在哪：

结论：容器这层几乎不花时间。 换任何 OS 级方案，瓶颈都在 Node 加载插件所占的那 96%，不在容器——而那 96% 恰恰是唯一无法绕过、也不该绕过的部分。

同一台设备（OPPO PLZ110 / Android 16 / 内核 6.12.38）横向对照：

我们只比需要 root 的真 chroot 慢约 1 ms（就是路径翻译与信号处理的成本），但比 proot 快 8 ~ 14 倍。

内存表现同样干净——跑引擎时与真 chroot 几乎等同（容器 180186 MB vs 真 chroot 181187 MB），容器 loader 自身 RSS 仅 1.8 MB。文件 IO 比 proot 快约 30 倍，syscall 快 2.7 倍。

换句话说：我们不是「在慢的基础上做优化」，而是把容器这一层做到了接近零开销。免 root，却有 root 级的性能。

另有一条：前端注入 polyfill，把 WebView 门槛从 Chrome 126 拉回 85——国产 ROM 常见的 96 实测可用。

有一批同类项目在某些方面做得比我们好——界面更成熟、移植适配更广。我们也承认这一点。

而「Agent 到底能替你操作多少东西」，是这一层里更难被补上、我们投入最多的部分。

我们的上限是：只要 Android 肯给，Agent 就能用。

1354 项权限声明，真机实收 432 项。提供 108 条 HTTP 路由、42 条自描述目录项，配有 21 个独立能力开关——每项能力都要用户单独点头，不是一把梭全开。

三档身份，从普通到 Root：

Root 模式下的四条自律（不是能力限制，是我们自己划的线）：

1. rm / exec / prop set / pm uninstall 默认 dry-run，必须显式传 confirm=1 才执行
2. 关键进程保护：对 init / zygote / zygote64 / system_server / surfaceflinger / servicemanager / logd / vold / netd 的操作一律拒绝
3. rm 不真删——移进隔离区 /data/local/tmp/dsh-root-trash/<batch>/，root undo <batch> 可恢复
4. 绝不修改 SELinux 策略：可执行代码里不存在 setenforce / supolicy / magiskpolicy / sepolicy-inject

dev                    # 列出 9 组能力目录
dev <能力>             # 看某个能力的用法
dev <能力> k=v         # 直接执行
dev api GET /dev/help  # 原始目录 JSON（含 params / body / limits）
dev raw                # 真实路由表（可核对目录是否漂移）

dev 是纯渲染器，从服务端拉目录，不在脚本里硬编码能力名。MCP 工具表也从同一份目录派生——42 个工具，新增端点会自动出现在工具表里，不用维护第二份清单。

这是整件事里投入产出最不对称的一块，也是我们最想强调的。

20 套工具链，一键装，装完就能编。

① 原生 C / C++ —— clang + make + cmake，能编出 .so、能编 NDK 工程。

② Java / Android —— OpenJDK 17 + gradle + aapt2 + apksigner + d8。这是一条真能打出 APK 的完整编译链，我们用它在手机上编过本项目的扩展。

这条路有一个很容易踩的坑：android-buildtools 内嵌的 gradle 启动脚本在 Android 的 toybox 环境里是开箱即坏的——/system/bin/xargs 是 toybox 版本，不剥引号，会把 "-Xmx64m" 原样传给 JVM，报 Could not find or load main class "-Xmx64m"；内嵌 JDK 还把 user.home 与 java.io.tmpdir 硬编码为某个外部环境的固定路径。我们在安装期打补丁修掉了这些问题（issue #86），现在开箱可用。

③ 更多语言 —— rustc / cargo、go、python、ruby、php、lua、perl，各自采用独立闭包安装，并进行 SHA-256 校验和原子发布。

第三条重点中，兼容性是最容易被忽略、却最实用的一层：

两条路线共用同一套引擎代码、同一个 $DSH_HOME、同一份工作区。 切换路线不需要重装、不需要重新配置、不需要第二个 App。

把两条同时打通、还都保持秒级启动，是这件事最难的地方。我们把两条都做成了开箱可用。

可选加装，默认关闭。 这是一套自研的免 root 用户态容器：

首次启动时，容器通过 self-reexec 完成 guest 用户态接管，之后运行的就是一个正常的 Linux 进程树。

两套 rootfs 任选：

实测：容器启动 31 ms；Ubuntu 冷启 2.6 ~ 4.2 秒；Alpine 冷启 0.1 秒级。Ubuntu 比 Alpine 慢一个量级，是由发行版自身开销（glibc + init 脚本链）决定的，不是加载器缺陷。

注意：这不是安全沙箱。它保证兼容性和性能，不隔离不可信代码。

编完直接起本地服务，在手机内的 WebView 中预览：

「在当前工作区建个项目，编译它，起个开发服务器，把 127.0.0.1 预览链接发我。」

Agent 会真的执行：建目录 → 写代码 → make / gradle build → 起服务 → 给你回环链接。

不提供 X11 / Wayland 桌面，图形结果走本地 HTTP + WebView 预览。

先说清楚一件事：已经有好几个同类项目在某些方面做得比我们好——界面打磨更成熟、移植适配更广、生态更热闹。这不是客套，是我们判断自己该往哪补的依据。

下面这张表不是排名，是能力侧重对照。每一列都有它擅长的场景。

我们的取舍是：不跟最好的那几个比谁界面更漂亮，而是把「真能干活」这一层补满。

如果你要的是尽快跑起来聊两句，轻量方案可能更合适；如果你要在手机上真的编译、真的操作设备，那才是我们擅长的场景。

以下是按分组列出的全部能力。前七组对应 GET /dev/help 的自描述目录（42 条目录项 / 36 个唯一路径），另附几个目录之外但真实存在的路由（/dev/help、/dev/perms/status、/dev/perms/revoke）。

每项能力都要用户单独授权，默认全关。开关保存在 capabilities 偏好设置中，键名前缀为 cap.：

门脚本是给 AI 直接调用的命令行入口，比 dev api 更省 token、更适合脚本化：

loop 执行器支持的完整动作集：

tap tap_text double_tap long_press swipe drag pinch input key launch intent scroll scroll_find scroll_collect set_switch collect repeat repeat_until back_to sleep noop

adb shell getprop ro.product.cpu.abi

arm64-v8a → 手机包；x86_64 → 模拟器包。

两个包跑的是完全同一套引擎，差别只是运行时在 APK 里还是在网络上。

1. 引导页选语言 / 朝向 / 主题
2. 选运行模式：普通（不需要 Root）/ Shizuku / Root
3. 等运行时就位（完整包已内置，只需首次解压；简单包此时联网下载）
4. 配置模型 API Key 或登录模型服务
5. 选工作区

第一次可以这样测：

「在当前工作区建个 hello.c，用 clang 编出来跑一下，把输出发我。」

到系统设置里开启 DSH Screen Tap 无障碍服务。Android 13+ 还要确认「允许完全控制设备」。App 不能静默开启这个权限，必须由你手动点。

设置里切到 Linux 模式，首次会部署 Alpine（内置，离线）或 Ubuntu（需下载约 30 MB）。两条路径共用同一份工作区与配置。

# 前置：JDK 17+、Android SDK 36、Node 22、Python 3

# 1) 收集运行时（拉 bionic 包 + 打 Android 适配补丁）
./scripts/build-runtime.sh --abi arm64-v8a --out dist/runtime-arm64-v8a.zip

# 2) 构建 APK
./gradlew :app:assembleDebug -Pabi=arm64-v8a -Ppackage=full \
  -PruntimeZip="$PWD/dist/runtime-arm64-v8a.zip"

# 输出：app/build/outputs/apk/debug/app-debug.apk

Windows Git Bash 用 gradle.bat 替代 ./gradlew。

不打包运行时（体积小，首启要下载）：

./gradlew :app:assembleDebug -Pabi=arm64-v8a -Ppackage=noruntime

运行时流水线细节见 docs/CI_RUNTIME_PIPELINE.md。

不是端侧大模型。 模型不在 APK 里，走你配置的 API 或模型服务。

不是安全沙箱。 Linux Workspace 也一样——它保证兼容性和性能，不隔离不可信代码。Root 模式下 Agent 拥有整个设备的读写能力。

有些权限静默不了（系统不让，会返回 user_confirmation_required，绝不假装成功）：无障碍服务、MediaProjection、Android 13+ 的 WiFi / 蓝牙开关、部分 OEM 的 HID Profile。

长任务不等于永不中断。 前台服务 + 监督器尽力保活，但用户强停、极端省电策略、厂商冻结后台（如 OplusHansManager）、设备重启、Root 操作杀进程都会断。断了要重新派发。

无障碍读不全所有界面。 纯 Canvas、游戏画面、部分受保护页面没有可用节点树，程序会按层降级（节点树 → OCR → 图标几何 → 帧差），但仍不能把所有图形界面变成可靠的结构化信息。

不该拿它做的事。 不要用虚拟 HID / 无障碍 / Root 绕过风控、欺骗用户、操作未授权设备。项目不提供让注入输入「不可检测」的实现。

需要 Root 吗？ 不需要。普通模式已经能跑引擎、编译、读文件、用多数常规能力；Root 只是把系统级那一层也打开。

Linux Workspace 需要 Root 吗？ 不需要。它用 seccomp 在 App 沙箱内加载 rootfs，不依赖 Root / ptrace / user namespace / chroot。

真的能在手机上编 APK 吗？ 能。OpenJDK 17 + gradle + aapt2 + apksigner + d8 全套，装 android-buildtools 扩展即可（其中的 gradle 启动脚本我们已按 issue #86 修好）。

完整包 161 MB 装了什么？ 整套 bionic Node 运行时——解压后 418.1 MB、15292 个文件。简单包只带清单，首启下载同一个 zip。

为什么不走 proot？ 它多了一层用户态翻译，还要解压 rootfs，直接吃掉启动速度。我们用 seccomp 做同样的事，省掉 ptrace 那一层：只比需要 root 的真 chroot 慢约 1 ms，比 proot 快 8~14 倍。

Alpine 和 Ubuntu 选哪个？ 默认 Alpine（小、离线、快）；需要 glibc-only 的预编译程序或 apt 生态，就选 Ubuntu。

能力「存在」但 Agent 不知道？ 五个条件必须全部满足：① 实现已注册进桥；② 已登记进能力目录；③ 能力开关已由用户授权；④ 环境说明书已升级；⑤ 引擎已重启。自检：

dev
dev api GET /dev/help
dev api GET /dev/routes

怎么从电脑访问手机 WebUI？ 在设置里开启局域网 WebUI，启动代理，配合 6 位一次性验证码访问。这暴露的是能操作文件、执行命令的 Agent，只在可信网络用，用完就关。

和手工搭 Linux 环境能一起用吗？ 能。跑的是同一个引擎，差别只在运行层。

独立社区项目，与 DeepSeek 官方无隶属关系。

只在你拥有或明确获授权的设备上使用。普通 / Shizuku / Root 三档模式的系统边界完全不同；Root 模式下 Agent 生成的命令可能修改或删除系统文件、应用数据、网络规则、设备配置。

使用者自行承担以下风险及后果：数据丢失、应用或系统损坏、设备无法启动、账号或服务条款风险，以及 Root / Shizuku / 无障碍 / 自动化带来的后果。

模型服务商的 API 使用、数据处理、计费规则由你配置的服务端点决定。

• GitHub Issues
• QQ 群：1128769016
• Telegram

提 issue 请附：设备型号、Android 版本、CPU ABI、版本号、当前运行模式、相关权限状态、logcat、最小复现步骤、失败时的原始输出。

感谢所有提 Issue、提供复现日志、参与真机测试、提交 PR 的贡献者。完整名单见 Contributors。

也要感谢上游与生态：DeepSeek Harness、AOSP、bionic 工具链、Node.js、ripgrep、OpenSSH、SQLite、FFmpeg、llama.cpp。

除特别声明外，仓库内容（Kotlin、Java、XML、脚本、探针）均使用 MIT License。

app/src/main/cpp/dsh_alpine.c 及其运行时实现使用专有许可证，条款见 dsh-linux-runtime LICENSE。专有许可不等同于仓库根的 MIT。 第三方组件原始许可证见 NOTICE。

修改 dsh_alpine 时必须遵守其专有许可证，且不得引入 GPL / AGPL 或与本项目许可冲突的代码。