DSHA: a DeepSeek Harness launcher that runs a full Ubuntu on Android without root

What DSHA actually solves on an Android phone

DeepSeek Harness, published as @deepseek-ai/dsh, is DeepSeek's official agent harness. The README describes it as being in the same family as Claude Code, and states that it is written for glibc Linux. Running that on Android directly runs into a list of problems the README enumerates: native modules fail to compile, link(2) is blocked by SELinux, the sandbox will not start, and the front end lays itself out for a desktop.

DSHA is not a port of the harness. It is a launcher APK that wraps those problems. Inside the package is an offline Ubuntu 24.04 arm64 rootfs, so apt works, an interactive PTY works, and modules that need compiling can be built. The intended audience is narrow and specific: someone with an arm64 Android device who wants the harness running without installing Termux, without root, and without typing a command to get started. The README states the target as Android 6+ or 11+ depending on the build, arm64-v8a only. If your phone is not arm64, nothing here applies.

proroot, the offline rootfs and the two runtimes

The runtime is the part worth understanding, because it is where DSHA departs from the usual approach. Traditional proot performs two context switches per system call. DSHA's default runtime, called proroot, instead uses LD_PRELOAD plus binary patching to do path translation inside the process. The README reports a measured result on a vivo V2352A running Android 14: a total of +58% across the key items, tar packing at +94% (the path backups take) and stat-heavy work at +82% (node module resolution). Those numbers come from the project's own testing on one device, not from an independent run.

The fallback design is the more interesting engineering choice. If the runtime files are missing, DSHA drops back to proot automatically. Three consecutive startup failures force the switch back and tell the user. The installation path itself always uses proot, so the riskier runtime is never in play while the environment is being built. Around that sit a Node.js 24 and pnpm toolchain, a foreground service so Android does not reclaim the process, and a watchdog that restarts the web UI when it dies.

State lives outside the app. Conversations, settings and attachments go to Documents/dshdata in internal storage, with a private symlink left in place, and the API key is stored through Android Keystore with AES/CBC. That layout is why an uninstall and reinstall does not necessarily take your conversations with it, and also why the backup code has to dereference those symlinks: tar stores links by default, and a restored archive on a different device would otherwise contain empty directories.

Installing DSHA and getting the web UI up

There is no build step for the user. The README's 30-second path is: download the latest APK from Releases, install it, let the first launch unpack the bundled environment (a few minutes, once), enter a DeepSeek API key on the Configuration page, then press start on the Launch page. The web UI opens by itself.

The release table gives two files, and the choice matters because the two builds share a package name and data, so they cannot be installed side by side.

# standard build: Android 11+ / arm64, uses the system WebView
dsha-0.1.5-rc2.apk          176.69 MiB

# compatibility build: Android 6+ / arm64, bundled Gecko fallback engine
dsha-0.1.5-rc2low.apk       253.23 MiB

Each APK has a .sha256 file published next to it on the release page. Verifying the download against that file is the one check worth doing before you install, since the APK is the whole product.

If you prefer not to do everything at once, the installer is split into four independent steps: rootfs, base tools, Node.js, and the harness. Each step can be reinstalled or updated on its own without re-downloading the others, and a failed or abandoned run resumes at the step it stopped on. After each step DSHA verifies the artifacts immediately rather than treating a half-finished install as success.

Where DSHA is the wrong tool

The project's own release notes are unusually direct about what has not been tested, and that is the honest starting point. The final round did not test Android 6 or 7, devices with a real 16 KiB page size, or the thedjchi-modified Shizuku manager; compatibility with that manager is based on its public protocol implementation rather than a run. Direct upgrade paths from 1.1.10 and earlier architectures were not re-verified in this round either. If you are on one of those configurations, you are outside what the maintainers claim to have exercised.

The current line is also a release candidate. The latest release is v0.1.5-rc2, published 2026-09-12, with the package name, version code 129 and signing key carried over from the accepted APK. The README notes the bundled dsh is 0.1.5-rc.2 and the Ubuntu base environment is still 10. If you need a stable branch rather than rc builds, this is not it yet.

Two further constraints are structural. The APK is large, 176.69 MiB for the standard build and 253.23 MiB for the compatibility build, because an Ubuntu rootfs is inside it. And the architecture is arm64-v8a only, with no armeabi or x86 build listed. A 32-bit device or an emulator is simply out of scope.

How DSHA differs from Termux and a plain proot distribution

The obvious alternative is Termux, optionally with a proot distribution such as proot-distro. The difference is where the work sits. With Termux you assemble the environment yourself: install the app, set up the package manager, pull a distribution, then fight the same glibc and native-module problems DSHA exists to absorb. You get full control over the filesystem and the package set, and you own every upgrade. DSHA inverts that. You get an APK with the rootfs already inside, a step installer, a verification pass after each step, and a set of self-repair scripts, but you also inherit the project's packaging decisions and its release cadence.

The runtime choice is the second difference. A conventional proot setup pays the ptrace cost on every system call, and that cost is visible in stat-heavy workloads. proroot avoids ptrace by patching in-process, which is where the reported +58% comes from, but it is newer code with an automatic fallback to proot when its files are missing or startup fails three times in a row. Termux does not have a runtime to fall back from.

The third difference is device control. DSHA ships ADB wireless pairing and keep-alive so the agent can click, swipe, screenshot, install apps and read logs without Shizuku, with the Shizuku channel kept as a secondary path. It also exposes an app bridge on 127.0.0.1:3090 for notifications, device information and user confirmation requests. Reaching that level of device access from a Termux setup means building the plumbing yourself.

Maintenance, upgrade cost and the MIT licence

The repository was last pushed on 2026-09-14 and is not archived, so the codebase is being worked on. That is not the same as a stable release channel. Three releases landed between 2026-09-07 and 2026-09-12, two of them release candidates, which tells you the API surface and packaging are still moving.

Upgrading means installing a same-signature APK over the existing one. The README advises keeping a manual backup of important data first. When the base environment is already version 10, only the managed runtime is updated; when it is the older base 9, data is protected and the environment is rebuilt. That rebuild path was exercised on an Android 17 tablet, and that is the only upgrade the notes describe as actually performed.

Two maintenance features reduce the cost of waiting for a new APK. Critical scripts can be updated incrementally from GitHub with offline signature verification, using a public key baked into the app; if the signature does not match, the whole batch is rejected. And the built-in self-check covers 23 items with one-tap repair, plus 15 self-healing and patch scripts for things like pnpm shell restoration and bundle resolution. Failure reasons for backups, installs and startups are written to disk so the self-check can read them, which is a real answer to the usual "nothing happened" report.

The licence is MIT, which is permissive and imposes no obligation on how you use the APK. Note that the repository carries a THIRD_PARTY_NOTICES.md, and that the APK bundles an Ubuntu rootfs, Node.js, pnpm and Gecko in the compatibility build, each under its own terms. MIT covers DSHA's own code; it does not relicense what is inside the package. That is a statement about what the files say, not legal advice.

Editorial conclusion

Adopt DSHA if you want the DeepSeek Harness on an arm64 Android phone with a real glibc userland and no Termux or root, and you accept that the current line is a 0.1.5 release candidate. Skip it if your device is not arm64, if you need a long-term stable branch rather than rc builds, or if you would rather control the Linux environment yourself through Termux or a proot distribution. Before you install, verify the SHA-256 of the APK against the file published beside it on the release page, confirm the package name is not already installed, and read the v0.1.5-rc2 release notes for the list of devices the final round did not cover.

Frequently asked questions

Official sources

1. DSH-APP/DSHA on GitHub
2. Issues
3. License: MIT
4. README
5. Releases