How an AI agent can use Android apps that have no API (five routes in 2026)

Disclosure: I work on Phonebox, which is the fifth option below. The other four are Google's or open source, and I've tried to be straight about what each can and can't do. A lot of the apps people want an agent to use have no API: food delivery, rides, banking, most of what's on your phone. So how does an AI agent actually get work done in them? In October 2026 there are five routes, and which one works depends on who you are and which app it is. Five ways, best first Works when Who can use it 1. The app's API or MCP server The app publishes one Anyone with access 2. Android AppFunctions The app adopted it; Android 16+; experimental System agents such as Gemini; Gemini support in private preview 3. Gemini doing it for you Select food, grocery and ride apps; Pixel 10, Galaxy S26; US and Korea The phone's owner, who taps the final order button 4. An agent framework on your own phone You connect a phone or emulator over ADB Developers; Play bans autonomous agents built on accessibility 5. An agent on its own cloud phone Any app a person can use Any agent over MCP, CLI or API AppFunctions is the clean future: apps annotate functions with @AppFunction, and agents call them directly, on the device. Google calls it "the mobile equivalent of tools within the Model Context Protocol". But it's experimental, needs Android 16, and only works for apps that adopted it, called by a limited set of system agents. Gemini's in-app tasks (beta since February 2026) can run multi-step tasks in DoorDash, Uber, Lyft, Instacart and a few others, in a virtual window on the phone. It stops before the buy button and asks you to tap it. Accessibility-based agents like Mobilerun, mobile-use and AppAgent run an observe-act loop on a phone you connect over ADB. Great for experiments. Note that Google Play's policy prohibits shipping an app that uses AccessibilityService to autonomously plan and execute actions. How an agent uses the screen Whatever runs the phone, the loop is the same: Observe. Read the screen as a list of elements with their labels (plus a screenshot). Act. Tap by visible text, type, swipe. Check. Read the new screen and confirm the result before the next step. Reading text rather than pixels is what makes it hold up: "tap Sign in" still works after a redesign moves the button. This is what an agent reads on a Phonebox phone: snapshot snp_4f2k7m3q6z3a app com.android.launcher3 keyboard hidden screen 1080x2400 [1] EditText "Search apps" #search clickable editable (540,250) [2] TextView "Chrome" #icon clickable (200,1900) Where the common tasks draw the line Food and rides. Let the agent build the order, then confirm and pay yourself. Gemini works the same way: it stops before the buy button. WhatsApp. Messaging customers belongs on the WhatsApp Business Platform: opt-in, templates outside the 24-hour window, and a limit that starts at 250 people a day. WhatsApp's Terms prohibit "bulk messaging, auto-messaging, auto-dialing, and the like" from regular and Business app accounts, and it bans accounts for it. An agent doing a few user-directed things in your own account isn't explicitly addressed; treat that as a grey area, never as a way to send in bulk. Accounts. Sign in only to accounts you own or may use. When an app wants a one-time code, a person should enter it. The fifth route That's the gap Phonebox fills: a cloud Android phone the agent drives over MCP, CLI or API, which keeps its apps and sign-ins between sessions, with nothing attached to your machine. When a step needs a person, such as a code or a payment, the agent sends a live view link and waits. Originally published on phonebox.dev. If you've found another route that works for apps with no API, I'd like to hear it.