The Three Projects

The three repositories are often mistaken for "three versions", but they actually form one core engine plus two hosts. Choosing the wrong repository can lead you to mistake the launcher for the automation script itself or assume the Android app has an independent logic implementation.

Solid lines indicate startup and code distribution; dashed lines indicate device control pipelines. The core program does not care which host spawns it.

Responsibility Matrix

Repository	Default Branch	Language / Framework	License	Responsible For	Not Responsible For
wess09/AzurPilot	master	Python 3.14 · React · Vite	GPL-3.0	Scheduling, recognition, game logic, WebUI, API, MCP	Provisioning Python environments, process management, mobile porting
wess09/AzurPilotLauncher	main	Rust · Tauri 2	GPL-3.0	Desktop environment bootstrapping, code updates, backend process lifecycle, system tray, notifications	Any in-game behavior
wess09/AzurPilot-for-Android	main	Kotlin · Compose · C++ · Python Runtime	AGPL-3.0	PRoot runtime, virtual display, privileged services, OCR hardware acceleration, remote client	Game logic (reuses upstream core)

Default Branch Discrepancy

The core repository uses master, while the other two repositories use main. Links copied from older articles frequently hit 404s due to this difference.

Dependency Flow

Launcher ──git pull──▶ AzurPilot (core repo)
   │                      ▲
   └──uv sync──▶ .venv     │
                           │ Same source code bundled into rootfs
Android ──PRoot──▶ Ubuntu 24.04 ──▶ AzurPilot

• The launcher does not bundle core code. It runs git clone on initial boot, followed by git pull and uv sync on subsequent starts. The launcher version and core version operate on completely independent version lines.
• The Android host embeds core code. The Runtime image contains a full copy of the AzurPilot source and pre-built frontend assets, allowing offline startup. Upstream updates arrive through an independent hot update channel.
• All three share identical WebSocket contracts. The Android host's AzurPilotGateway and the browser WebUI subscribe to the same /api/v1/ws endpoint.

Which One Should You Download

Your Situation	Choice	Entry Point
Windows / macOS / Linux PC with emulator	Launcher	Install Launcher
No PC available, or dedicating an old phone to automation	Android APK	Install Android Version
Already running instances on another PC, monitoring via phone	Android APK in remote client mode	Remote Client
Modifying code, authoring tasks, integrating APIs	Source repository	Source Installation
Server / NAS / Raspberry Pi	Docker or source	Docker Deployment

Release Cycles and Versioning

The three repositories release independently; version numbers do not correlate:

• Core: Rolling updates on master without strict semantic versioning. The WebUI "Update" page displays commit lists to review and apply.
• Launcher: Versioned releases (archives) that auto-update via mTLS channels with multi-mirror fallback.
• Android: Dual-track releases—lightweight APK (host code) + Runtime (rootfs image), both distributed per ABI.

To learn what happens when updating individual components, read Update, Backup & Migration.

Docker Deployment

The core repository includes a Dockerfile and docker-compose.yml, ideal for headless environments:

git clone https://github.com/wess09/AzurPilot.git
cd AzurPilot
docker compose up -d --build

The image uses a multi-stage build ("Frontend Build → Python Runtime"). The container launches via .venv/bin/python gui.py. The repository also provides deploy/docker/Dockerfile.cn configured for mainland China network mirrors.

No Emulator Inside Container

The container only hosts the WebUI and scheduler. The emulator runs on the host OS. You must forward ADB ports into the container or configure network_mode: host.

Licensing

These licenses are copyleft: distributed modified versions must comply with GPL-3.0 / AGPL-3.0. Because the Android host delivers services over a network, AGPL mandates making corresponding source code available to network users.