botdrop-android: the build recipe clones a different repository

The build recipe clones a different repository path

The build-from-source block opens with a clone URL that does not match the repository hosting it:

git clone https://github.com/louzhixian/botdrop.git
cd botdrop

export BOTDROP_BUNDLED_OPENCLAW_VERSION=2026.3.13
QQBOT_VERSION=1.5.4
./scripts/build-openclaw-bundle.sh "$BOTDROP_BUNDLED_OPENCLAW_VERSION"
./scripts/build-qqbot-plugin-bundle.sh "$QQBOT_VERSION"

export BOTDROP_OPENCLAW_BUNDLE_TGZ="$PWD/build/openclaw-bundles/openclaw-runtime-${BOTDROP_BUNDLED_OPENCLAW_VERSION}.tar"
export BOTDROP_QQBOT_PLUGIN_DIR="$PWD/build/openclaw-bundles/qqbot-sliverp-qqbot-${QQBOT_VERSION}/package"
./gradlew assembleDebug

This project is zhixianio/botdrop-android, on a default branch called master. The clone line points at another owner and another project name, and the directory it creates is botdrop rather than botdrop-android. A reader who follows the instructions literally builds something other than the tree they are reading, and nothing in the file explains a fork, a rename, or which of the two is the one to use.

The rest of the block hangs together. Two versions are pinned as shell variables, two build scripts turn them into bundles under build/openclaw-bundles/, two environment variables hand those bundles to Gradle, and assembleDebug does the work. That sequence is the only complete recipe in the project, which makes the clone line the single place where the whole thing can send you to the wrong source.

The only documented build is an arm64 debug APK

`./gradlew assembleDebug` is the only build command in the documentation, and the output it names is qualified twice: the APK will be at `app/build/outputs/apk/debug/`, arm64 only. Debug, arm64, nothing else. No release variant is documented, no signing configuration is described, and no keystore step appears anywhere. Distribution therefore runs through the releases page rather than through a reproducible local build: a user installs a prebuilt APK, while anyone rebuilding gets a debug-signed, single-architecture artifact for their own device.

The prerequisites are more specific than that. Android SDK Platform 36, NDK 29.0.14206865, JDK 17, and Node.js with npm for preparing the bundled runtime. Those pins are exact down to the NDK build number, which says the toolchain is deliberate. The cost is that a mismatch is not negotiable, and no fallback is offered for a machine that cannot supply NDK 29.0.14206865.

Bundle preparation also requires network access, so the offline setup the app performs on a phone is something the build creates rather than something the build itself demonstrates.

The build bundles a QQ plugin the feature list omits

The features list names Telegram and Discord as the messenger integrations, and the build prepares a QQ plugin. One of the two scripts before Gradle runs does that work:

./scripts/build-qqbot-plugin-bundle.sh "$QQBOT_VERSION"

with the plugin directory exported as build/openclaw-bundles/qqbot-sliverp-qqbot-1.5.4/package. So the QQ path is a versioned part of the build at 1.5.4, and it appears in neither the feature list nor the setup flow. The 4-step path, Agent, Install, Auth, Channel, names no messenger at all, which leaves a reader guessing which channels the guided setup actually offers on first launch.

The same asymmetry runs through the tree. Top-level entries include api/, server/, site/, manager/, worker/, common/, starter/, shell/, terminal-emulator/, terminal-view/ and termux-shared/, and none of them is described beyond one architecture diagram and two links, to docs/design.md and docs/crashlytics.md. For a project whose pitch is a guided setup, the documentation covers the guided part and leaves the rest of the surface to browsing.

The install link is a relative path, not a releases page

The installation section sends users to the newest build with a relative link:

../../releases

Read from the repository root, that path does not resolve to a GitHub releases page; it only makes sense from a directory two levels down. As written, the instruction to download the latest APK has no working destination for anyone reading the file where it lives, and no release URL is offered in its place.

That matters more than a broken link usually does, because this is the only install route the project describes. There is no store listing, no install script, and no sideloading walkthrough beyond the releases page itself. A reader who wants the app rather than the source has exactly one instruction to follow, and it is the one carrying the relative path.

Versions also appear twice over. Three release notes sit at the top level, RELEASE_NOTES_v0.2.4.md, RELEASE_NOTES_v0.2.6.md and v0.2.2-feature-checklist.md, covering early milestones, while the newest published tag is v0.2.11. The notes a user would most want are the ones that do not exist as files.

A terminal emulator and a proot userland sit under the GUI

The architecture section says BotDrop is built on Termux, and the diagram it prints is a four-layer stack: the BotDrop UI under the package name app.botdrop, Termux Core under com.termux, a Linux environment provided by proot and apt, and OpenClaw with Node.js and npm at the bottom. The app that promises no terminal and no CLI ships a terminal emulator underneath and runs the agent inside a proot Linux userland.

The tree backs that reading up. terminal-emulator/, terminal-view/, termux-shared/, shell/, starter/ and worker/ are vendored at the top level, which is what a Termux derivative looks like when it stops depending on a separately installed Termux app. A shizuku-official-api-manifest.gradle file sits beside them, so a Shizuku API dependency is part of the Gradle build, yet Shizuku is named in neither the setup steps nor the architecture text.

docs/design.md is described as the original design proposal, with some flows differing from the current implementation. That is a candid warning, and also the only pointer to why any of this is shaped the way it is.

Tags stopped in March 2026 while commits continued

Three releases are published: v0.2.10 on 2026-03-13, v0.2.10-beta1+0de9a6f on 2026-03-16, and v0.2.11 on 2026-03-18. The last push to the default branch is dated 2026-09-17.

That gap is roughly six months of commits with no new tag, and it changes how the version numbers elsewhere in the project should be read. Anyone who installs the newest APK is running code from March rather than from the current tree, and the OpenClaw version pinned in the build recipe, 2026.3.13, comes from the same window. Comparing an installed app against a fresh clone is therefore not a like-for-like check unless you build both.

The tree holds fastlane/ and site/, the kind of directories a release pipeline lives in, and neither is described in the README, which contains no release instructions at all. Combined with the missing release build command, that leaves the tagging step undocumented: the project publishes binaries without saying how a build becomes a tag.

Two license files and an unreferenced CLAUDE.md

The repository ships two license files at the top level, LICENSE and LICENSE.md, while the licensing section links to LICENSE. Both the app and the Termux base it is built on are GPLv3, and the README repeats that in its own line, so the terms themselves are not in doubt even where the file reference is.

The governance files are less tidy. AGENTS.md and CLAUDE.md sit at the root next to CONTRIBUTING.md and SECURITY.md, and the contributing section points only at CONTRIBUTING.md. For a project whose entire mechanism is a set of instructions an agent follows, leaving its own agent instruction files unreferenced is a small oddity: a contributor entering through the documented path learns nothing about them.

Crash reporting is the one place where a non-obvious choice is explained properly, with docs/crashlytics.md covering Firebase Crashlytics setup, build behavior and privacy notes. Whether crash data leaves the device is exactly the question an app bundling an agent gateway should answer before install, and here the answer exists but only for a reader who goes looking for the second link in the README.

Editorial conclusion

Use botdrop-android if you want OpenClaw running on a phone without touching a terminal, and treat the documentation gaps as part of that bargain: the source path clones a different repository, the only build is arm64 debug, the QQ plugin never appears in the feature list, and the newest tag is v0.2.11 from March 2026 while the branch has moved on since. Before trusting an install, confirm which APK you actually have, whether its bundled OpenClaw runtime matches the version the build recipe pins, and whether release notes exist for that tag, since the tracked notes stop at v0.2.6.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. zhixianio/botdrop-android on GitHub