Android Dev Hub

Turn your Android phone's browser into a GUI for the Termux environment.

Android │ ▼ Chrome / Android browser │ ▼ http://127.0.0.1:8080 │ ▼ Android Dev Hub ├── 📊 Dashboard (realtime CPU / RAM / storage / versions) ├── 📁 Files (sandboxed file manager + code editor) ├── 🖥 Terminal (real PTY shell running in Termux) ├── ⚙ Processes (uid-scoped process list + safe kill) ├── 📜 Logs (realtime log streaming) ├── 📦 Projects (Phase 2) └── 🤖 Hermes (Phase 3)

Architecture

• Backend: Python + FastAPI + uvicorn (REST API)
• Realtime: WebSocket (stats, terminal PTY, processes, logs)
• Frontend: vanilla JS SPA served by the backend (mobile-first dark theme)
• Binds to 127.0.0.1 only — never exposed to LAN/internet by default.

Requirements

• Termux with Python 3.11+
• Node (optional; frontend is buildless)
• No Docker, no VPS, no laptop required.

Install

The backend needs FastAPI + uvicorn + websockets:

pip install fastapi "uvicorn[standard]" websockets

Note: psutil does NOT build on Android. Android Dev Hub reads /proc directly with the standard library instead — nothing to install.

Run

./scripts/start.sh      # start the server
./scripts/status.sh     # show RUNNING / PID / URL
./scripts/stop.sh       # stop
./scripts/open.sh       # launch Android browser to the dashboard

Then open http://127.0.0.1:8080 in your Android browser.

Security

• Server binds to 127.0.0.1 only. Do not change it to 0.0.0.0 unless you fully understand the exposure.
• The file manager is sandboxed to two roots:
  • /storage/emulated/0/AndroidDev/projects/
  • $HOME (/data/data/com.termux/files/home/)
• Path traversal (../) is rejected at the string level AND by a realpath containment check. The browser can never read arbitrary filesystem.
• Process control is uid-scoped: the app can only kill processes owned by the current user. System / Android processes are refused.
• No API keys, passwords, or tokens are stored in source code.

Development phases

• Phase 1 (current): Dashboard, Files (+ editor), Terminal, Processes, Logs.
• Phase 2: Projects + Git + Service Manager.
• Phase 3: Hermes GUI (chat interface → existing Hermes CLI, same config/memory).
• Phase 4: Android integration, auto-start, notifications, extras.

Notes

• Hermes integration reuses the already-installed Hermes CLI at ~/bin/hermes with its existing config and memory. A second Hermes instance is never created.
• The backend keeps the host LD_PRELOAD environment (the Termux/Hermes workaround) intact so its shell behaves like a normal interactive shell.