AppFunctions for Android Developers: Android's MCP Moment for Mobile Apps

14 min read

androidaospaimobile

I went looking through recent Android open source work for something more interesting than another model wrapper. The thing that stood out was not a chatbot UI. It was AppFunctions, Android’s early answer to a question every mobile team will probably face: what should your app let agents do?

The interesting part is not that Android has another AI API. It is that Android apps may soon need to describe their own actions as safe, typed tools.

The short version: Android is building an OS-level way for apps to expose small, typed actions that agents can discover and run on device. The Android AppFunctions overview says AppFunctions let apps provide “services, data, and actions to the registry built into the Android OS,” so users can complete tasks through agents and system-level interactions. The same page compares AppFunctions to tools in the Model Context Protocol, but with Android-native hooks that execute locally instead of only through cloud tools.

That is why this feels like Android’s MCP moment for mobile apps. Not because the APIs are identical, but because the shape is familiar: an agent chooses a tool, fills structured parameters, and asks the owner of that tool to execute the work. The mobile difference is that the tool can be app-owned code running near local state, account context, permissions, offline behavior, and user trust boundaries.

The timing matters too. Android 16 is already live, and the AppFunctions docs say the API is available on devices running Android 16 or higher. The part that is still early is the broader agent story: Gemini integration is in private preview with trusted testers as of May 2026, and AppFunctions are still labeled an experimental preview. So the OS requirement is here, but the API shape, permissions, and assistant behavior can still change. Google is also publishing an AppFunctions sample app and an AppFunctions agent skill, which makes this feel aimed at Android developers, not just platform teams.

If you build Android apps, this matters because agent actions are becoming an app architecture problem, not just an assistant feature. The hard part is not adding an annotation. The hard part is deciding which parts of your product should become callable, which ones should only create drafts, and which ones should never be executable through an agent at all.

My take: do not treat AppFunctions as “add AI to your app.” Treat them as a new product boundary. The question is not only whether an agent can call your app. It is which actions your app should safely expose.

That changes the mobile AI story from:

The assistant can talk about your app.

Into:

The assistant can ask your app to do a specific thing, through a system-owned boundary.

That moves the assistant from navigation into execution, which is where mobile product design gets harder.

Why Android developers should pay attention

The short answer: study it now because Android 16 is already live, but do not treat it as a broad production agent channel yet.

The clearest sign is that the official docs are not only describing an assistant feature. They are describing a developer integration surface:

This lets you expose your app’s capabilities as orchestratable “tools” that authorized apps (callers) can discover and execute to fulfill user intents.

That sentence is the whole idea. Android apps can expose capabilities as tools, but the caller still needs platform permission. This is not just a marketing line about Gemini.

The Jetpack release notes make the developer angle even clearer. The library description says AppFunctions let apps share functionality and data with AI assistants, “enabling them to discover and execute tasks directly on the device to fulfill user requests.” This is not just API plumbing. Recent alpha notes cover things Android developers actually need: constraints for Int and String parameters, natural-language descriptions for LLMs, user-visible descriptions inside agent apps, URI grants for returned files, and Robolectric support through AppFunctionTestRule.

So the work is not “add AI.” It is more concrete:

identify the app workflows that should be callable
model inputs and outputs as typed functions
write descriptions good enough for agents to choose correctly
decide which actions need confirmation
test the app function boundary before real agents depend on it

Google’s own AppFunctions sample repository reinforces that. The sample is a chat app with AppFunctions for sending messages, searching contacts, and initiating calls. These are not toy examples. They are real product actions where wrong execution would matter.

A practical AppFunctions checklist

If I were evaluating AppFunctions for a real app, I would use this checklist before writing much code:

List repeated user intents that already map to clear app actions.
Start with reversible or reviewable actions, not high-risk commits.
Model each function with narrow typed inputs and explicit result types.
Write descriptions that help an agent choose the right function, not marketing copy.
Separate prepare and commit steps for risky workflows.
Require confirmation when the action affects another person, money, security, or public content.
Make account, workspace, and tenant selection explicit.
Decide offline and sync behavior before agents depend on the function.
Add tests around the function boundary, including wrong caller, missing parameter, and ambiguous state cases.
Log agent-triggered actions in a way that users and support teams can understand.

The checklist is boring on purpose. AppFunctions are interesting because they make app capabilities callable, but trust comes from small, predictable, well-modeled actions.

Why this caught my eye

A lot of AI features on mobile still feel like a layer pasted on top of the real app. They summarize, rewrite, or search, but execution gets awkward. The assistant asks the user to open the app, the app builds its own assistant surface, or a backend tool calls an API without local app context.

AppFunctions suggest a cleaner model: users speak naturally, while apps keep owning the action.

What AOSP shows

The public Android docs give the high-level pitch, but AOSP makes the architecture easier to reason about. AppFunctionManager says most developers should use the AppFunctions SDK for type-safe schemas, parameter classes, and return values. Internally, those SDK types become ExecuteAppFunctionRequest parameters and ExecuteAppFunctionResponse result documents.

The core flow is simple:

The app defines AppFunctions and static metadata.
A caller discovers available functions through metadata.
The caller builds an ExecuteAppFunctionRequest.
Android routes the call through AppFunctionManager.
The app’s AppFunctionService executes the action.

The AOSP Javadoc example is a note-taking app. An assistant tries to fulfill “Save XYZ into my note,” finds a note-taking function, builds a request, and executes it. The point is not the note app. The point is the level of abstraction: the assistant is not screen scraping UI. It is calling a declared app capability.

The service side lives in AppFunctionService. It is a bound service protected by android.permission.BIND_APP_FUNCTION_SERVICE, which AOSP defines as a signature permission. Arbitrary callers are not supposed to bind directly to app function services. The system sits in the middle.

The architecture in one picture

At a high level, I read AppFunctions as four layers:

User intent
  "Add oat milk to my grocery list"
        |
        v
Agent or assistant
  chooses a function and fills parameters
        |
        v
Android App Function manager
  checks caller, metadata, enabled state, and user boundary
        |
        v
Target app service
  runs app-owned code against local app state

This is close to the tool-calling shape many people already know from LLM systems, but with a mobile-specific difference: the tool is local app code, not only a remote server.

The AppFunctions overview makes the same comparison directly. It calls AppFunctions the mobile equivalent of tools in the Model Context Protocol, but notes that standard MCP is platform-agnostic and often cloud-based, while AppFunctions are Android OS-level hooks that execute locally.

If the action depends on local auth, app settings, offline state, recent local cache, account selection, or device-owned permissions, doing it inside the app is often cleaner than bouncing through a cloud tool.

A small example

Imagine a grocery app exposing a function for adding an item.

The app-owned function might look roughly like this with the Jetpack library shape:

This is pseudocode, not a complete compiler-ready sample. A real app would also add AppFunctionContext, serializable parameter and result types, better descriptions, constraints, error handling, and tests. The Jetpack AppFunctions reference says the compiler generates an XML file that describes the signatures of @AppFunction-annotated functions and provides infrastructure to expose them through android.app.appfunctions.AppFunctionService.

That generated metadata is the interesting part. The assistant should not need to know the grocery app’s internal UI. It needs to know that a function exists, what parameters it needs, and what result comes back.

A user could say:

Add two cartons of oat milk to my Costco list.

The assistant maps that to:

The app still owns the final behavior. It can decide which account is active, whether the list exists, how sync should work, how undo should work, and what to show next time the user opens the app.

That is the part I like. The agent handles intent. The app keeps product ownership.

Why this is not just deep links

Android already has intents, app links, shortcuts, widgets, slices, and accessibility. So it is fair to ask: why add another mechanism?

AppFunctions solve a different problem.

Deep links are good at navigation. They answer: “Where should this user go?”

AppFunctions are about typed execution. They answer: “What app-owned action should happen, with which structured inputs, under which caller permissions?”

For AI agents, that difference matters. Natural language has to become something executable. If the only target is a URL or screen, the assistant still depends on the app UI to finish the task. If the target is a typed function with metadata, the assistant can choose a more precise action.

A useful mental model:

Intent or app link: bring the user to the right surface.
Shortcut: expose a common user action.
AppFunction: expose a typed operation that an agent can discover, fill, and execute.

These can work together. A safe AppFunction might perform the action directly and return a result. A risky one might create a draft and deep link the user to a confirmation screen.

The security boundary is the product

The most important part of this system is not the annotation. It is the boundary around execution.

AOSP has separate permissions for this. In AndroidManifest.xml, EXECUTE_APP_FUNCTIONS_TRUSTED is defined for trusted apps that can act on behalf of users with system privacy guarantees. EXECUTE_APP_FUNCTIONS is documented as a System API permission for preinstalled or system apps with the ASSISTANT role.

That tells me Android is not treating this as “any app can call any app’s private tool.” It is closer to a mediated agent boundary.

That boundary matters because agent actions have a different risk profile from normal navigation. A deep link can open a compose screen. An AppFunction might send the message. A shortcut can start a task. An AppFunction might complete it with parameters inferred from conversation.

So apps need to decide which functions should execute immediately, require confirmation, expose only read access, return a draft, or produce an audit trail. The platform mediates execution, but app teams still own the confirmation, undo, and trust UX for their domain.

This is where good app design matters more than clever AI plumbing.

A better example: message drafting

A messaging app could expose two different functions:

The first function is low risk. It creates a draft. The second is higher risk. It sends.

An assistant could help the user say:

Tell Alex I will be 10 minutes late, but make it polite.

The safer flow is:

The assistant calls createDraftMessage.
The app returns a draft ID and preview text.
The app or assistant asks for user confirmation.
Only then does sendMessage run.

This split gives the product a clean policy boundary. Drafting is agent-friendly. Sending is user-confirmed.

That is the design AppFunctions should encourage: not “let AI do everything,” but “make the right app actions callable with the right guardrails.”

Where it can get messy

I like the direction, but the hard parts are real.

Discovery quality matters. If functions have vague names or weak descriptions, agents will choose poorly. The Jetpack release notes already mention natural-language descriptions for LLMs, which suggests metadata quality is part of the design, not an afterthought.

Confirmation UX will be hard. “Add a grocery item” and “transfer money” should not feel the same.

Account, offline, and policy behavior still belong to the app. Workspaces, tenants, sync queues, managed devices, and work profiles need explicit handling. The OS boundary does not remove product choices.

Private preview means the public story is not finished. Android 16 is live, but Gemini integration is still in private preview with trusted testers. Developers can prepare, but this is not yet the same as every installed assistant having broad production access.

What I would expose first

For most Android developers, I would treat AppFunctions as watch closely and prototype lightly. I would not rebuild an app around them yet. Android 16 is live, but the public docs still say Gemini integration is in private preview, and the dependency is still alpha.

But I would spend a day mapping a real app’s workflows if the app has clear, repeated, user-owned actions: notes, todos, messages, shopping lists, bookings, media search, or enterprise status updates.

The Android developer takeaway is simple: AppFunctions make your app’s core workflows legible to the system. If agent interfaces grow on Android, apps with clean, typed, well-described functions will be easier for agents to use than apps that only expose screens.

If I were adding AppFunctions to a real app today, I would start with boring, reversible actions:

create a draft note
add a todo item
search local app content
create a calendar-like hold inside the app
summarize an app-owned record
attach a tag
prepare a shareable draft

I would avoid starting with irreversible actions:

send money
delete data
message another person
change security settings
publish public content
invite teammates

For high-risk actions, I would split the API into two steps: prepare, then confirm. That is the product version of the same checklist: make the agent useful, but keep the final trust boundary visible.

That two-step shape is less magical, but it is much easier to trust.

My bottom line

AppFunctions are interesting because they make AI integration feel like a mobile architecture problem again.

The hard questions are familiar: source of truth, active account, offline behavior, confirmation, partial failure, user feedback, and audit logs. The agent does not remove those questions. It makes them more visible.

The apps that win here will not be the ones with the most AI features. They will be the ones that expose the right actions, with the right guardrails, before agent interfaces become normal on Android.

Comments

Loading…