Onmyoji Auto Script: a decade of Android automation rebuilt around a task scheduler

What the project actually automates, task by task

The README opens with a statement about the game's lifecycle rather than a feature list, and it is worth reading literally: the game is late in its life, and the argument for automation is that the remaining play time is better spent elsewhere. Everything after that is a schedule of what the script will do for you.

The categories cover a lot of ground. Daily work includes bounty seals, seal drawing, sign-in routines, gold monster hunts, the New Year event, guild-style cooperative play, exploration and soul tidying. Weekly work adds the True Snake fight, secret realm races, the mystery shop, PvP dojo runs and weekly errands. The guild section covers base claiming, base enhancement, guild breakthroughs, hunting battles and the dojo. Then there is a long list of instanced PvE content, an exploration-focused section for accounts that push resource collection hard, and a limited-event section for tower climbs, onmyoji duels, guessing events and quiz events.

Two features stand out as different in kind from the rest. The first is automated soul inventory tidying, which is a sorting problem rather than a combat loop. The second is the hundred demons night parade, where the README claims a model that knows every shikigami decides where the bean throws land. That is a machine learning feature rather than a rule set, and it is the one place in the repository where the automation claims reasoning rather than repetition.

Where it came from: Azur Lane, then Star Rail, then this

The README is explicit that this project did not start from a blank page. It was developed on top of Azur Lane Auto Script, and it borrows from the design problems raised in a separate Star Rail automation project that shares the same lineage. Three of those projects appear in the related repositories list: AzurLaneAutoScript, StarRailCopilot, and the newer Nikke script.

The listed changes from the original framework are the useful part, because they explain the shape of the tree. First, the architecture was split so the backend and the interface are separate, which the README frames as more flexible to maintain and extend, with less coupling to any one game. Second, the GUI was rebuilt: the original approach was described as bloated, so the replacement uses Flutter for a cross-platform interface. Third, the OCR library was replaced with a ppocr-onnx based option, following the same upstream author's choice, described as easier to use with higher accuracy at higher speed. Fourth, a new asset management system was built to handle game images, text and click targets. Fifth, configuration files were moved to pydantic so user configuration is validated rather than loosely parsed.

Those five items map directly onto directories you can see in the repository. `fluentui/` is the interface layer, `assets/` is the asset system, `config/` is the pydantic configuration, `tasks/` holds the task implementations and `module/` holds shared machinery. The tree also holds `dev_tools/`, `tests/`, `deploy/`, three top-level Python entry points and a `requirements-in.txt` alongside the compiled lock.

Three entry points and a compiled dependency lock

At the top level of the tree there are three Python files that matter: `gui.py`, `server.py` and `script.py`. Given the split-backend claim, the natural reading is that the interface talks to a server process which in turn drives tasks, with `script.py` as the direct command line path. The README does not document the wiring between them, which is one of the places where the repository hands off to its documentation site.

The dependency situation is the opposite. `requirements.txt` is a fully compiled, annotated lock file, and its header says so plainly.

#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --annotation-style=line --output-file=requirements.txt requirements-in.txt
#

Reading it tells you what the automation actually talks to. `uiautomator2` and `adbutils` are the Android control layer, with `adbutils` pinned at 0.11.0. `frida` and `frida-tools` are present, which is instrumentation rather than UI automation, and `onnxruntime` with `flatbuffers` is the inference runtime behind the OCR. `fastapi` at 0.104.1 plus `uvicorn` and `starlette` is the server. `cryptography` and `gevent` come in through the RPC stack that `zerorpc` needs. There is also `anytree` and `cn2an`, the latter for Chinese numeral conversion, which suggests task logic that formats Chinese numbers for display.

The implication is that this is not a lightweight script. The pin set is large and specific, the runtime assumes Python 3.10, and installing it means dealing with native wheels for cryptography, onnxruntime and gevent.

A compose file that assumes Linux, despite the Windows badge

The README's badges advertise a Windows platform and a Python 3.10 target, and the linked install tutorial is described as a hand-holding manual. The repository, however, ships a Linux container path, and the compose file is small enough to read in full.

services:
    OAS:
        network_mode: host
        volumes:
            - '.:/app/OnmyojiAutoScript:rw'
            - '/etc/localtime:/etc/localtime:ro'
        container_name: 'oas-env'
        image: 'oas-env'
        build:
            context: ./deploy/docker/
            dockerfile: ./Dockerfile

Three details in that file are worth pausing on. `network_mode: host` means the container shares the host's network namespace rather than getting its own, which is usually a deliberate choice for Android debugging work where ADB traffic and emulator ports need to be reachable directly. The build context is `./deploy/docker/`, so the Dockerfile lives inside the deploy directory rather than at the repository root. And the source tree is bind-mounted read-write into `/app/OnmyojiAutoScript`, which means edits on the host take effect immediately and logs written by the container land in your checkout.

So there are two deployment stories that the README does not reconcile: a Windows-native path implied by the badges and the packaged download, and a Linux container path implied by the compose file. The container also needs the same hardware access the native version does, which means USB passthrough or a networked emulator, and the compose file does nothing to arrange that for you.

Releases stopped in 2023 while development kept going

GitHub shows three releases, and the newest is from December 2023. It is a Windows installer archive rather than a library artifact, and its release notes carry a warning that this version is the one built to talk to the separate GUI project. The release before it, from June 2023, is explicitly labelled an informal release that only supports Windows. The third is older still.

That is a real signal about how this project distributes itself: installers, not packages. The automation interface described in the README as a Flutter application is the OASX project, which has its own repository, and the release note is effectively a compatibility marker between the two. Anyone expecting a pip-installable automation framework with versioned releases is looking for something this repository does not publish.

The freshness signal has to come from elsewhere. The repository shows 5,246 stars, 503 forks and 310 open issues, with a last push on 2026-09-21, so work is clearly landing in the tree long after the last packaged build. The open issue count is also the largest in this batch, which is consistent with a project whose bug reports arrive in a language its maintainers read fluently and where each user runs their own account configuration.

The governance page is the part most projects leave out

The README contains the clearest policy statement of any project in this batch, and it covers three separate things: what users may do with the code, how to join the community, and what happens if you paid for it.

On payment, the statement is blunt and bilingual. The project is free open source software released for study and exchange. The team reserves final interpretation of the project. Any problems arising from use of the software are the user's own. And then the sentence that is unusual enough to be memorable: if you paid for this from any channel, please refund. That is a legal posture, not a joke, and it is consistent with the GPL-3.0 license declared directly beneath it.

On community, the position is that Onmyoji players as a group are unusually hostile to automation tooling, so the ask is that you do not promote the project on the internet, which protects both the users and the developers. Access to the main QQ groups is gated: a QQ level above 32, an account older than a year, and a GitHub account at least six months old that has starred the repository, with the star explicitly allowed to be removed later. Group entry verification uses the GitHub username rather than the display name. A separate developer group exists for people who intend to contribute, and the README asks that it be joined with that intent rather than at random.

The development guidance is brief and specific: pick the part you are interested in and open a pull request, with future work announced on issues and marked as help wanted. For a project with this many open issues, searching the backlog and filtering for help wanted is probably the fastest route to a contribution that gets read.

Editorial conclusion

The interesting engineering in this repository is not the automation itself but the framework decisions that make automation survive a live service. Splitting the backend from the interface, replacing reflection-heavy configuration with pydantic models, moving OCR to an onnx runtime and building an asset pipeline are all maintenance decisions aimed at a codebase that started life as someone else's script. What you inherit with that is a large, opinionated, Chinese-language automation framework that expects an Android device or emulator on ADB, a Python 3.10 environment and hours of tuning per account. It is licensed GPL-3.0, distributed free of charge with an explicit refund request to anyone who paid for it, and maintained through a QQ group with membership rules rather than an open community. Read the installation guide on the documentation site before cloning anything, because the README itself defers almost every operational detail there.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. runhey/OnmyojiAutoScript on GitHub