Eta: An Android Agent That Steps Outside the App Sandbox

The gap Eta is aimed at: Android apps cannot reach the system

The README is candid about the motivation. Desktop agents work because they inherit a shell, a file system and installable command-line tools. On Android, the README argues, a normal app sees a restricted set of directories and system capabilities, so an agent can run commands but still cannot reach the data locked inside other apps. Eta tries to close that distance by giving the agent three routes into the device at once: direct Android API and Intent calls, accessibility-driven UI control, and a Linux environment for scripts and dependencies. The target user is someone who already uses a phone assistant and finds it too shallow for multi-step work. The project also states plainly that BYOK is the baseline, so the model and provider are the user's choice rather than the vendor's. That framing matters: Eta is not trying to be a better chatbot, it is trying to be an execution layer that happens to live in a chat interface.

One Agent Loop, three ways to touch the device

The README describes a single Agent Runtime inside the app. Requests from the chat screen and from system assistant entry points share the same Agent Loop, which orchestrates model calls, tool execution and result feedback. The model selects tools through Tool Calling, arguments are validated against JSON Schema, and permissions are re-checked immediately before execution. The README notes that a Hook process handles only entry and result relay, which suggests the Xposed side is deliberately kept thin rather than hosting agent logic. Tool categories are distinct in mechanism. System API calls use Android APIs and Intents for alarms, media and volume, avoiding UI navigation entirely. The GUI Agent uses the accessibility UI tree, control location and on-demand screenshots to click, scroll and type, with an overlay showing progress and offering stop or takeover. The built-in browser is a WebView that can load JavaScript pages, read body text, manipulate the DOM and capture screenshots, and the user can open the same session to take over. The terminal offers Android user or root shell, Alpine or Debian Linux, file read and write, plus sessions, asynchronous commands and daemon tasks. A single task can chain these, for example reading a web page and then scripting file cleanup.

Getting it running: APK, API key, then permissions

The quick start is short. Download the APK from the Releases page, install it, then open the model provider settings and enter an API key and pick a model. The README states that task execution requires Tool Calling, and image understanding requires a model that accepts image input. After that, tool switches and permissions are configured per task: the GUI Agent needs the accessibility service, notifications and app usage need separate grants, and the location tool needs always-allow. The tools page shows what the current device can actually do. Linux is optional and installed from the Linux tool environment screen, where you choose a distribution and base tools, then add development tools such as Python, Node.js, SSH, APK analysis or Kimi Code. Provider configuration is not limited to a fixed list. The README names OpenAI, Anthropic, Alibaba Bailian, DeepSeek, Kimi, MiMo, MiniMax, StepFun, SiliconFlow and OpenRouter as built-in entries, with support for adding custom services. The provider layer covers OpenAI-compatible Chat Completions, the Responses API and Anthropic Messages, including SSE, Tool Calling, image input and reasoning content, and you can edit the base URL, request headers and request body.

What you give up without root, and what root still does not fix

Eta separates device classes explicitly. On an ordinary device running Android 14 or newer you get chat, the browser, memory, Skills, MCP, the standard terminal and the private workspace, with GUI control and local information reads granted on demand. Linux requires a 64-bit device. Root opens system setting changes, app management, protected files, dedicated personal data retrieval, root shell and chroot. LSPosed and a compatible ROM open vendor assistant takeover, system shortcuts and the Google capability enhancements. The README is direct that contacts, SMS and calendar retrieval still need root, and that some personal context sources additionally need matching ROM and app support. Two boundaries are easy to underestimate. First, the README states that the simulated root inside PRoot does not grant Android system permissions, so a Linux shell is not the same as a rooted device. Second, background execution is subject to Android and vendor process management, so after a force stop or reboot the agent must be started manually, and system or app updates may require the Hook to be adapted again. That last point is a recurring maintenance cost, not a one-time setup step.

Data flow, permissions and the licence question

The README devotes a section to data boundaries and it is worth reading before installing. Conversations, images and tool results needed for a task are sent to the configured model service, and the README states explicitly that a local runtime does not mean local inference. Custom HTTP endpoints transmit the API key and request content in cleartext. Sensitive tool and MCP raw arguments and results are not written to persistent sessions, though model replies still are. Notification history, once authorized, keeps the last seven days up to a maximum of 1000 entries, and MCP authentication tokens are stored encrypted. Conversation, model configuration and memory can be exported and imported, and the README notes that backups include API keys. System tools, sensitive reads, sensitive operations, terminal and file access, web browsing and memory each have an independent switch, currently on by default, and the runtime re-checks permissions before execution so revoking access does not overwrite saved configuration. The licence is the open question. Repository metadata reports NOASSERTION, which means no standard licence identifier was detected, so anyone planning to redistribute or build on the code should read the repository's own terms rather than assume a permissive licence.

Skills, MCP and memory: extension without automatic trust

Extensibility is handled through three mechanisms. Skills load task methods, reference material and script resources on demand, and can be installed from a public GitHub repository or imported as a local ZIP. The README makes a specific claim about installation behaviour: installing a Skill does not execute scripts or grant additional permissions. That is a meaningful design choice, because it separates fetching content from running it. MCP connects to remote tools over Streamable HTTP with Bearer Token support, and each tool is enabled individually so remote tools sit alongside local ones in the same task. Long-term memory uses a local MEMORY.md file, with core content added to context under a budget and the rest read on demand, and memory can be edited, cleared or turned off. The practical consequence is that trust is per-item. A Skill you import and an MCP tool you enable are separate decisions, and the permission model still applies at execution time. The README does not describe a sandbox for Skill scripts, so the claim that installation is inert should be read as applying to installation, not to later execution.

The alternative that shaped this design, and where it failed

Eta's README names Doubao's phone assistant as the reference point for cross-app GUI operation, and then documents what happened to it. In December 2025, according to the README, some users hit WeChat crashes and login restrictions, and Doubao withdrew its ability to operate WeChat. In the same period there were reports of Taobao human verification and banking apps asking users to disable screen sharing, and WeChat attributed the problem to existing risk controls. Doubao also announced restrictions on incentive farming, financial apps and some game scenarios. The README reads this as evidence that even with system-level permissions, a single agent cannot open up an app ecosystem on its own, because apps keep accounts, data, services and transactions inside their own loops. The difference in approach is worth stating precisely. Doubao operated through vendor cooperation at the OS level. Eta instead runs as a third-party app that borrows system entry points through Xposed and uses accessibility plus screenshots to drive apps that expose no API. That avoids needing each vendor's cooperation, but it also means Eta inherits the same friction: apps that treat automation as a risk signal will react to it regardless of who is driving.

Who this fits, and what to check before you commit

Eta is a reasonable fit for an engineer who wants a mobile agent that can actually execute: call system APIs, drive a UI where no API exists, drop into a Linux shell, and point at a model of their own choosing. It is a poor fit for anyone who needs a hands-off install. The capability table is tiered by device state, and the most interesting items (protected files, dedicated personal data retrieval, vendor assistant takeover, circle-to-search) sit behind root or LSPosed plus ROM support. Verify three things first. Check docs/ROOTLESS_SUPPORT.md against your exact device and ROM, because the README points there for full conditions and validation scope. Confirm your model supports Tool Calling and, if you want screen understanding, image input, since the quick start states both as requirements. Read docs/TECHNICAL.md for the Gemini and circle-to-search adaptation notes, because the README warns that system and app updates can require the Hook to be re-adapted. Then decide whether sending task conversations, images and tool results to a third-party model endpoint is acceptable for the data on that phone.

Editorial conclusion

Adopt Eta if you run Android 14 or newer on a device you are willing to root and equip with LSPosed, and you accept that your prompts, screenshots and tool results go to whichever model provider you configure. Skip it if you need a locked-down corporate device, an unrooted daily driver with full personal-data retrieval, or a project with a clearly declared open source licence, since the repository metadata reports NOASSERTION. Before installing, check docs/ROOTLESS_SUPPORT.md for your exact device and ROM, confirm your chosen model supports tool calling and image input, and read docs/TECHNICAL.md to see whether the Gemini and circle-to-search hooks cover your build.

Official sources

1. Issues
2. Mangi-11/Eta on GitHub
3. README
4. Releases