# OneBox keeps upstream package names on purpose, and ships an eight-flavor build

> An Android toolbox whose agent drives 90-odd on-device tools, where the source deliberately leaves inherited package paths unchanged to keep a diff against upstream reviewable, and where eight product flavors mean the Play build and the repository build differ in which SDKs they contain.

**wangzhishou/OneBox** — A free AI-agent toolbox for Android,  一站式安卓AI Agent工具箱

- Repository: https://github.com/wangzhishou/OneBox
- Website: https://www.oneboxable.com
- Stars: 584 · Forks: 90
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/wangzhishou-onebox

## The agent runs inside the app sandbox and the tools are local

The permission story is stated as a property of the architecture rather than a promise in a policy document. Everything the agent does stays inside the app's own Android sandbox and its declared permission set, and it is explicit that it never touches contacts, SMS or call logs. Local tools run entirely on the device, and the only thing that goes online is the conversation with whichever model you configured. The agent itself can invoke more than 90 in-app local tools covering PDF processing, image editing, file management and bookkeeping, and it chains multi-step tasks across them, with per-tool timeouts and iteration limits as the guard rails. Those two limits are the ones to look for in a tool-calling agent, because an unbounded loop over a tool that fails silently is the failure mode that turns a helpful assistant into a battery drain, and the readme names the limits without giving values.

## Eight product flavors, and only one of them is verified

The app module uses two flavor dimensions. The product dimension has eight values, five of which are Chinese distribution channels, one that is the default Google channel, one that is the project's own channel, and one that is a fully free-software build. That last one is described precisely: no Google mobile services, no Firebase, no WeChat and no Alipay SDKs, and it is the variant continuous integration verifies. The ABI dimension has arm64 and a universal option, 64-bit. The practical consequence is that the application you get from the Play listing and the application you build from this repository are not the same binary, and the differences are not cosmetic: a payment SDK's presence changes what the app can reach. The readme also says custom engines, endpoints and tokens are fully open in the Google Play build and in builds from this repository, which means a user-supplied API key is the intended configuration rather than a workaround. Two keystore templates sit at the root, one for the Google channel and one generic, so release signing is expected to be configured rather than improvised.

## Paths under the upstream package are left unchanged on purpose

The architecture entry points section contains the most useful sentence in the readme for anyone about to modify this code. Paths beginning with one package prefix are inherited from an upstream image-editing project and are left unchanged on purpose, so the diff against upstream stays reviewable, and everything written for this project lives under two other package prefixes. The consequence is visible in the entry points themselves: the runtime navigation root and the route definitions both sit under the inherited prefix, while the top-level shell selector and the adaptive navigation layout sit under the project's own. So the place you would instinctively look for the app's navigation root is not where it is, and a rename that would be a one-line change in a normal project would rewrite hundreds of upstream files. That trade is defensible for a fork that intends to pull upstream changes, and it is the wrong trade for a fork that intends to diverge, which is worth deciding before the first commit rather than after.

## The build pins a recent toolchain and the sources of truth are named

The build requirements are unusually specific and the readme does the right thing by naming which files override them. Use the bundled Gradle wrapper, JDK 17, and a compile, target and minimum SDK of 37, 37 and 24. The toolchain is Kotlin 2.4.0 with Android Gradle Plugin 9.3.1. Then the sentence that saves an afternoon: when in doubt, the version catalog and the wrapper properties are the source of truth. That is a project telling you the prose can drift, which is common in build documentation and rarely admitted. The clone instruction is a shallow clone and gives the reason, which is that the repository carries a lot of binary assets:

```bash
git clone --depth=1 https://github.com/wangzhishou/OneBox.git
```

The commands section leads with a single-variant debug assemble for the default channel rather than a full build, which is the right first command on a repository this size, alongside a task-listing invocation for finding the variants you actually want.

## The agent can reach a computer over the network, and that is a separate tool

One feature sits outside the app sandbox in a way the permission paragraph does not cover, and it is worth reading on its own. There is a client for an external harness agent, which lets a desktop agent running on your computer be driven from the phone, paired by scanning a code, end to end encrypted, working either over the local network or through a cloud relay. The computer side is a separate open-source plugin repository, installed with a plugin-add command. Two things follow. The privacy claim covers what the in-app agent does, and this feature deliberately routes around the device, so the boundary the readme draws is the app sandbox, not the phone. And the relay option means the pairing can traverse infrastructure neither side controls, which is a different trust relationship from a local network connection even with the same encryption. The local tools claim and the remote control claim are both true and they are not the same claim, so a reader assessing what leaves the device has to read both.

## Two icon libraries and a web subproject in an Android app

The dependency list has one oddity worth flagging. The project depends on two separate icon sets, one at a 1.x version and another at 3.x, which in a Compose codebase is two component vocabularies for the same job and a visible inconsistency in any screen that mixes them. The repository structure also includes a web frontend source directory for the file-transfer module, described as an esbuild project, so part of the app is a web bundle built by a different toolchain than the Gradle build that produces the rest. A file transfer module implemented in a web view is a reasonable choice for drag and drop and directory picking, and it is also the part of the app most likely to be affected by web view version changes on a given Android release, which is a maintenance surface the Gradle configuration does not describe. Neither of these is a problem on its own. Both are places where a future maintainer will lose an afternoon, which is why they are worth naming now.

## Two homepages, one application id, and a funding link

The distribution story is the part with the most moving pieces. There are two sites, one for international users and one for China, and the Chinese one has a different domain from the English one even though the application identifier is the same. The Play listing and a free-software repository are both linked as download channels, and the Chinese instruction is to search the app's name in five vendor stores, which covers Xiaomi, a Tencent app store, OPPO, vivo and Huawei. The five vendor channels in the store list are the same five product flavors in the build matrix, so a user in China installs a binary with that vendor's SDK in it, and the same source produces a build with none of them. The project also links a funding page and carries a code of conduct, a contributing guide, a security policy and a run document at the root, so the governance surface is present even though the repository is mostly application code.

## Conclusion

OneBox is a real application rather than a demonstration, and the two things worth understanding before you build it are the flavor matrix and the upstream inheritance. The app module carries eight product flavors, five of which exist for Chinese distribution channels and one of which is a fully free-software build with no Google services, no Firebase, no WeChat and no Alipay SDKs, and that flavor is the one continuous integration verifies. If you are auditing what an install can reach, that matrix is the answer: the Play listing and a build from this repository are not the same binary, and the documentation says custom endpoints and tokens are open in both, so a user-supplied key is the intended configuration. Read the architecture entry points before changing navigation, because the runtime navigation root lives under the inherited upstream package rather than the project's own, which is a deliberate choice to keep diffs reviewable and a real hazard for anyone assuming the project's namespace is where the app starts. The last commit on the default branch main is dated 1 October 2026 and the newest release is 1.4.4 from the same day.

## FAQ

### What can the OneBox agent actually do?

It invokes more than 90 in-app local tools, covering PDF processing, image editing, file management and bookkeeping, and chains multi-step tasks across them with per-tool timeouts and iteration limits. Everything stays inside the app's own Android sandbox and permission set, and it never touches contacts, SMS or call logs.

### How do I build OneBox from source?

With a shallow clone, the bundled Gradle wrapper, JDK 17, and compile, target and minimum SDK values of 37, 37 and 24. The version catalog and the wrapper properties are named as the source of truth over the prose. The first command to run is a single-variant debug assemble for the default channel.

### What are the OneBox product flavors?

Eight on the product dimension, five for Chinese vendor channels plus a Google channel, a project channel and a fully free-software build with no Google services, no Firebase, no WeChat and no Alipay SDKs, which is the variant continuous integration verifies. The ABI dimension offers arm64 and a universal option.

### Why does OneBox keep some code under an upstream package name?

Paths under one inherited package prefix come from an upstream image-editing project and are left unchanged so the diff against upstream stays reviewable. New work lives under two other prefixes. The runtime navigation root and route definitions sit under the inherited prefix, so they are not where the project's own namespace would suggest.

## Sources

- [License: Apache-2.0](https://github.com/wangzhishou/OneBox/blob/main/LICENSE)
- [Project website](https://www.oneboxable.com)
- [README](https://github.com/wangzhishou/OneBox/blob/main/README.md)
- [Releases](https://github.com/wangzhishou/OneBox/releases)
- [wangzhishou/OneBox on GitHub](https://github.com/wangzhishou/OneBox)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wangzhishou-onebox