MobileClaw: an Android AI agent runtime that doubles as a model-vs-model arena
Open Android AI agent runtime for phone control, app automation, VLM screen reading, skill routing, mini apps, and Mihomo VPN workflows.
At a glance
- What is it?
- MobileClaw is a Kotlin and Jetpack Compose Android app that runs LLM agents on the device, controls apps through the accessibility service, and, in its current release, seats several models at one table to play social deduction games. The repo is ambitious and the README is thinner than the feature list.
- Who is it for?
- Adopt MobileClaw if you want a working Android shell for agent experiments and accept that you will read Kotlin to answer questions the README does not. Do not adopt it if you need a documented integration surface, a clear licence position, or a runtime that survives Play Store policy review without changes.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 67 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MobileClaw addresses on a phone
Most agent tooling assumes a desktop. It assumes a shell, a browser, a filesystem you can write to, and a process supervisor. An Android phone offers none of those in the same shape. MobileClaw exists to close that gap: it is an agent runtime that lives on the device, reads the screen, drives apps, and routes work to whichever model the user has configured. The repository description lists the scope directly: phone control, app automation, VLM screen reading, skill routing, MiniAPPs, and Mihomo VPN workflows. The README frames the current release around one slice of that: an arena where several AI roles, each bound to a different gateway and model, sit in a group and play a social game. That framing is a marketing choice rather than a technical one. The arena needs the same plumbing as any other agent task (model routing, role state, a host that sequences turns), so it functions as a demonstration of the runtime rather than a separate product. The audience is narrow but real: Android developers experimenting with on-device agents, people comparing model behaviour under adversarial prompts, and anyone who wants phone automation without writing an accessibility service from scratch.
How the arena and the runtime are wired together
The README describes a host process inside the app. That host calls speakers, collects votes, hides night actions, announces results, and advances rounds. Roles are configuration objects: each one picks a user-configured gateway and model, so a single game can mix providers. The visible mechanics are specific. Votes are tallied and announced, the highest-vote seat is eliminated, and an eliminated seat is locked out of later rounds. Hidden actions are handled so that night or event actors are not casually leaked, which is the kind of detail that matters when several models are reading the same transcript. That is the game layer. The runtime layer underneath is described only in outline. The repository topics name an accessibility service, Jetpack Compose, Kotlin, Python, VLM, and Mihomo, and the README refers to role management, memory, local and cloud model routing, MiniAPPs, native AI pages, skill tools, and a desktop Codex bridge. What the supplied material does not give is the data flow: how a screen read becomes a model prompt, where memory is persisted, or how a skill is selected. A linked design document, docs/group-chat-game-module-boundary.md, suggests the game was deliberately carved out as a module, but the boundary itself is not reproduced here.
Building and running it from source
The README gives one build path. Clone the repository, change into it, and run the assemble script:
git clone https://github.com/eggbrid2/mobileClaw.git cd mobileClaw ./scripts/assemble_debug.sh
The debug artifact lands at app/build/outputs/apk/debug/app-debug.apk. There is no Play Store listing mentioned, so installation means sideloading that APK. A second script handles distribution through Pgyer:
python3 scripts/pgyer_release.py build-upload --gradle-task assembleDebug --notes "MobileClaw AI arena group play release"
The README states that Pgyer secrets belong in local.properties, .pgyer.env, or environment variables, and warns against committing them. That is the only configuration guidance in the supplied material. Nothing here documents the gateway settings, the model provider keys, or where the app expects them, even though the arena depends on user-configured gateways. Anyone building this should expect to find those keys by reading the Kotlin source. The build requires an Android toolchain for API 11 and above, per the badge in the README, and Kotlin 2.2 with Jetpack Compose.
The accessibility service is the load-bearing risk
Phone control on Android runs through the accessibility service, and the repository lists accessibility-service as a topic. That choice buys real capability: reading screen content, dispatching taps, moving through app flows. It also buys a set of constraints that no amount of Kotlin quality removes. The user must enable the service manually in system settings, and some ROMs kill or throttle accessibility services aggressively. The service is also the single point where a bug becomes a misdirected tap in a banking app. The README does not describe a confirmation step before actions, a scope limit on which packages the agent may touch, or an audit log. The hidden-action handling in the game layer shows the authors think about information leakage between agents, but that is a different concern from what the agent does to the phone. Treat the accessibility path as the part of MobileClaw that needs the most scrutiny before you hand it a device you care about.
Licence status and what NOASSERTION means here
The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not match the LICENSE file to a known template. The README says MIT and links to LICENSE, and the badge in the README also says MIT. Those two signals disagree with the metadata, and only the LICENSE file resolves it. This is not a formality. If the file is a modified MIT or a custom text, the terms that matter to you (patent grant, attribution, redistribution in a closed product) may differ from stock MIT. Read the file before you build anything you intend to ship. The supplied material also says nothing about third-party dependencies, their licences, or the licence of any bundled model weights or MiniAPP runtime, and docs/miniapp-javet-node-runtime-plan.md suggests a Javet or Node runtime is planned for MiniAPPs, which would carry its own licensing questions.
Maintenance, upgrades, and the update channel
The release history shows v0.5.0 and a duplicate 0.5.0 tag on the same day, plus 0.4.15 shortly before, and the last push is dated 2026-07-11. That pattern suggests active iteration with occasional tag noise rather than a stable release cadence. Upgrades arrive through the Pgyer flow, which the README describes as having native update prompts and an APK install handoff. That means users sideload updates rather than receiving them from a store, and each update is a fresh APK install with whatever permission prompts the platform requires. For a team, the cost is not the build. It is the ongoing read of the Kotlin source every time a gateway setting, a skill boundary, or the accessibility behaviour changes, because the documentation set is a quickstart plus four design documents and the README does not track the code. Budget for that reading time, or pin to a tag and stop moving.
Where Tasker plus an LLM API call is the better fit
Tasker, paired with an HTTP call to a model provider, solves a overlapping problem with a different shape. Tasker exposes triggers, conditions, and actions as a configuration graph, so a flow like "when a notification from this package arrives, read it, send the text to a model, and post the reply" is built by wiring blocks rather than writing an accessibility service. The trade-off runs the other way too. Tasker has no agent loop, no memory model, no skill router, and no multi-role state, so anything that needs an agent to decide its next step at runtime falls outside it. MobileClaw inverts the balance: it gives you the agent loop and the model routing, and asks you to accept an app whose internal interfaces are undocumented. If your automation is a fixed sequence, Tasker is less work and less risk. If your automation needs the model to choose the next action, MobileClaw is the closer fit, and you should expect to read its source to use it.
Who should pick this up, and what to check first
MobileClaw is worth a look if you are building or studying on-device agents on Android and you want a Compose codebase that already wires an accessibility service, model routing, and a multi-agent turn structure. The arena is a genuine test harness for comparing how different models behave under the same adversarial prompt, and the vote tally and seat lockout give the game a real state machine rather than a chat log. It is the wrong tool if you need a documented API, a Play Store distribution path, or a licence you can confirm from the metadata alone. Before building, open the LICENSE file and confirm the terms match the MIT claim. Then check the accessibility service behaviour on your target ROM, since that is the failure mode the README does not cover. Finally, look at how gateway credentials are stored, because the arena depends on user-configured gateways and the supplied material never says where those secrets live.
Editorial conclusion
Adopt MobileClaw if you want a working Android shell for agent experiments and accept that you will read Kotlin to answer questions the README does not. Do not adopt it if you need a documented integration surface, a clear licence position, or a runtime that survives Play Store policy review without changes. Verify three things before you commit: what the LICENSE file actually contains, whether your target ROM grants and keeps the accessibility service permission, and how the app stores gateway API keys on disk. The group-game release is the headline, but the agent runtime underneath is what you are really evaluating.
Community notes