DeepSeek Harness Android

English | 中文

app/ is an independent Capacitor Android application for running DeepSeek Harness in a local Ubuntu userspace. Once the runtime is ready, opening the app starts Harness and enters the in-app conversation directly; no external browser is required. Harness service controls, Ubuntu installation and reset, terminals, runtime source details, and optional Shizuku-backed device shell access live under Settings.

Build requirements

• Node.js ^22.19.0 || >=24.0.0, matching the current DeepSeek Harness engine range. Node.js 11.9 cannot build supported Capacitor releases or the current DeepSeek Harness upstream.
• JDK 23.0.1, with JAVA_HOME set explicitly when the system default still points to Java 8.
• Android SDK 35 and a compatible Android NDK.
• The pinned ARM64 PRoot runner and loader used by the release. The current
  release artifacts come from the Operit2 Android runtime toolchain at commit
  dc4c3a9405dc7ed3ef69b2ac9a6ace65374d77cf.

The Android WebView does not run Node.js. The installed Ubuntu environment must contain Node.js in the exact supported range ^22.19.0 || >=24.0.0; Node.js 23 is not supported by the current Harness.

Local workflow

pnpm install --frozen-lockfile
pnpm run build
pnpm run android:sync

The 0.1.7 CI release is a thin APK. The workflow builds the mobile Harness
conversation frontend, injects it into an Ubuntu 24.04 ARM64 image containing
Node.js 24.19.0 and @deepseek-ai/dsh 0.1.0-rc.6, and publishes three assets
under one v0.1.7-mobile-<run_number> tag: the APK, runtime-manifest.json,
and rootfs.bundle. The manifest contains that same Release's rootfs URL and
exact archive metadata. CI hashes the finished manifest and compiles its URL
and SHA-256 into the matching APK; generated runtime assets and transaction
backups are removed from APK assets before Gradle runs. Installing an official
Release therefore does not require entering a manifest URL or digest.

The manifest bytes must match the APK-pinned digest before parsing. The parsed
manifest then pins the rootfs URL, byte length, architecture, compression, and
SHA-256. Each HTTPS redirect is revalidated against public-destination policy,
and the final content remains digest-bound. Remote archives use an app-private
rootfs-<sha256>.part file, so an interrupted transfer can resume across app
or process restarts. A resumed response must be HTTP 206 with the exact
expected Content-Range; HTTP 200 or 416 causes a clean, verified restart from
byte zero. Network, TLS, timeout, and incomplete-transfer failures enter an
explicit error state while retaining a valid bounded partial file. The UI does
not report extraction until acquisition and archive verification have
completed.

scripts/build-embedded-runtime.py remains the deterministic image builder
used by CI and also supports an explicitly constructed embedded development
build. Embedded and remote acquisition share the same size, digest,
extraction, and atomic-promotion checks. Do not put API keys, passwords,
database credentials, signing passwords, or tokens in .env, Gradle files,
source code, manifests, URLs, or logs.

The native runner files are generated or imported separately and never
committed. A release APK packages both
lib/arm64-v8a/libdsh_proot.so and
lib/arm64-v8a/libdsh_proot_loader.so; both are required. The existing
prepare:runner flow remains available for a separately pinned runner source,
but it does not replace the provenance and license review for the exact two
binaries shipped in an APK.

The runtime manifest fields, CI pinning flow, and security boundaries are
documented in docs/ARCHITECTURE.md. See
docs/RELEASE_CHECKLIST.md before distributing an
APK or runtime asset.

Security checkpoints

• Native bridge inputs have explicit type, length, format, and state validation.
• The app has no user-facing login or Android device-credential gate. The
  conversation opens directly, while management operations remain in the
  app's Settings surface. This does not weaken the separate loopback transport
  credential described below.
• Embedded and downloaded artifacts require exact digests and byte limits;
  downloads additionally require HTTPS, resumable digest-named staging files,
  strict Range-response validation, and atomic promotion.
• Archive extraction prevents traversal and does not create device nodes. The
  exact compressed stream consumed by the extractor is counted and hashed
  again before promotion, independently enforcing the manifest's compressed
  size and SHA-256 during decompression.
• Before launching Ubuntu, the app probes the packaged PRoot runner and its
  seccomp compatibility, then requires individually validated bind mounts for
  the generated resolver file, /dev, and /proc. Startup fails closed if a
  required source, guest target, or compatibility probe is unavailable.
• Harness binds only to Android loopback; no business service is exposed on 0.0.0.0.
• Every Harness start generates a non-persistent 256-bit credential. A rootfs
  preload authenticates both HTTP and WebSocket upgrades before upstream
  handlers run, and the non-exported internal WebView answers the Basic-auth
  challenge transparently. An open TCP port alone is not considered ready: two
  loopback probes separated by a stability interval must return HTTP 401 with
  the exact expected Basic realm and UTF-8 challenge. The credential is never
  placed in the URL or audit log.
• Shizuku access requires the declared ShizukuProvider, a visible permission
  grant, an explicit successful UserService connection, and a user-opened
  terminal session. Settings exposes a Connect Shizuku action whenever
  permission exists but the service is disconnected. Binder or UserService
  loss clears active sessions, and connected is true only while a live
  authorized UserService binder is available.
• Reset is confined to the app-private runtime root and does not follow symbolic links.
• Owner-only audit files rotate daily and retain at least 90 days of fixed event/result codes.
• No credential, URL, command, session identifier, terminal content, or sensitive user data is written to application audit files.

Licensing

The original application source is MIT licensed. That does not replace or
weaken the licenses of packaged runtime components. Direct dependency and
runtime redistribution obligations are summarized in
THIRD_PARTY_NOTICES.md. In particular, the PRoot
runner is GPL-2.0-or-later and the referenced Operit2 source/build material is
AGPL-3.0. A distributor must provide the applicable license texts, complete
corresponding source for the exact shipped artifacts (including modifications
and the scripts needed to build them), and clear source-acquisition
instructions for as long as the applicable licenses require. The current
provenance record identifies a source revision and binary digests; it does not
claim a bit-for-bit reproducible rebuild.