DroidClaw vs FoneClaw: APK, Dashboard, CLI, and Android Task Workflows
Compare DroidClaw and FoneClaw by setup path, Android task fit, model costs, data exposure, permissions, approvals, and reversible first-task checks.
- Choose DroidClaw when you want an open MIT-licensed Android automation project with source-code customization, APK and Dashboard paths, and documented CLI workflows.
- Choose FoneClaw when you want supported everyday Android task workflows with a free default or configured compatible model, on-demand permissions, visible results, and policy-dependent approvals.
- DroidClaw has Android APK, Dashboard, and CLI paths; its CLI setup documents Bun, ADB, Android USB debugging, and a model provider or local Ollama route.
- Judge both products by small reversible tasks, model and data boundaries, approval behavior, and the final phone result rather than by tool totals or broad automation promises.
Choose by the Work You Want to Maintain
The practical DroidClaw vs FoneClaw decision is not a generic “which AI agent is smarter” question. DroidClaw is a named open-source Android automation project for people who are comfortable evaluating code, setup paths, model configuration, and workflow behavior. FoneClaw is our supported Android assistant path for everyday phone tasks where the user wants visible progress, Android permissions, and clear result checks inside the app experience.
| Choose | Best fit | Main check |
|---|---|---|
| DroidClaw | You want source-code customization, configurable workflows, APK or Dashboard paths, and a documented CLI option. | Confirm the current official setup path, model provider, device connection, and workflow safeguards. |
| FoneClaw | You want supported Android task workflows such as app opening, calendar creation, and Information Inbox assistance. | Check the supported action, required Android permission, model setting, approval policy, and visible result. |
Neither choice is a universal answer for every app or every Android device. The better pick is the one whose setup, model costs, permissions, and maintenance burden match the work you actually plan to run.
Separate APK, Dashboard, and CLI Setup
DroidClaw has Android APK, Dashboard, and CLI paths in its official materials. The DroidClaw repository identifies the project, shows the MIT license, and links an Android APK and Dashboard. Its official DroidClaw release record also includes an Android APK asset and notes around scheduled goals, cancellation, and an Android stop-button fix for web-started goals.
The CLI path is a separate setup route. DroidClaw's CLI instructions document Bun, ADB, Android USB debugging, and an LLM provider key or local Ollama. The README describes reading accessibility XML, sending the goal, screen, and history to the model, then acting through ADB. It also documents optional screenshot vision fallback when the UI tree is unavailable. Those CLI prerequisites should not be assumed for every APK or Dashboard user unless the current setup path requires them.
| Path | What official materials establish | What to confirm yourself |
|---|---|---|
| Android APK | DroidClaw publishes an APK asset and links APK access from the repository. | Current release, install source, permissions, device behavior, and update expectations. |
| Dashboard | The repository links a Dashboard path for web-started goals. | Account or hosting requirements, current availability, and how goals are stopped or reviewed. |
| CLI | CLI setup documents Bun, ADB, USB debugging, and model configuration. | ADB authorization, provider cost, local or remote model location, and workflow reliability on your target apps. |
If you are comparing more developer-oriented phone-agent projects, Best Open Source Phone Agent Frameworks: Open-AutoGLM, Mobilerun, and mobile-use gives a wider framework view.
Compare Tasks Rather Than Tool Totals
Tool counts and broad automation claims are a weak way to choose an Android assistant. A better comparison is whether the product can handle the specific task, expose the right context, ask for the right permission, and leave a result you can inspect.
| Decision point | DroidClaw | FoneClaw |
|---|---|---|
| Setup style | Open project with APK, Dashboard, and CLI paths; CLI users manage developer prerequisites and model configuration. | Supported Android assistant app with free default model or configured compatible model. |
| Workflow style | AI workflows use JSON sub-goals across apps; deterministic YAML flows do not call an LLM. | Supported Android task flows inside FoneClaw with visible progress and result review. |
| Screen context | CLI can use accessibility XML and optional screenshot vision fallback when the tree is unavailable. | FoneClaw uses supported screen and app context where the user grants the needed access. |
| Examples to check | Open a simple app flow or run a documented workflow on a non-sensitive target. | Open a launchable app, create a calendar event when required time details are available, or use Information Inbox reply and in-app navigation help. |
| Approvals and results | Review the workflow safeguards, action feedback, and loop or repetition handling described by the project. | On-demand Android permissions and global or per-tool approval settings govern prompts; users inspect the final app or task result. |
For screen perception tradeoffs, Android AI Screen Understanding: UI State, Screenshots, and Safe Actions explains why UI trees, screenshots, and current app state affect automation reliability. For FoneClaw, the current FoneClaw Features page describes our supported Android capabilities.
Check Model Cost and Data Exposure
An MIT license on project code does not make model inference free. DroidClaw's CLI path still needs an LLM provider key or local Ollama. A local Ollama setup may run on another machine rather than the Android phone, and target apps can still need internet. Using ChatGPT or Gemini apps without those services' API keys is not the same thing as free controller inference for every workflow.
FoneClaw gives users a free default model option and also supports configured compatible models. If a user chooses an external model provider, that provider can have its own costs, limits, and data handling terms. In both products, the model choice and the task determine what may be sent, read, or stored. Before relying on either setup, inspect the selected model, Android permissions, logs or task history, and what screen or message context the workflow uses.
The clean rule is simple: do not judge privacy or cost from the product name alone. Check the model endpoint, whether data leaves the phone, what the target app exposes, and whether the result is visible before the task has consequences.
Try a Small Reversible Task First
Start with a task that is easy to verify and easy to undo. Good first checks include opening a non-sensitive app or creating a clearly named test calendar event with known start and end times, then inspecting and deleting it afterward. The goal is not to create a benchmark score; it is to see whether the system understands the target, asks for the needed access, avoids duplicate actions, and reports a result you can inspect.
For DroidClaw CLI, confirm ADB authorization, USB debugging or the documented remote setup, model configuration, UI tree access, and screenshot vision behavior before using a workflow on sensitive apps. For APK or Dashboard paths, use the current official setup material and keep the first goal small. Stop retries before a workflow can repeat an external action.
For FoneClaw, choose a supported Android task. App launch changes the foreground app and may expose that app's screen, so it follows the relevant approval policy. Calendar creation collects missing time and reminder details before saving, can preserve a user-provided location name when one is supplied, and reports the actual created time from the result. Information Inbox can help with AI-assisted replies and in-app navigation, with the user reviewing meaningful content before relying on it.
For the broader action model, AI Agent Phone Control on Android: Intent, Confirmation, Action explains why intent, approval, execution, and result verification should stay separate.
Pick the Setup You Can Support
Pick DroidClaw if you want an open, configurable project and you are ready to maintain the setup path you choose: APK, Dashboard, or CLI. It fits best when source-code customization, workflow design, and model-provider control matter.
Pick FoneClaw if you want supported Android workflows for app launch, calendar creation, Information Inbox assistance, visible task progress, on-demand permissions, and approval settings controlled by global mode and per-tool policy. It fits best when you want practical phone tasks with results you can review inside a supported product experience.