Three-Layer System Design
How Android DEX distributes responsibilities across execution contexts to enable near-zero latency commands and deep system control.
System Overview
Both Android-side components connect back to the Windows side — the Windows app runs the servers; Android clients connect to them.
Layer 1 — Windows Side
Role: Orchestrator, UI host, server infrastructure, and rendering engine.
| Domain | What It Does |
|---|---|
| ADB Lifecycle | Starts ADB server, connects device, sets up reverse port forwarding |
| Servers | Runs 4 TCP/WebSocket servers that Android components connect to |
| JAR Deployment | Locates, pushes, and launches the Logic Engine on the device |
| APK Management | Detects, installs, and starts the companion APK service |
| Rendering | Embeds scrcpy windows as native Win32 child windows inside Flutter |
| Reconnection | Monitors connection state; auto-heals without user restart |
Layer 2 — Logic Engine (Java JAR)
Role: Shell-level command executor running with elevated ADB daemon privileges.
The JAR, launched via adb shell app_process, executes at the ADB shell user level — allowing volume manipulation via AudioService and control over the ActivityManager without launcher process restrictions.
Core Responsibilities
- Volume Control: Direct
AudioManagerstream access at shell level. - App Launch:
ActivityManager.startActivity()with foreground flags. - App Kill:
ActivityManager.forceStopPackage(). - Screen State: PowerManager + WakeManager invocation.
Layer 3 — Feature Hub (Kotlin APK)
Role: Permission-holding daemon for all telemetry and high-level Android APIs.
Includes access to listener APIs that require app registration, such as NotificationListenerService and MediaSessionManager.