# assists: an accessibility service framework for Android automation

> Assists is a Java framework that wraps the Android AccessibilityService so an automation script can find nodes, tap, type, scroll, manage floating windows and take screenshots without dealing with the raw service API. It is the base library of a wider ecosystem that adds a custom IME, OpenCV matching, a WebView bridge, a runtime platform and an MCP server, and it is published on Maven Central under GPL-3.0.

**ven-coder/assists** — 🔥Android无障碍服务（AccessibilityService）开发框架，Android自动化脚本框架，快速开发复杂自动化任务、远程协助、监听等

- Repository: https://github.com/ven-coder/assists
- Stars: 986 · Forks: 237
- Language: Java
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ven-coder-assists

## A wrapper over AccessibilityService, and nothing more

Assists describes itself as a development framework built on Android's accessibility service, AccessibilityService. The repository description is explicit about what it is: an Android automation scripting framework for quickly building complex automation tasks, remote assistance and monitoring.

The README positions it as the foundation of an ecosystem rather than a product on its own. Assists is the base library, wrapping the accessibility service and providing a unified API with enhanced capabilities, so that upper layer modules and applications can focus on business logic instead of platform details.

The reasons the README gives for choosing it are concrete. Development is simpler because accessibility capabilities are wrapped into easy to use APIs, which reduces boilerplate. Capabilities are extensible, with floating windows, screenshots, input methods, image recognition and a Web bridge all available as needed. Scripts stay maintainable because of the stepper and modular design. And the stack is flexible, supporting both native development and Web automation with HTML and JS or Vue through a separate JavaScript library.

The listed use cases are the familiar Android automation ones: automatically handling incoming calls, automating in-app tasks such as watering and collecting in a plant growing game, marketing and traffic automation across platforms, and remote control with device collaboration.

The core capability list in the README is short enough to quote in substance. The accessibility API covers node lookup, tapping, text input and scrolling with a simple interface. Floating window management supports adding, removing, showing, hiding, scaling and moving windows for a floating control panel. The stepper is a reusable automation step framework for orchestration. Screen and screenshot capture is provided by a separate module. Image recognition adds OpenCV based template matching. And Web automation uses a WebView bridge so scripts can be written in HTML with JS or Vue.

The repository layout mirrors that list, with a directory per module: assists/, assists-ime/, assists-log/, assists-mp/, assists-opcv/ and assists-web/, plus a simple/ directory for a minimal example and CHANGELOG.md and CHANGELOG_RULES.md at the root.

## The module family and the version rule that ties it together

The dependency section is where the ecosystem becomes concrete, and it carries one rule that is easy to miss and expensive to break: the optional modules must use the same version number as the core library.

The recommended version at the time of writing is 3.5.9, and the Gradle snippet is short.

```gradle
repositories {
    mavenCentral()
}

dependencies {
    // 核心库（必选）
    implementation "io.github.ven-coder:assists-base:3.5.9"
    // 按需引入，版本号与上相同
    // implementation "io.github.ven-coder:assists-web:3.5.9"
    // implementation "io.github.ven-coder:assists-mp:3.5.9"
    // implementation "io.github.ven-coder:assists-log:3.5.9"
    // implementation "io.github.ven-coder:assists-ime:3.5.9"
    // implementation "io.github.ven-coder:assists-opcv:3.5.9"
}
```

Only assists-base is mandatory. The rest are commented out and pulled in as needed, and the comment states that the version number must match the one above.

The mapping from project name to artifactId is not obvious from the directory names, so it is worth writing down: assists is published as assists-base, and the other projects keep their own names, assists-web, assists-mp, assists-log, assists-ime and assists-opcv.

There is also a coordinate migration to be aware of. From version 3.5.3 the official repository is Maven Central under io.github.ven-coder. The older JitPack coordinates, com.github.ven-coder.assists with a wildcard artifact, still work for historical versions, and the README says new projects should use the coordinates in the table instead.

Per module changes are recorded in CHANGELOG.md at the repository root, and the repository also carries a jitpack.yml and a Gradle wrapper, so the modules are built and published as a Gradle multi project with settings.gradle and a build.gradle at the top.

## The optional modules each cover a platform gap

Reading the module list against the capability list shows that most of the interesting work in this ecosystem is about closing gaps that accessibility services cannot close on their own.

assists-ime is a custom input method. Its stated purpose is to provide a key capability for automation in scenarios where a search can only be triggered through the input method, which is a real constraint on some Android flows where the accessibility service can tap but cannot type into a given field.

assists-mp is screen recording and screenshot, covering full screen capture and node region capture. The README is explicit about why it exists: it compensates for the situation where accessibility cannot take a screenshot directly. That is a genuine architectural gap, and a separate module is a clean answer to it.

assists-opcv integrates OpenCV so template matching and similar techniques can assist with recognising screen content, which is what you need when a node hierarchy does not expose the information you want.

assists-web provides a Web automation bridge. It describes a native to JavaScript channel inside a WebView so that Web side code can call Assists capabilities directly, and it is the piece that makes the Web development path work.

assists-log is the logging module. It connects to the separate log and node reporting analysis system described in the ecosystem table, where testers submit run logs and page node information, and developers analyse the reported data to understand page structure, locate bugs across multiple devices and multiple screens, and address the problem of having no logs and no nodes to reproduce an issue.

Taken together, the modules form a coherent answer to a specific problem: on Android, an accessibility service sees the UI tree but cannot see pixels, cannot always type, and cannot read what is rendered inside a WebView canvas. Each module removes one of those limits.

## The Web path runs through AssistsX and assistsx-js

Not every team wants to write automation in Java. The project offers a second path that keeps the same runtime.

The recommended path in the README is a four step chain: develop the automation on the Web side with the assistsx-js library, install AssistsX on the phone to run the plugin, connect Assists MCP so an AI agent can help with development and troubleshooting, and use the assists-examples repository to learn and extend. The examples repository is described as containing both native automation and Web side automation examples that run as they are.

AssistsX itself is the runtime platform and node analysis tool. It installs and works out of the box, supports plugins loaded locally, over the local network or online, and with node analysis enabled it lets you inspect page nodes from a browser on the local network. The same project also provides remote control and remote retrieval of node information: you download AssistsX, register and log in with the same account at admin.assists.cn to use it free of charge, which is described as convenient for remote debugging and for fetching node information from a remote device so you can adapt your automation logic.

The assistsx-js library is the Web automation JavaScript library, offering node lookup, gestures and the stepper among its features, so that front end technologies can be used to write and maintain the automation.

The split between the two worlds is worth being explicit about, because it defines where your code lives. Native scripts are Java in your app, with the Assists library on the device. Web scripts are JavaScript in a front end project, with the assistsx-js library talking to the AssistsX runtime on the device through the Web bridge, and the plugin executed there.

One practical consequence: the Web path needs the AssistsX application on the device, so it is not a drop-in library for an existing Android application. Native development is the path for teams building automation inside their own app.

## Assists MCP gives an AI assistant the docs and the node tree

The newest addition in the README is MCP support, and the framing is that an AI agent moves from being an auxiliary tool to becoming a core collaborator in the automation development process.

The clients named are Cursor, Claude Code, Codex and OpenCode, so the integration is the standard Model Context Protocol rather than a bespoke interface. What the agent gets is access to the framework's own documentation, since the MCP server has the complete native Assists API and assistsx-js documentation built in, which the README argues is faster to query than reading web pages and easier to work with while writing code.

The capabilities listed are node reading and analysis for native accessibility nodes and logic analysis, writing automation logic, and troubleshooting runtime exceptions and locating bugs. Paired with AssistsX, the coverage widens to plugin creation, implementation, debugging and exception analysis.

What this changes in practice is the shape of the feedback loop. In the traditional workflow, diagnosing an automation failure means looking at a device, reading a node tree by hand, and comparing it with the script. With node reading exposed over MCP, the same inspection can be done in the editor as part of the conversation, which is what the project means by moving beyond remote controlling a phone to covering the whole delivery process.

Two caveats belong here. First, this is a documentation plus inspection aid, not a test oracle. The agent reads nodes and documentation, but whether the automation does the right thing still has to be established by running it on a device. Second, the whole approach inherits the accuracy of accessibility node trees, which is to say the quality of the target app's own accessibility implementation. A view that exposes no useful node information is invisible to the tooling no matter how capable the tooling is.

## Where the platform itself limits what an automation can do

The constraints on this framework are not in the framework. They are in Android, and the README design makes them visible.

The first constraint is that an accessibility service must be enabled by the user in system settings, and that permission is visible to the user. Any app shipping an automation built on this has to ask the user to grant it, which is a UX cost that no API removes.

The second is that the automation is only as good as the target app's accessibility tree. If the app under automation renders its content as a canvas, or exposes nodes without useful text or bounds, node lookup returns nothing useful. That is exactly why assists-mp and assists-opcv exist as separate modules: the fallback is pixel work, which is slower and more fragile than node work.

The third constraint is the input method problem, which assists-ime exists to work around. Some flows only accept input through an input method, and a service that cannot type is stuck at that point.

The fourth is simply that this is automation, not instrumentation. For testing your own application, an accessibility driven script is a second class citizen next to an instrumentation test, because it goes through the same UI a user does and inherits accessibility problems in your own app. The README does not position the framework as a testing framework, and for that reason it should not be chosen as one.

The remote control and monitoring use cases raise their own consideration. The project bundles a runtime with remote control and a web console for account registration, and the log and node reporting system collects run logs and page node information from testers. Those are legitimate for internal testing and device farms, and they are exactly the capabilities that a policy review at a company should look at before adoption.

## GPL-3.0, a fast release cadence and a documentation-first project

The licence is GNU General Public License v3.0, with the copyright line naming ven-coder and the year 2025. For a library that you link into an application you ship, GPL-3.0 is the decision point that has to be made before anything else, because it is reciprocal. A team that cannot distribute a GPL component inside a closed source product should stop at this paragraph.

The release cadence is fast. The listed releases are 3.5.5 on 2026-08-10, 3.5.4 on 2026-08-02 and 3.5.3 on 2026-07-08, and the README's recommended dependency version is 3.5.9, which is ahead of the newest listed tag. The repository is not archived and the last push was on 2026-10-19, so the tree is being worked on continuously and the published artefacts move ahead of the tagged releases.

That combination, a moving recommended version and frequent releases, is good for a fast moving framework and bad for reproducible builds. The practical answer is to pin every module to the same explicit version and to read CHANGELOG.md before each bump, which the README asks you to do by linking it at the point where the dependencies are described.

Documentation is unusually prominent for a Java library. The online documentation is a Feishu wiki space, the developer documentation section recommends querying the docs through Assists MCP inside an AI assistant rather than browsing the pages, and the MCP configuration guide lives at its own site. There is also a downloadable Demo application covering basic operations, advanced automation such as collecting in-app energy and posting to a social feed and answering calls, and screenshots with floating windows.

The community channels are a QQ group, a WeChat group and the maintainer's WeChat contact, and the project asks for sponsorship through a donation platform alongside star support.

## Conclusion

Assists fits Android developers building device side automation, testing tools or remote assistance features who want a maintained wrapper over AccessibilityService rather than raw platform code. It does not fit projects that need to ship the framework inside a closed source product without a GPL-3.0 review, and it does not replace a genuine UI test framework for application level testing. Verify first that the assists-base version you pin matches the assists-mp, assists-opcv, assists-ime and assists-web versions you add, since the README requires them to share a version, and confirm the accessibility permission flow your target Android version enforces.

## FAQ

### How do I add the Assists framework to an Android project?

Add the mavenCentral repository and depend on io.github.ven-coder:assists-base at the recommended version, 3.5.9 in the README. Optional modules such as assists-web, assists-mp, assists-log, assists-ime and assists-opcv are added on demand and must use the same version number.

### Which Assists module do I need for screenshots?

Screenshots and screen recording are provided by the separate assists-mp module, which covers full screen and node region capture. It exists because accessibility services cannot take a screenshot directly.

### Can I write Assists automation in JavaScript instead of Java?

Yes, through the Web path. You write the script with the assistsx-js library, install the AssistsX application on the device to run the plugin, and the Web bridge connects the two. The recommended path adds the Assists MCP server so an AI assistant can help with plugin creation, node analysis and debugging.

### What changed in version 3.5.3 of the Assists project?

From 3.5.3 the official repository is Maven Central under the io.github.ven-coder coordinates. The older JitPack coordinates com.github.ven-coder.assists with a wildcard artifact still work for historical versions, and new projects should use the Maven Central coordinates.

### What licence does the Assists framework use?

It is released under the GNU General Public License v3.0, with the copyright line naming ven-coder and the year 2025. Read the LICENSE file at the repository root before linking the library into an application you distribute.

## Sources

- [Issues](https://github.com/ven-coder/assists/issues)
- [License: GPL-3.0](https://github.com/ven-coder/assists/blob/master/LICENSE)
- [README](https://github.com/ven-coder/assists/blob/master/README.md)
- [Releases](https://github.com/ven-coder/assists/releases)
- [ven-coder/assists on GitHub](https://github.com/ven-coder/assists)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ven-coder-assists