BAAH drives Blue Archive daily tasks through an emulator on screen recognition

The bot plays the game through pixels, not through a game API

BAAH is a script that finishes the daily tasks of Blue Archive, the global, Japan, CN, Bilibili and Steam servers, by driving an Android emulator. The mechanism is visual. The project depends on opencv-python and pponnxcr, an OCR model, and the README lists them under packages, alongside nicegui for the interface, MaaTouch for touch input, and Aria2 for downloads.

That choice determines everything else about the project. There is no internal API to call, no save file to edit and no packet to forge. The script takes a screenshot of the emulator, finds the element it expects, decides what to do, and sends a touch. The dependencies confirm the shape of the pipeline: an image processing library to locate shapes and regions, a neural OCR model to read text on screen, and a touch driver to act.

This is why the emulator is a requirement rather than a convenience. A native mobile client on a phone is not something the project can see into, and an emulator running on a desktop gives the script a window it can capture and click. The README's support matrix says Windows, macOS, Linux and Android Termux, and the repositories include a Dockerfile, a docker-compose.yml, a docker.sh and a Dockerfile.CN, so the container path is a first-class way of running the tool rather than an afterthought.

The topic tags on the repository, automatic-control and bluearchive, and the automated-control feature list, are blunt about what this is: the tool takes over the account's routine play. Whether that is acceptable is a question of the game's own terms, which the README does not address.

What it actually collects, raids, buys and explores

The feature list in the README is specific, and reading it tells you what a daily run covers.

On the collection side: cafe rewards, the cafe invite, touch head, club sign-in, daily task rewards, mailbox, event rewards, tactical challenge rewards and total assault rewards. On spending side, it uses tickets or power to raid timetable, normal, hard, event, bounty, commissions, scrimmage, tactical challenge and total assault stages. It buys from the normal shop and the tactical challenge shop. It explores, covering Momotalk, normal, hard, event and episode stages. It can also update the game itself, both the game package and the resource package.

The one function that goes beyond clicking through menus is the emulator lifecycle. The README lists auto open emulator, auto execute, a custom accelerator startup task and auto close emulator. Running the whole cycle unattended, starting the emulator, playing, then shutting it down, is what makes the tool usable on a schedule.

The Python project has a matching structure. At the top level sit BAAH.py, main.py, update.py, package.py, test.py, jsoneditor.py, pythonrun.bat, plus a modules/ directory, a define_actions/ directory, a DATA/ directory and a BAAH_CONFIGS/ directory holding configuration. A gui/ directory and a docs/ directory sit next to them, with the documentation images under docs/static.

APScheduler appears in the dependency list, which is consistent with the scheduled daily task claim, and aiohttp plus fastapi with fastapi-socketio sit alongside the NiceGUI layer, so the interface and any server side communication are web based.

The container path wires ADB, Aria2 and a web port together

The Dockerfile is the clearest statement of the runtime requirements, and it is short enough to read as a checklist.

The base image is ubuntu:22.04 with the work directory set to /app, and the environment variable BAAH_EDITION is set to container. The apt step installs aria2, adb, git, libgl1, libglib2.0-0, python3-pip and iproute2, then installs uv as the Python package installer. The repository is cloned with a depth of 1, the dependencies are installed through requireforyou.py with the --core flag, and the result is installed with uv pip install against the generated requirements file. Finally docker.sh is copied to start.sh and made executable, and the image exposes port 8000 with that script as the command.

Two details matter for anyone running this. adb in the image list confirms that the automation talks to the emulator over the Android debug bridge. aria2 in the same list, together with the Aria2 entry in the README's package list, is there for fetching the game client and its resource packages, which is what the auto-update function needs.

The compose file maps the configuration directories out of the container so your settings survive an image rebuild:

services:
  baah:
    build:
      context: .
    container_name: BAAH
    volumes:
      - ./DATA/CONFIGS:/app/BAAH/DATA/CONFIGS
      - ./BAAH_CONFIGS:/app/BAAH/BAAH_CONFIGS
    environment:
      - TZ=Asia/Shanghai
      - HOST=0.0.0.0
      - PORT=8000
    ports:
      - 8000:8000

The HOST setting binds the service to all interfaces and the port mapping publishes 8000 on the host, and there is a commented TOKEN variable that the file leaves unset. The timezone defaults to Asia/Shanghai, which matters for a tool whose behaviour depends on daily reset times.

Requirements are pinned, including Windows only packages

requirements.txt is long and entirely version pinned, split into a CORE section and a BUILD section. The core block runs from aiofiles 23.2.1 through yarl 1.22.0 and includes the image recognition stack: opencv-python 4.8.1.78, pponnxcr 2.0, onnxruntime 1.16.2, numpy 1.26.1, shapely 2.0.2 and pyclipper 1.3.0.post5. The web and scheduling layer is there too, with nicegui 3.4.1, fastapi 0.124.4, uvicorn 0.22.0, APScheduler 3.11.1, Jinja2 3.1.6 and pydantic 2.12.5.

The build block is where the platform assumptions show. pyinstaller 6.2.0 and pyinstaller-hooks-contrib are there to produce a Windows executable, and pywebview 4.4.1 and bottle 0.12.25 back a native window. Two entries carry environment markers:

pywin32==311;sys_platform=='win32'
pywin32-ctypes==0.2.2;sys_platform=='win32'

Those markers make the Windows-only packages optional on other systems, so the same file installs cleanly on Linux or macOS. Anything that only runs on Windows, such as the executable build, is kept out of the way of the source install path, and the README's support matrix matches: Windows gets an executable file and source code, macOS source code only, Linux source code and docker, and Android Termux is listed with source code and proot and marked experimental.

Two container files exist, Dockerfile and Dockerfile.CN, and the compose file carries a commented line pointing at the CN variant, which suggests the Chinese server build differs in its base image or its package sources.

Where this approach breaks down

Screen recognition automation is fragile by construction, and BAAH's own documentation hints at the places where it hurts.

The first limit is resolution and layout. The OCR model has to read the pixels, so a different emulator skin, a different window size or a scaled display changes what the script sees. The repository ships icon assets contributed separately and a DATA/ directory, which is the shape of a project that has had to adjust its visual expectations over time. The README does not document a list of supported emulators or resolutions, so a reader has to discover the working combination by trial.

The second limit is the emulator itself. Everything depends on adb reaching a running emulator, and the auto open and auto close features assume a particular emulator launcher on the host. On Termux the support is explicitly experimental.

The third limit is server and client drift. The script navigates by matching what it expects to find. A game update that changes a menu, a button label or an icon moves the target, and the update function the project provides is for the game package and resource package, not for a schedule of adjustments. The release history shows versions 2.4.10, 2.4.11 and 2.4.13 all landing in the first week of September 2026, which is consistent with frequent small releases, but it is not evidence that a given release works with a given game client.

None of this is criticism of the approach so much as a description of it. A pixel-driven bot needs the pixels to stay put, and a game client does not promise that.

Licence, releases and the project behind it

BAAH is licensed under MIT, and the licence file sits at the top of the repository along with the Dockerfile, docker-compose.yml and docker.sh.

The project is hosted under the BlueArchiveArisHelper organisation on GitHub, and the README points to a separate project website at baah.sanmusen.top, announced in the README as newly deployed. The project homepage field points to the same address. Documentation lives in the docs/ directory, and the README links GUI screenshots for the Chinese, English and Japanese interfaces, so the interface itself is localized.

The release naming is distinctive. Tags are written as BAAH followed by the version, for example BAAH2.4.13, BAAH2.4.11 and BAAH2.4.10, and those three landed on 2026-09-06, 2026-09-03 and 2026-09-03. The last push was on 2026-10-13 and the repository is not archived, so work is ongoing on a cadence of small version bumps.

The README also asks for stars, and links a contributors graph under the sanmusen214 account, credits icons from a separate artist, and mentions support for a release notification bot. Those are community signals rather than technical ones, and the project does not present a formal support policy beyond opening an issue on GitHub. The MIT licence is permissive, so anyone can fork and modify the automation, which is the practical reason the licence matters here.

Editorial conclusion

BAAH suits a player who runs the game in an emulator on their own machine and wants the daily loop handled while it is away, and it does not suit a player who expects it to work on a phone app or on a live service, since the whole design depends on ADB and a readable emulator window. Before running it, check that the emulator you use exposes a screen the OCR can read and that your server variant is one of the six the README lists. Verify first that the account, and not only the client, is what the automation touches, and read the terms of the game you are automating before you automate it on an account you care about.

Frequently asked questions

Official sources

1. BlueArchiveArisHelper/BAAH on GitHub
2. License: MIT
3. Project website
4. README
5. Releases