opendroid ships 60+ action executors across ten modules with no per-app allowlist, and a 4-tier memory graph that stores patterns it inferred

Sixty action executors across ten modules, with no per-app allowlist described

The capability surface is stated as 60 or more action executors across ten modules, sitting under an accessibility package of app automators for messaging, SMS, and calls. The device control table covers eight categories. System covers brightness, WiFi, Bluetooth, flashlight, do not disturb, volume, and screenshot. Communication covers WhatsApp messages, Telegram messages and channels addressed by handle, calls, SMS, and email drafts. Routines covers morning briefings, agenda summaries, and automated macro sequences. Productivity covers screen extraction, alarms, timers, reminders, calendar events, and notes. Navigation covers Google Maps directions and ride booking with two providers. Media covers playback control, a video search, and the camera. Finance covers UPI payments, bill splitting, and currency conversion. Smart Home covers Google Home device control. What is absent from that description is the part that matters most for an agent with this reach. No per-application allowlist is mentioned, so nothing in the visible documentation prevents an action from targeting an app you would rather it left alone. No dry run mode is described. No confirmation step appears before any of the eight categories, and the only stop control named is the foreground service, which is the one component Android itself surfaces to the user for killing.

Habit detection offers to automate the routines it infers from your app use

One feature is the reason scope grows on its own rather than by configuration. Habit and routine detection mines recurring daily application sequences, with a worked example given as Gmail into Calendar into Slack at 9 in the morning, and then offers one-click automated routines built from what it found. So the agent does not wait for you to write a macro; it proposes one from observed behaviour, and accepting it changes what runs without you. That mechanism is described alongside three other planning features. Self-planning breaks a complex command into sequential steps with dependency tracking, re-evaluation monitors execution and replans when a step fails, and a compound intent guard exists to detect multi-action commands such as opening a messenger and sending a message in one request. Contact resolution is four-tiered with fuzzy matching and relationship aliases, so a phrase like calling dad resolves through an alias rather than a stored number. The worked example at the top of the readme shows all of this combined: check tomorrow's rain, and if it will rain, text a specific person about being late and set an alarm. Three steps, one conditional, an irreversible message to a human being.

Payments and messages sit in the same table as brightness and the flashlight

The flat structure of that capability table is the finding. Finance sits beside System in a list with no severity ordering, which means a currency conversion and a UPI payment are entries in the same list as toggling the flashlight. Bill splitting is there too, which is an action with money and other people attached. Communication covers four separate channels of outbound contact, including Telegram channels addressed by handle and email drafts, and Navigation includes booking a ride with two named providers, which commits money and sends your location. Nothing in the visible documentation describes a confirmation dialog, an amount limit, a recipient allowlist, or a distinction between reversible and irreversible actions. Re-planning makes this sharper rather than safer: when a step fails, the system replans, so a failure partway through a money or messaging action produces a new attempt rather than a halt. The stated architecture has an agent loop, a plan manager, an intent classifier, and a vision engine inside the core agent package, which is the standard shape for an autonomous controller with no gate between intent and action.

Automatic failover across twelve providers means a prompt can leave the vendor you chose

Twelve language model providers are supported, and the list is broad enough that the privacy question is not which provider you configured but what happens when it fails. There is a smart fallback described as automatically trying the next available provider in the chain when the primary fails. The twelve are a cloud model family, two other cloud model families, a fast inference host, an open-weights vendor, a European cloud vendor, an aggregator offering 200 or more models through one API, an open-source model host, a retrieval-augmented vendor, a coding-assistant API that can serve two different model families, a local runtime for any local model, and any OpenAI-compatible endpoint you point it at. Screen content travels with that. The vision engine captures screenshots through the Accessibility API and feeds them to vision-capable models for analysis and for a feature described as reading and remembering, and the documented fallback on older devices is scraping the accessibility tree text instead of sending an image. That fallback is the safer path and it is device-dependent rather than user-selectable in the visible text. The user interface does show live latency benchmarks per provider, so the app is telling you the cost of the failover it is willing to make.

Credentials moved into the Keystore and a plaintext migration path is still named

Two separate places hold secrets, and both are handled through the platform keystore rather than through application preferences. The security package in the architecture listing is described as direct keystore provider credentials plus legacy plaintext migration, which is the sentence to notice: there was a version that stored provider credentials as plaintext, and the code that migrates them still exists. Provider API keys therefore land in a keystore-backed store, and the four-tier knowledge graph puts its sensitive tier there as well, labelled encrypted with the keystore in the diagram. The on-device model manager uses the same mechanism for a different purpose: gated models hosted on a model hub require a token, and that token is stored with AES-GCM in the Android Keystore so the app can fetch the model without the credential sitting in a preferences file. The four tiers themselves describe a widening of confidence. Level one is temporary and tied to the active plan. Level two is long-term and holds explicit facts you stated. Level three is learned patterns, which the diagram labels as inferences. Level four is sensitive and keystore-encrypted. The third tier is the one to think about, because it is what habit detection writes into.

A model is marked ready only after a hash check and an engine compatibility check

The on-device model manager is the most carefully specified subsystem in the application, and its four capabilities read like an answer to the usual objections about bundling models. The background downloader is described as doing real network downloads through a scheduling library, with pause and resume, cellular support, speed tracking, and an estimated time remaining. Integrity verification computes SHA-256 hashes and verifies engine loading compatibility before a model is marked ready, so a corrupt download does not become a usable-looking model. Local import lets you bring in a catalog model or a freestanding custom file with either of two extensions, subject to a native interface verification check. Secure authentication is the keystore-backed token storage described above. What is not described is the catalog itself, which models are actually offered, their sizes, or what a first-run download costs in time and storage. The wake word is offline, so activation does not need the network, and speech recognition is separate from the model manager, with text-to-speech able to use a paid premium voice service hosted by a third party.

The three newest releases are titled with a storage policy fix and a memory feature

Release titles here carry more information than changelogs usually do. The newest, v1.0.7, is titled for AI social media management, storage access framework policy remediation, and an OLED theme redesign. The middle one, v1.0.6, is titled for the habit and routine detection engine, Telegram automation, and fixes to the on-device runtime. The third, v1.0.5, is titled for screen understanding, personal growth memory, and cellular model downloads. Two of those entries are worth pausing on. Storage access framework policy remediation means an earlier version was reaching storage in a way that did not comply with scoped storage, so the app had to be brought back inside the platform's rules. That is the kind of entry that only appears after a platform policy review or a user complaint, and it is the sort of thing worth checking in your own build rather than assuming. Personal growth memory in v1.0.5 lines up with the learned-patterns tier of the graph. Cellular model downloads in the same release line up with the cellular support in the downloader, which decides whether a large model ever finishes downloading on a metered connection.

The readme header prints a blockchain address and the licence field is empty

Two things in the header are worth naming. The first is a string of letters and numbers preceded by a two-letter chain marker, sitting alone in a centred line above the badges with no visible label explaining what it is for. It is not connected to any sentence in the surrounding text, so a reader cannot tell from the visible material whether it is a donation address, an artefact of a template, or something else, and a repository header is exactly the wrong place for an unexplained financial-looking string. The second is licensing. The project metadata records no licence value, while the badge row links to a licence file in the repository and the navigation includes a licence section, so the terms presumably live in that file and are not visible here. Against that, the repository description calls the application production-ready and a badge links to a product listing page, both of which are claims a prospective adopter should weigh separately from the absence of readable terms. The rest of the header is distribution: a releases link, a stargazers link, a Discord invite, and a demo video whose filename marks it as generated.

Editorial conclusion

opendroid is worth reading if you are building or evaluating on-device Android agents, because the architecture, the provider list, and the memory tiers are unusually well described. It is a different matter whether to let it run on a phone that holds your banking app. The application acts as you through the Accessibility API, its action table spans messages, calls, payments, and smart home devices, and the visible documentation names no per-app allowlist, no dry run, and no confirmation prompt before an irreversible action. Before you install it, check four things. What the Accessibility Service is granted access to on your device, since that grant is the whole capability. Which providers are in the failover chain, because automatic failover means a prompt can go to a vendor you did not choose, and screen screenshots go to whichever vision-capable model is active. What ends up in the learned-patterns tier, since that is inferred rather than stated. And whether the storage permissions it wants are limited to the framework, given that one of the three most recent releases is titled as a storage policy remediation.

Frequently asked questions

Official sources

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