Andee, an on-device agent that drives any Android app

One APK, no root, and a model you choose

Andee is aimed at people who want an agent on their own phone rather than a service that operates phones on the vendor's servers. The framing in the project documentation is deliberately blunt: it is not the assistant that helps you use your phone, it is the thing that lives in it. What ships is one APK, with no root and no custom ROM, targeting Android 11 and later, API 30, written in Kotlin. The brain runs on the device against any OpenAI-compatible model you select, with OpenAI as the default on an English interface and DeepSeek on a Chinese one, and the documentation says you can point it at something else either way. There is no account and no vendor backend. For a developer evaluating this, the interesting surface is the agent loop itself, which the project says is in the repository along with the guard rails. It is an unusual distribution model for an agent: not a library you import, not a web service, but a resident program on a single device.

The accessibility tree and a labelled grid, not coordinate maths

The automation mechanism is stated in one paragraph of the README and it matters more than it looks. Andee reads the accessibility tree and the screenshot, and it aims on a labelled grid instead of doing coordinate maths, which the project describes as the thing general models are worst at. That single decision removes the classic failure of GUI agents, where a vision model guesses a pixel offset and the tap lands next to the button. It also removes the need for anything from the app: no intent to expose, no SDK to adopt, no integration list to be on. The claim that follows is that if you can do it with your thumb, it can do it. The constraint hiding in that claim is that the accessibility tree has to describe the thing. An app that ships a flat or custom-drawn interface, or one that gates content behind a canvas, gives the tree less to work with, and a labelled grid cannot help where there are no labels. Nothing in the published documentation quantifies how the grounding degrades on such apps.

The dispatcher holds the refusals that a prompt cannot talk away

Here is where Andee differs from a prompt with a screen attached. The project is explicit that certain rules live in the dispatcher, not in the prompt, and that a page instructing the agent otherwise does not get its way. The concrete cases: a stranger's notification cannot unlock the vault or grant new permissions, it fills a page up to the last button and leaves that button to you, and it stops before the final confirmation of a purchase and never enters a payment password. A phone maker's assistant has no self to make that kind of refusal, which is the argument the documentation makes for the whole design. Two other behaviours belong to the same layer. The agent is biased toward silence, so it decides when to speak rather than always answering. And after a conversation goes quiet it sends itself a turn written as a message to itself, then reads the conversation back alone, which is how the project claims it behaves the same when nobody is watching. That self-directed turn is also the most unusual thing here, and the least documented: the README quotes its tone, nobody is watching you, nobody is waiting for you to answer, but says nothing about how that turn is scheduled or bounded.

A notebook that is localOnly and filtered out of the hub payload

The memory design is the part with a concrete claim a reader can check. What the agent remembers about you, habits, promises, and things it decided were worth keeping, is marked localOnly and filtered out of the hub payload, so the memory is not a profile sitting on someone else's server. The documentation also says the interface lists every entry, all of them deletable, which is a stronger statement than most agents make about their own storage. Telemetry follows the same pattern: there is no analytics SDK, no content telemetry, and the only thing ever sent back to the project is a version number and a phone model, and only when the agent checks whether an update exists. The full field list is published in docs/permissions.md, and the repository also ships a permissions document that the README anchors as a section on why each permission is needed and what happens if you refuse it. That last part is the one to read first, because a permission-based agent that operates your apps can only do as much as the permissions you grant, and a refusal is exactly where a demo stops looking like a product.

Provisioning a device: Gradle, an install script, or a build in the browser

What the repository listing does show is a standard Android project with a Gradle wrapper, a build-and-install.sh script at the root, an app module, docs/, tools/ and a reports/ directory, alongside the usual project files.

The project also offers a build online and a try-now path through codeflying.app/andee, and the badges describe it as no token setup, Android 11 plus with API 30, and Kotlin 1.9.22. First run follows the provisioning section: install the APK, walk the permission prompts, point the agent at a model, then use the scene system. Four scenes ship ready-made and are adopted from Scenes, Ready-made scenes, after which they are editable or deletable like anything else. The character layer is separate from the function layer: six looks, nineteen moods, and a face the model picks for itself mid-sentence, with the expression changing in step with the audio.

The licence is Apache 2.0 plus conditions, and the releases moved fast

Two things about governance. The licence is listed as custom, the kind GitHub cannot classify, and the badge in the README reads Apache-2.0 plus conditions, with the details in the LICENSE file, a DISCLAIMER.md in both English and Chinese, a THIRD_PARTY_NOTICES.md and a SECURITY.md in the repository root. That combination is normal for an agent that ships a model-aware runtime, but it means the licence text has to be read rather than assumed, and it is not the plain Apache 2.0 a badge might suggest. The other fact is release cadence. Three versions landed in four days: v0.5.0 on 2026-10-16, v0.5.1 on 2026-10-19 and v0.5.2 later the same day, and the last push was on 2026-10-19. A CHANGELOG.md is included. This is a project in motion, which helps if you want to report problems and hurts if you need a stable build: there is no long-lived branch or pinned artefact described anywhere, so a device in the field is running whatever APK you last installed.

Where Andee is the wrong tool

Three cases come to mind. If you want an agent to complete a purchase unattended, Andee is the wrong shape, because the dispatcher stops before the final confirmation and never enters a payment password by design, and no configuration is documented that changes that. If your workflow is one integration with one service, an app that exposes a proper intent or SDK is less work than teaching an agent to read a screen, and the project says as much when it notes that it needs nothing from the app. And if your threat model assumes nothing leaves the device, read the model configuration first, because the default on an English interface is OpenAI and the default on a Chinese one is DeepSeek, so the on-device claim covers the agent's reasoning and its notebook, not necessarily the traffic of the model you point it at. The documentation does not publish a model list, a token cost estimate, or a measured accuracy figure for any of this, so those are open questions a pilot has to answer.

Editorial conclusion

Andee suits people who want one agent to operate many apps on a phone they control, and who are willing to review the permissions listed in docs/permissions.md before handing over a device. It does not suit unattended purchase flows, since the dispatcher stops before the final confirmation, and it does not suit anyone who assumes the on-device claim survives a cloud model endpoint. Before installing, read LICENSE, because the licence is classified as custom with extra conditions, check what changes when a permission is refused, and confirm that the model you point it at actually runs where you think it runs.

Frequently asked questions

Official sources

1. Issues
2. kuafuai/andee on GitHub
3. Project website
4. README
5. Releases