OpenDroid: an accessibility-driven Android agent that plans, executes and replans

The problem OpenDroid targets: apps that never exposed an API

Most Android automation assumes someone published an interface for you. Tasker profiles hook into intents, Shortcuts-style tools call documented endpoints, and anything without one is simply out of reach. OpenDroid takes the opposite position. It drives the phone the way a person does, by reading the screen and issuing taps, so the set of automatable targets becomes every app that renders a UI. That is the whole thesis, and the README states it directly: screen capture happens through the Accessibility API, with a fallback to accessibility tree text scraping on older devices. The intended user is someone who wants a natural-language command like a weather check followed by a message and an alarm to become real device actions, without writing a script per app. This is a personal automation tool for a rooted-in-spirit but unrooted-in-practice workflow, not a mobile testing framework and not a RPA product for fleets of devices.

Planning loop, action executors and the replanning path

The architecture section of the README shows a package layout under com.opendroid.ai with an accessibility package holding app automators for WhatsApp, SMS and calls, and an actions package described as 60+ action executors across 10 modules. Above those sits the agent engine, which the README says breaks a command into sequential steps with dependency tracking, monitors results, and dynamically replans when a step fails. A separate guard detects compound intents, so a command containing two verbs is not silently collapsed into one action. Contact resolution is described as four tiers with fuzzy matching and relationship aliases, which is the part that decides whether "call dad" resolves to a number. The device control table is the clearest signal of scope: system toggles, messaging on WhatsApp and Telegram, calls, SMS, email drafts, maps and ride booking, media, UPI payments, and Google Home. Note what is missing from the material: there is no published schema for an action, no list of the 10 modules, and no description of how a step failure is classified as retryable versus terminal. If you want to extend the action set, you will be reading Kotlin, not documentation.

The four-tier knowledge graph and what it stores on your phone

Memory is split into four levels in the README diagram. Level 1 is temporary and holds the active plan. Level 2 is long-term explicit facts. Level 3 is learned patterns, described elsewhere in the feature list as habit and routine detection that mines recurring daily app sequences and offers one-click routines. Level 4 is marked sensitive and encrypted through the Keystore. The separation matters because the tiers have different lifetimes and different exposure. A plan is discarded when it finishes; a routine is inferred from behaviour you did not consciously record. The README does not say how long Level 3 inferences persist, whether they can be listed and deleted individually, or what triggers a routine suggestion. Those are the questions to answer before letting the app observe a few weeks of usage. The Keystore encryption on Level 4 is a concrete claim, and Android Keystore is a real mechanism, but the README does not enumerate which fields land in that tier.

Getting it running: build, model files and the keys you must supply

The README's Get Started section is the entry point, and the repository is a Kotlin Android project, so the build path is the standard one: clone the repository, open it in Android Studio, and let Gradle resolve dependencies. The material does not give a Gradle command line, a minimum SDK, or a required JDK, so treat those as things to read off the build files rather than assume. Two setup areas are described in more detail than the rest. The first is provider configuration: the app supports local and remote LLMs, and the README lists a supported providers section plus a UI that shows live latency benchmarks per provider, which implies you choose a provider and supply credentials before the agent can plan anything. The second is the on-device model manager, which uses WorkManager for background downloads with pause, resume, cellular support, speed tracking and an ETA, stores a Hugging Face token with Android Keystore AES-GCM for gated models, computes SHA-256 hashes, and checks LiteRT engine loading compatibility before marking a model READY. It also supports importing a .task or .litertlm file directly, with a JNI verification check. The accessibility service has to be enabled in Android settings before any automation works; the README treats that as a prerequisite rather than a step, but it is the step that decides whether the app does anything at all.

Where the accessibility approach breaks down

Screen-driven automation inherits every weakness of the screens it reads. The README acknowledges one of them: on older devices the vision path is unavailable and the app falls back to scraping the accessibility tree, which yields text but not layout, so anything that depends on position or on non-text UI is harder to act on. Three more follow from the design. First, apps that draw their own surfaces, games and many media players among them, expose little or nothing to the accessibility tree, so the agent has nothing to reason over. Second, an automation that taps coordinates or matches labels is coupled to a specific app version; a redesign can invalidate a routine without any error surfacing until the routine runs. Third, Android's own background execution limits apply to this app exactly as they apply to any other, and the README does not describe a foreground service or an exemption strategy. The replanning loop helps with a failed step, but it cannot help when the failure is a permission dialog the agent has no rule for. For a workflow that must run unattended and reliably, a documented API or an intent-based integration remains the better tool.

How this differs from Tasker and from Appium

Tasker is the closest thing to a default answer for Android automation, and the difference is in who writes the logic. A Tasker profile is a graph you author: trigger, condition, action, with each action chosen from a catalogue of documented hooks. OpenDroid moves the authoring into a prompt and the planning into a model, and the README's example command, a weather check that leads to a message and an alarm, is exactly the kind of multi-app sequence that is tedious to wire by hand and trivial to state in a sentence. The trade is determinism. Tasker does the same thing every time and fails in ways you can inspect; OpenDroid's plan is generated per command, and the README says it adapts when steps fail, which means the same prompt can produce different step sequences on different runs. Appium sits at the other end: it is a test automation framework driven from a host machine against a device, built for repeatable assertions rather than for a person issuing ad hoc requests on their own phone. Neither alternative is worse in the abstract. If your automation must be auditable and identical across runs, Tasker's explicit graph is the stronger choice, and OpenDroid's value is concentrated in the cases where no hook exists and a screen is all you have.

Release cadence, licence status and the cost of keeping up

Three releases land in the material: v1.0.5 on 2026-08-18 with screen understanding, personal growth memory and cellular model downloads; v1.0.6 on 2026-08-23 with a habit and routine detection engine, Telegram automation and LiteRT fixes; v1.0.7 on 2026-09-04 with AI social media management, a SAF storage policy remediation and an OLED theme redesign. That is roughly one release every eight days, and the contents jump across unrelated subsystems. A cadence like that means the upgrade cost is not the download, it is re-verifying that your routines still fire after a release that touched storage policy or the model manager. Two things in the material deserve a direct flag. The licence is reported as NOASSERTION, which means GitHub could not map the LICENSE file to a recognised identifier; the README links to that file but the material does not show its contents, so anyone intending to redistribute or ship a modified build needs to read it themselves. And the README carries a Solana contract address near the top, which tells you the project has a funding dimension alongside the code. That is not a defect, but it is context a team evaluating the project for internal use should know before assuming a conventional open source governance model. Nothing here is legal advice; the licence file is the only thing that settles the licence question.

Editorial conclusion

Adopt OpenDroid only if you are comfortable reading Kotlin source, because the accessibility automators and the action registry are the specification. It is a poor fit for anyone who needs a stable, documented API or a resolved licence before shipping. Before installing, verify two things in the repository: the actual contents of the LICENSE file, since GitHub reports NOASSERTION, and the permission scope of the accessibility service, because that service is what gives the agent its reach. Everything else in the README is a claim you should check against the code.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yashab-cyber/opendroid on GitHub