March 2027 Is Closer Than You Think: Android's AppFunctions Mandate

Platform mandates have a predictable lifecycle: announced to little attention, ignored for a year, then a scramble in the final quarter. Android's AppFunctions requirement is in the quiet middle phase right now - which is exactly when acting on it is cheap.

The fact: under Google's AEP guidelines, apps in messaging, notes, calendar, productivity, finance, and retail categories must expose AppFunctions by March 1, 2027.

What AppFunctions actually is

AppFunctions is a framework for declaring structured, callable entry points into your app - functions the system assistant (Gemini on Android) can discover and invoke on the user's behalf. Send this message. Create this note. Add this calendar event. Check this balance. Reorder this item.

The useful mental model for engineers: it's Android's local MCP. The same idea driving tool-calling everywhere in 2026 - a model doesn't guess its way through your UI; it calls a typed function you declared - applied at the OS level. The assistant gets a catalog of what your app can do, with schemas, and orchestrates across apps.

That framing also explains why this is bigger than a compliance checkbox. Google is rebuilding Android interaction around the assistant, and AppFunctions is how apps stay reachable in that world.

What happens if you ignore it

Two consequences, one hard and one strategic:

• The hard one: AEP compliance. If your app sits in one of the six categories, this lands in the same bucket as target-SDK requirements - a condition of good standing, with a date attached.
• The strategic one: invisibility. When a user says "reply to Anna that I'm running late" or "add the standup to my calendar," the assistant routes to apps that expose the matching function. Apps without AppFunctions don't get a vote. Your competitor's app becomes the verb; yours becomes a tile the user has to remember to open.

The second consequence arrives before the deadline does - assistant-driven flows are shipping now, and early catalog presence compounds the same way early App Store or early voice-assistant presence did.

What the work actually looks like

The good news: this is bounded, well-defined engineering, not a rewrite.

1. Function inventory. List the actions in your app a user could reasonably delegate: the create/send/check/update verbs. For most products this is 5-15 functions, not 50.
2. Schema design. Each function gets typed parameters and results. This is API-design work, and quality matters: a well-scoped createNote(title, body, notebook) is usable by the assistant; a vague openScreen(deeplink) is not.
3. Implementation and guardrails. Wire the declared functions to real app logic, with the same auth, validation, and confirmation UX your UI enforces - the assistant is a new caller, not a trusted one. Destructive and financial actions need explicit confirmation policies.
4. Testing against the assistant. Verify the flows end-to-end: discovery, invocation, error states, and what the user sees when a function needs the app to come to the foreground.

For a typical app in the affected categories this is weeks of focused work, not months - if the app's internal architecture has clean action boundaries. If every action is welded to a ViewModel, add refactoring time; the mandate is incidentally a code-quality audit.

Why this belongs in the on-device story

AppFunctions is the action side of the same shift we've covered from the inference side: the phone is becoming an AI runtime, with the OS providing free local models and now a standard way for those models to act inside apps. Notably, the assistant processing that orchestrates your functions benefits from the same on-device execution properties - the interaction can stay local, which matters if your app is in the finance category and your lawyers have opinions about where user intent data travels.

Teams building for the mandate often find the function inventory pays twice: the same typed actions that serve the system assistant are the natural seams for your own AI features - your in-app assistant, automation, shortcuts. Declare once, serve both.

The sensible timeline from here

Working backward from March 1, 2027:

• This quarter: function inventory + schema design. Cheap, mostly product thinking, and it surfaces any architectural blockers while there's time to fix them calmly.
• Next two quarters: implementation and internal testing, shipped incrementally behind the scenes.
• Q4 2026 - Q1 2027: end-to-end assistant testing and rollout, with margin for the platform-side surprises every new framework has.

Starting this quarter turns the mandate into a normal feature cycle. Starting next summer turns it into a scramble competing with everyone else's scramble - including for the attention of the few teams that have done it before.

If your Android app is in one of the six categories and you want the inventory-and-architecture step done by people who live in this stack, that's a conversation we do well - free, and you keep the written function map either way.