BotDrop for Android: An OpenClaw Agent Wrapped in a Four-Step GUI
Run AI agents on your Android phone — no terminal, no CLI, just a guided setup.
At a glance
- What is it?
- BotDrop packages OpenClaw and a Termux-based Linux environment into an Android app so an agent can run on a phone without a terminal. The guided setup is the real product; the stack underneath is the constraint.
- Who is it for?
- Adopt BotDrop if you want an OpenClaw agent on a phone and you are not willing to type Termux commands, and if you accept that the agent runs inside a proot Linux environment on a phone rather than a server. Do not adopt it if you need a supported, upstream-maintained runtime: the README points to a clone URL (github.com/louzhixian/botdrop) that does not match the repository name in this listing, so verify the source you build from.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, 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 Setup Problem BotDrop Is Trying to Remove
Running an OpenClaw agent on Android normally means installing Termux, pulling a Linux userland, installing Node.js and npm, and then keeping a gateway process alive. Each of those steps assumes a terminal. BotDrop's stated goal is to remove that assumption: the README describes it as wrapping OpenClaw into a user-friendly Android app where you install, configure, and manage an agent in four steps. The audience is narrow and specific. It is someone who already has an API key for Anthropic, OpenAI, Google Gemini or OpenRouter and wants the agent reachable from Telegram or Discord, but who does not want to maintain a shell session on a phone. It is not aimed at server operators, and it is not aimed at people who want to write their own agent loop. The project's own feature list is a setup list, not a capability list: guided setup, multi-provider support, messenger integration, a background gateway, and the absence of a terminal requirement.
Four Screens Over a Termux Stack
The README gives the setup sequence as Auth, Agent, Install, Channel. That ordering is the architecture in miniature. Credentials come first, so the app knows which provider to configure before anything is downloaded. Then agent selection, then installation, then a channel binding to Telegram or Discord. The layer diagram in the README shows what sits underneath: the BotDrop UI in the app.botdrop package, Termux Core in com.termux, a Linux environment provided through proot and apt, and OpenClaw with Node.js and npm at the bottom. So the guided flow is a controller for a proot container. The Install step is where npm work happens, which is why it is separated from the configuration steps that precede it. The background gateway is described as keeping the agent running with auto-restart, and the README points to docs/design.md for the detailed architecture. That document is where you would look to understand how the gateway process is supervised and whether auto-restart survives the phone's own process management.
Building the APK and What the Toolchain Requires
The README's build path is a standard Gradle debug build. Prerequisites are an Android SDK at API level 34 or higher, NDK r29 or higher, and JDK 17 or higher. The commands given are git clone https://github.com/louzhixian/botdrop.git, then cd botdrop, then ./gradlew assembleDebug, with the output at app/build/outputs/apk/debug/. Note the mismatch: the repository in this listing is zhixianio/botdrop-android, while the README's clone URL is github.com/louzhixian/botdrop. Treat that as something to confirm before you build, because the two names do not line up and the README is the only source here. The NDK requirement is worth pausing on. A pure Java UI would not need the NDK; its presence is consistent with the native components that a Termux-derived app carries. If you only want the app, the README says to download the APK from Releases, and the most recent tagged build in this listing is v0.2.11, published the same day as the last push to master.
Where the Guided Flow Stops Being Guided
The honest limitation is that BotDrop does not remove the Linux environment, it hides it. Everything OpenClaw needs still has to exist inside proot, and the app's job is to drive apt and npm on your behalf. When a provider changes an authentication scheme, or when an npm install fails because a mirror is unreachable or a package needs a build step the container cannot satisfy, the failure surfaces inside a GUI that was designed to avoid exactly this kind of detail. There is no terminal in the product's stated design, which means the diagnostic surface is whatever the app chooses to show. That is the trade: you get a four-step setup, and you give up the ability to read the raw error and fix it by hand. The README also lists no minimum Android version, no RAM or storage floor, and no statement about which Node.js version is installed. Those omissions matter more on a phone than on a server, because the Linux userland and the npm dependency tree both live in app storage.
BotDrop Versus Doing It Yourself in Termux
The obvious alternative is the thing BotDrop is built on: Termux plus a manual OpenClaw install. The difference is not capability, it is who performs the steps. With Termux you run the package installs and the npm installs yourself, you start the gateway yourself, and you decide how it restarts. You get the full error output and a shell to act on it. BotDrop trades that for a fixed sequence of four screens and an auto-restart gateway it manages. For someone who already lives in a terminal, the manual route is strictly more transparent and probably easier to debug. For someone who does not, the manual route is the reason they never got an agent running in the first place. That is the only case where the wrapper earns its place. A second comparison is a hosted agent runtime, where the process runs on someone else's machine and the phone is just a chat client. BotDrop's selling point is the opposite: the agent runs on hardware you own, which is also why its reliability is capped by that hardware.
GPL-3.0, Termux, and What You Inherit
BotDrop is licensed under GPL-3.0, and the README states it is built on Termux, which is also GPLv3. If you fork and distribute the app, the copyleft terms travel with it; if you only run it on your own phone, the licence is not something you need to act on. I am not giving legal advice, and the LICENSE file is the authority here. The maintenance picture is more concrete. The release cadence shown in this listing is three tagged builds in the six days before the last push: v0.2.10 on 2026-03-13, v0.2.10-beta1+0de9a6f on 2026-03-16, and v0.2.11 on 2026-03-18. That is active, and it is also the kind of cadence where beta tags ship alongside stable ones, so pin to a specific tag rather than tracking master if you care about reproducibility. The upgrade cost sits in two places: the APK itself, and the Linux userland and npm packages inside it. The README says nothing about whether an app upgrade rebuilds the environment or preserves it, so treat that as unverified and check docs/design.md before upgrading a working install.
What the README Does Not Tell You
Several things a reader would want are absent from the supplied material. There is no stated minimum Android version, no device compatibility list, and no note on battery or wake-lock behaviour, which is the usual failure mode for any long-running process on Android. The background gateway is described as having auto-restart, but the mechanism is not in the README; docs/design.md is referenced for it. There is no information about how provider credentials are stored on the device, and the crash reporting document, docs/crashlytics.md, is described as covering Firebase Crashlytics setup, build behavior and privacy notes, which suggests telemetry is part of the build. Whether it is on by default is not stated here. The project is not archived and the last push is recent, so the codebase is alive. What is thin is the operational documentation, and for an app whose whole promise is that you do not need to understand the underlying system, that is the gap that decides whether it works for you.
Editorial conclusion
Adopt BotDrop if you want an OpenClaw agent on a phone and you are not willing to type Termux commands, and if you accept that the agent runs inside a proot Linux environment on a phone rather than a server. Do not adopt it if you need a supported, upstream-maintained runtime: the README points to a clone URL (github.com/louzhixian/botdrop) that does not match the repository name in this listing, so verify the source you build from. Before relying on it, read docs/design.md to confirm how the gateway survives Android's background process limits, and check docs/crashlytics.md if you build with Crashlytics enabled, because that determines what leaves the device.
Community notes