DEV Community

Cover image for The Sleeper Announcement from Google I/O 2026 That Will Change How We Think About Apps
Vrushali
Vrushali

Posted on

The Sleeper Announcement from Google I/O 2026 That Will Change How We Think About Apps

#devchallenge #googleiochallenge #android #kotlin

Google I/O Writing Challenge Submission

This is a submission for the Google I/O Writing Challenge

Everyone walked away from Google I/O 2026 talking about Compose First, Gemini integrations, and Android 17's adaptive layout push. Fair — those are big. But the announcement I haven't been able to stop thinking about is one that barely got a headline: the AppFunctions API.

I've been building Android apps for 10 years. I've seen APIs come and go. This one feels different — not because of what it does today, but because of what it signals about what apps are becoming.

What AppFunctions Actually Is

At its core, AppFunctions lets your app expose discrete, named actions directly to AI assistants. Think:

  • "Create expense report"
  • "Book appointment"
  • "Send daily update"

Instead of a user launching your app, navigating to a screen, tapping through a flow — an agent like Gemini can invoke these actions directly, on the user's behalf, without the app ever coming to the foreground.

Here's a rough idea of how registering an AppFunction looks:

@AppFunction
suspend fun createExpenseReport(
    context: AppFunctionContext,
    params: CreateExpenseParams
): ExpenseResult {
    // your business logic here
    return ExpenseResult(id = repo.create(params))
}
Enter fullscreen mode Exit fullscreen mode

You define the function. You define the parameters. The AI figures out when and how to call it.

How to Integrate AppFunctions: A Step-by-Step Example

Let's make this concrete. Here's the full integration from zero to Gemini-callable.

Step 1 — Add the dependency 

// build.gradle.kts (module)
dependencies {
    implementation("androidx.appfunctions:appfunctions:1.0.0-alpha01")
    ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha01")
}
Enter fullscreen mode Exit fullscreen mode

Step 2 — Define your input/output types

AppFunctions uses typed Kotlin data classes. Keep them serializable — the AI agent needs to construct them from natural language.

@Serializable
data class CreateExpenseParams(
    val title: String,
    val amount: Double,
    val category: String? = null  // nullable — agent may not always provide this
)

@Serializable
data class ExpenseResult(
    val id: String,
    val success: Boolean,
    val message: String
)
Enter fullscreen mode Exit fullscreen mode

Step 3 — Annotate your function

Use @AppFunction on a suspend function. The annotation processor generates the registration schema at compile time — no boilerplate XML.

class ExpenseAppFunctions(
    private val repo: ExpenseRepository
) {

    @AppFunction
    suspend fun createExpenseReport(
        context: AppFunctionContext,
        params: CreateExpenseParams
    ): ExpenseResult {
        val id = repo.create(params)
        return ExpenseResult(
            id = id,
            success = true,
            message = "Expense created: ${params.title}"
        )
    }
}
Enter fullscreen mode Exit fullscreen mode

Step 4 — Make it agent-safe (the step everyone skips)

Agents may retry on network failure. Without idempotency, one user voice command could create duplicate records.

@AppFunction
suspend fun createExpenseReport(
    context: AppFunctionContext,
    params: CreateExpenseParams
): ExpenseResult {

    // Idempotency: return existing record if already created
    val existing = repo.findByTitle(params.title)
    if (existing != null) {
        return ExpenseResult(
            id = existing.id,
            success = true,
            message = "Already exists"
        )
    }
    return ExpenseResult(id = repo.create(params), success = true, message = "Created")
}
Enter fullscreen mode Exit fullscreen mode

Note: Use AppFunctionContext.callerPackageName to scope idempotency keys per agent if you want finer control.

Step 5 — Register in AndroidManifest

Without this, Gemini can't discover your functions at runtime.

<!-- AndroidManifest.xml -->
<service
    android:name=".ExpenseAppFunctions"
    android:exported="true"
    android:permission="android.permission.BIND_APP_FUNCTION_SERVICE">

    <intent-filter>
        <action android:name="androidx.appfunctions.AppFunctionService"/>
    </intent-filter>

</service>
Enter fullscreen mode Exit fullscreen mode

Step 6 — What Gemini does with it

Once registered, a user saying "Add a £45 taxi to expenses" triggers this behind the scenes — no UI, no navigation, no tap:

// Gemini constructs and executes this on-device
val result = appFunctionManager.executeAppFunction(
    targetPackage = "com.yourapp",
    functionId = "createExpenseReport",
    params = CreateExpenseParams(
        title = "Taxi",
        amount = 45.0,
        category = "Transport"
    )
)
// result.message → "Expense created: Taxi"
Enter fullscreen mode Exit fullscreen mode

That's the full loop. Six steps from dependency to agent-callable action — and most of the real work is in steps 3 and 4, not 1 and

Why This Is Bigger Than It Sounds

Let me be direct about the mental shift this requires.

For the last decade, Android apps have been passive tools. A user opens them, interacts with them, closes them. The app waits. The user comes back. That's the model.

AppFunctions breaks that model entirely.


Note: Your app is no longer just a UI. It's a set of capabilities that can be invoked by an external intelligence — one that operates on the user's behalf, across multiple apps, without requiring explicit navigation.

That's not an incremental update. That's a different paradigm.

Think about what this means for UX assumptions we've held forever:

  • Onboarding flows designed to guide users? Less relevant if agents bypass them.
  • Navigation architecture? Still matters, but it's no longer the only entry point.
  • State management? Now needs to account for actions triggered outside your UI lifecycle.

The Part Nobody Is Talking About: What This Demands From Developers

Here's where I think most coverage has dropped the ball.

Everyone's framing AppFunctions as a feature to "add" to your app. Sprinkle some annotations, expose a few actions, done. But that framing misses the architectural implications.

Your app logic has to be agent-safe.

That means:

  • Idempotency matters more. An agent might call createExpenseReport twice if a network blip happens. Have you handled that?
  • Error messaging has to be machine-readable. If your function fails, the agent needs structured information to recover or report back — not a toast.
  • Permissions and auth need to be explicit. An agent acting on a user's behalf still needs to respect scope. You can't just assume ambient user authentication.

This is less "add a feature" and more "rethink your service layer."

My Honest Take: Exciting, But We're Not Ready

I want to be real here — the Android developer community, broadly, is not prepared for this shift.

We're still mid-migration to Compose. A lot of teams are still untangling MVVM from spaghetti. And now we're being asked to think about our apps as agent-compatible APIs?


Note: The gap between "Google announced AppFunctions" and "most production apps expose well-designed AppFunctions" is going to be measured in years, not months. And that's okay — but only if we start thinking about the architecture now.

The developers who will be ahead of this curve are the ones who start treating their business logic as a first-class API today — clean use cases, clear input/output contracts, proper error handling. Not because an agent is calling it yet, but because good architecture pays forward.

What I'd Tell My Team Tomorrow

If I were walking into standup tomorrow with one takeaway from I/O 2026, it would be this:

Start auditing your use cases for agent-readiness.

Not to ship AppFunctions next sprint — but to ask: if an AI needed to invoke this action without a human at the keyboard, would our code hold up? Would the error states make sense? Would the auth model work?

That question alone will surface a lot of architectural debt worth addressing regardless of AppFunctions.

A Word on Privacy — Because Someone Has to Say It

I'm excited about AppFunctions. But I'd be doing you a disservice if I didn't flag the privacy surface this opens up.

When an agent can invoke your app without the user explicitly tapping anything, the consent model gets murky. A few things worth thinking hard about:

  • Agents act silently. The user said "add a taxi expense" once — they didn't review what data left their device or which systems were touched. Your function needs to do only exactly what it says it does.
  • Sensitive data needs explicit scoping. If your AppFunction touches finance, health, or messages, treat the output like a public API response. Return the minimum data needed, nothing more.
  • Validate callerPackageName. AppFunctionContext gives you the calling agent's package. For sensitive operations, whitelist trusted callers — don't assume all agents deserve equal trust.
  • Log every invocation. Users should be able to see what their agent did on their behalf. Build that audit trail from day one.

The good news: Android's BIND_APP_FUNCTION_SERVICE permission means only system-blessed agents like Gemini can invoke your functions by default. The platform guardrails are reasonable. But as the agent ecosystem grows, so does the attack surface.


Note: Treat every @AppFunction like a public API endpoint — validate inputs, scope outputs, log calls. The annotation is simple; the responsibility it carries is not.

What you're actually exposing

This one surprises developers: you're not exposing source code, but you are exposing your app's capability surface — and that has its own risks.

What AppFunctions reveals to the outside world:

  • Your function names like createExpenseReport or deleteUserAccount act as a discoverable public schema — anyone with the right tools can enumerate what your app registers
  • Your parameter types reveal your internal data model. The shape of CreateExpenseParams is visible, not just its name
  • Your business logic boundaries — if archiveAllRecords exists as an AppFunction, you've advertised that capability before you've even shipped the UI for it

Real attack scenarios to think about:

  • A probing app enumerates your registered functions to reverse-engineer your data model
  • An admin-level function without an internal auth check gets invoked by an untrusted agent — the manifest permission alone isn't enough
  • Competitors read your function names before a launch and know exactly what's coming

What to do about it:

  • Never register a function that wasn't explicitly designed to be agent-callable — not everything in your repo deserves an @AppFunction
  • Add auth checks inside every function, independent of the manifest permission
  • Use generic names for sensitive operations where the function name itself leaks intent
  • Audit @AppFunction annotations before every release the same way you'd audit a public REST API

Google I/O 2026 had plenty of exciting announcements. Compose First is overdue and welcome. The AI dev tooling is genuinely useful. Android Automotive is a real career path worth exploring.

But AppFunctions is the one that will change what we mean when we say "Android app." It's the sleeper. And five years from now, I think we'll look back at I/O 2026 as the moment the shift began.

How would you handle idempotency in your current service layer if an agent started calling your functions today? Drop your architectural "nightmare" scenarios in the comments — I'd love to hear them.

Relevant session: Developer Keynote — Google I/O 2026

Top comments (1)

Collapse
 
markusbnet profile image
Mark Barnett •

Your idempotency example hit directly because I'm building Money Me (money-me.com), a personal finance app — and createExpenseReport is literally an operation I'd want to expose.

The nightmare scenario for finance: agent calls addExpense(£45, "taxi"), network blips, retries. Now the user has two identical transactions with no idea which is real. In a finance context that's worse than a failed call — it corrodes trust in the data.

Title-based fingerprinting breaks down with real-world finance where duplicate amounts in the same category on the same day are completely legitimate (two taxi rides, two coffee shops). A client-side idempotency key generated before the call, persisted in the agent context, and checked server-side on arrival seems cleaner.

The privacy section resonated too. I took the opposite approach with Money Me — no bank sync, manual entry only — partly for exactly the reason you describe: when data creation is silent and agent-triggered, the consent model gets murky fast. Manual entry is a friction-based trust mechanism. Users know exactly what's in the app because they put it there.

Looking forward to AppFunctions maturing. The architectural implications are real.