What is AzurPilot
AzurPilot is an automation framework for Azur Lane. It connects to Android emulators or devices over ADB and runs a continuous loop of "screenshot → recognition → tap", handling repetitive routines such as dailies, sorties, and Operation Siren.It is neither an in-game plugin nor a client modification: all actions occur at the screen display level, using the same input pipeline as manual player taps.
Technical Stack
| Layer | Implementation | Details |
|---|---|---|
| Scheduler | alas.py | One process per instance, runs tasks sequentially, features tiered recovery upon failure |
| Recognition | OpenCV template matching + OCR + grid map detection | Assets authored at 1280×720 across CN / EN / JP / TW sets |
| Control | uiautomator2 / ADB / minitouch / MaaTouch | Switchable screenshot and control backends in settings |
| Interface | React + TypeScript + Vite | Accessed via browser, default port 25548 |
| Communication | WebSocket RPC (/api/v1/ws) | Shared by frontend, Android host, and external tools |
| Extension | MCP SSE service | 18 tools callable by MCP-compliant clients |
Supported Scope
- Servers: CN (official Bilibili and various channel servers), EN (Global), JP, and TW. Channel servers are differentiated by package name; see Connect Emulator & ADB.
- Platforms: Windows, macOS, Linux (launcher); Android 9.0+ (host); any environment supporting Python 3.14 (source).
- Resolution: 1280×720. This is a rigid requirement, not a suggestion.
- Direct physical phone connections are unsupported on the core program side. The Android app turns the phone into a controlled target via a virtual display, which operates over a distinct pipeline.
Explicit Boundaries
- No game client cracking, memory injection, or asset modification.
- No account leveling services, trading, or account sharing.
- No bypassing of anti-cheat or risk control mechanisms. Automation inherently carries ban risks.
- No guarantee that all new event stages support day-one automation. Event mechanics change frequently; some require manual completion of prerequisites.
What Happens During a Task Run
Taking the "Research" task as an example:
- The WebUI writes
Research.Scheduler.NextRunintoconfig/<instance>.json. - The scheduler selects the due task and binds its parameters to
self.config.Research_*. run('research')invokes the corresponding method onalas.py, which lazily importsmodule/research/research.py.- The module captures a screenshot with
device.screenshot(), checks the current UI using template matching and OCR, and advances the workflow withdevice.click(). - Upon completion, it calls
task_delay()to record the next execution timestamp, and the scheduler proceeds to the next iteration.
Read Scheduler Lifecycle for the complete execution and failure recovery flow.