DEV Community: Vrushali

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

Vrushali — Sun, 24 May 2026 11:35:25 +0000

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))
}

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")
}

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
)

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}"
        )
    }
}

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")
}

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>

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"

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

map() in Kotlin vs Dart (Beginner Friendly)

Vrushali — Tue, 28 Apr 2026 05:22:29 +0000

Ever wondered what map() actually does? 🤔

Let’s break it down in the simplest way possible 👇

🧠 What is map()?

map() is used to transform a list into another list.

👉 It takes each item

👉 Applies some logic

👉 Returns a new list

🟣 Kotlin Example

val numbers = listOf(1, 2, 3)

val doubled = numbers.map {
    it * 2
}

println(doubled) // [2, 4, 6]

🟣 Dart Example

var numbers = [1, 2, 3];

var doubled = numbers.map((n) => n * 2).toList();

print(doubled); // [2, 4, 6]

From AI Hype to Agentic Reality: What Google Cloud Next ’26 Means for Android Developers

Vrushali — Thu, 23 Apr 2026 14:57:30 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

AI Isn’t a Tool Anymore — It’s Redefining How We Build Software

What Google Cloud Next ’26 revealed about the shift from coding features to designing AI-powered systems

🚀 Hook

We’ve all played with AI tools.

We’ve generated code, built demos, maybe even shipped a feature or two.

But at Google Cloud Next ’26, something felt different.

This wasn’t about using AI.

This was about working alongside AI agents at scale.

And honestly? That changes everything.

🧠 The Big Shift: From Experimentation → Execution

In the opening keynote, Thomas Kurian introduced the idea of the Agentic Enterprise.

The message was clear:

AI is no longer a side feature. It’s becoming the operating layer of modern software systems.

Instead of isolated AI features, Google is pushing toward a world where:

AI agents collaborate across systems
Data continuously feeds context
Infrastructure scales intelligence—not just compute

This is a shift from “cool demos” → real business transformation.

🔑 What Actually Stood Out (And Why It Matters)

🧠 1. Gemini Enterprise Agent Platform = AI “Mission Control”

Google is positioning Gemini as the control layer for managing thousands of agents.

Not just chatbots.

Not just assistants.

We’re talking about:

Agents that monitor systems
Agents that make decisions
Agents that coordinate with other agents

👉 My take:

This feels like moving from writing functions → orchestrating autonomous systems.

As developers, our role shifts from builder to system designer.

📊 2. Agentic Data Cloud = Context Is Everything

The introduction of the Knowledge Catalog is underrated.

It automatically:

Understands structured + unstructured data
Tags and connects information
Feeds “business truth” into AI agents

👉 My take:

We often blame AI for bad outputs—but the real issue is bad context.

This is Google saying: fix the data layer, and AI becomes reliable.

⚡ 3. AI Hypercomputer = Infrastructure Finally Catches Up

Massive clusters. Insane bandwidth. Faster training cycles.

👉 My take:

This removes one of the biggest bottlenecks—time.

Faster iteration = faster innovation.

🔐 4. Built-In Security with Wiz

Security is no longer reactive.

👉 My take:

If agents are making decisions, security can’t be an afterthought.

It has to be embedded into the system itself.

💬 5. Workspace Intelligence = Where Work Actually Happens

Google Chat becoming a central hub.

👉 My take:

The tool adapts to your workflow — not the other way around.

🌍 Real-World Signals (This Is Already Happening)

Companies like Citadel Securities, YouTube TV, and Unilever are already using:

Multilingual AI agents
AI-driven decision systems
Automated workflows

👉 This isn’t future talk. This is production reality.

📱 My Personal Take (As an Android Developer)

As someone building Android apps—especially in the healthcare domain—this keynote felt personal.

Most of my work involves:

Handling real-world data (patients, reports, stock systems)
Building scalable apps for field use
Managing repetitive workflows

And honestly, a lot of this work is repetitive:

Fetch → process → display
Validate → sync → notify

After this keynote, I started thinking:

What if these workflows didn’t need to be manually coded end-to-end?

🏥 In Healthcare

AI agent monitors medicine stock and auto-triggers alerts
Voice assistant helps healthcare workers enter data in local languages
Patient insights generated automatically

✈️ In Travel Apps

AI agent plans trips dynamically (budget, preferences, weather)
Real-time itinerary updates (delays, traffic)
Smart recommendations based on live context

👉 This is where the idea clicked for me.

It’s not about replacing Android developers.

It’s about removing repetitive layers so we can focus on real problems.

Instead of writing every API and UI flow, we start designing systems where:

AI handles decisions
Data provides context
Apps become intelligent interfaces

🛠️ From Idea to Reality: What I’ve Already Built

While watching the keynote, I realized something interesting:

I’m not starting from zero — I’ve already been building parts of this.

In my work, I’ve implemented:

Voice-based interactions inside apps
Real-world workflows in healthcare systems
And an education platform called IlluminiLearn

In IlluminiLearn, I experimented with something simple but powerful:

👉 Generating stories for kids based on topics like photosynthesis and the water cycle

The idea was:

Take complex concepts
Turn them into engaging, easy-to-understand stories
Make learning more interactive for children

It worked—but it was still feature-driven.

Now, with this “agentic” approach, I see how this could evolve:

Instead of generating one-time stories → AI agents could adapt stories based on a child’s understanding
Instead of static learning → systems could personalize content in real-time
Instead of just explaining → AI could interact, ask questions, and guide learning

To explore these ideas further, I experimented with this during a hackathon using Gemini-based agents.

Here’s a quick demo of IlluminiLearn in action:

https://youtu.be/9OmHz5pfN8g

This started as a simple experiment—generating stories for topics like photosynthesis and the water cycle.

But after Google Cloud Next ’26, I can clearly see how this could evolve into a fully agent-driven learning system.

Similarly in healthcare:

Voice input already helps field workers
But AI agents could analyze and act on that data automatically

👉 That’s when it clicked:

What I built were features.

What’s coming next are intelligent, adaptive systems.

And the gap between those two is where developers like us need to evolve.

🚀 So, What Should We Do Next?

Start experimenting with agent-based workflows
Focus on data quality and context pipelines
Think in systems, not screens

💥 Final Thought

AI is no longer a tool you call.

It’s becoming a system you design around.

And honestly?

That’s both exciting...

Are you still experimenting with AI, or already building with agents?

🔥 Kotlin vs Dart Equality — 30 sec breakdown!

Vrushali — Fri, 17 Apr 2026 14:20:07 +0000

🔥 Kotlin vs Dart Equality — 30 sec breakdown!

👨‍💻 Kotlin:
== → checks VALUE
=== → checks MEMORY (same object)

val a = "Hi"
val b = "Hi"

println(a == b)  // true
println(a === b) // 🤔 maybe true (string pool)

🚀 Dart:
Only == exists → VALUE check
For memory → use identical()

String a = "Hi";
String b = "Hi";

print(a == b);           // true
print(identical(a, b));  // true/false

💡 Quick Trick:
Kotlin → == vs ===
Dart → == + identical()

⚡ Save this before your next interview!

Kotlin #Dart #Programming #AndroidDev #FlutterDev

Beginner Coding Series

Vrushali — Mon, 13 Apr 2026 14:39:38 +0000

Started Beginner Coding Series Shorts!

Learn:
👉 Kotlin basics
👉 Dart basics

Perfect for Android & Flutter devs 💻

Beginner Coding Series - YouTube

Learn Kotlin and Dart with quick, beginner-friendly coding shorts 🚀 This playlist covers basic concepts like: Hello World, variables, functions, and more. Pe...

youtube.com

Math in Jetpack Compose Animations

Vrushali — Wed, 03 Dec 2025 06:23:47 +0000

Math in Jetpack Compose Animations — Read the full article →

Jetpack Compose animations look simple on the surface, but there’s a lot of clever math behind easing, interpolation, and frame-smooth transitions. This article explains it beautifully.

What is a Coroutine? 🤔

Vrushali — Tue, 28 Oct 2025 14:29:34 +0000

💡 What is a Coroutine? 🤔

A simple question — yet one that traps many Android developers.

Most of us say:

“It’s used to run background tasks.”

❌ Sounds correct... until the interviewer says,

“That’s wrong.” 😅

So what is a coroutine really?

Find out here 👇

🔗 Kotlin Coroutines Explained: Why “Coroutine = Background Task” is Wrong

Why Kotlin Lets You Write `50_000` Instead of `50000` (Beginner-Friendly)

Vrushali — Fri, 17 Oct 2025 14:13:02 +0000

If you’re new to Kotlin, you might have seen something like this:

val number = 50_000

At first, it might look like a typo. But don’t worry — it’s actually a feature! Kotlin allows underscores in numbers to make large numbers easier to read, just like commas in English numbers.

Think of it this way:

50000 → “fifty thousand”

50_000 → “fifty thousand” (much easier to read)

🔹 Read the full blog on Medium
For a complete beginner-friendly explanation with more examples, check out my Medium article:
https://medium.com/@vrushalidev/why-kotlin-lets-you-write-50-000-instead-of-50000-861f132cc25e

Gradle Isn’t Slow… It’s Leveling Up Your Patience as an Android Dev

Vrushali — Fri, 26 Sep 2025 12:54:55 +0000

While Gradle builds your app, it’s actually building your patience 😌

Hit Run in Android Studio 💻, watch Gradle do its thing ⏳, and instead of getting frustrated, treat it as a mini patience workout 🧘‍♂️. Stretch 🤸‍♀️, breathe 😌, sip coffee ☕, or plan a small refactor 💻. Each progress bar is a reminder: coding isn’t just about the result ⚡—it’s about staying calm 🌿.

Read the full blog here: https://medium.com/@vrushalidev/gradle-isnt-slow-its-leveling-up-your-patience-as-an-android-dev-7bafab236dfa

🐘 May your builds be fast and your Zen strong. 💖😌

Android Studio Canary, Beta, RC & Stable Explained (in Simple Words)

Vrushali — Tue, 23 Sep 2025 06:39:58 +0000

New to Android Studio or confused by its update channels? Check out my simple guide on Canary, Beta, RC & Stable!

🚀 Canary for explorers · 🧪 Beta for early adopters · 🛠️ RC for testers · 🏗️ Stable for builders — pick what fits your workflow!

Read here

DataStore in Android: The Future of Local Key-Value Storage

Vrushali — Thu, 18 Sep 2025 15:14:12 +0000

If you're an Android developer, you might still be using SharedPreferences for storing small data. But Google now recommends Jetpack DataStore as the modern replacement! 🚀

I wrote a full guide on Medium with examples and best practices:

Read it here →

💡 Follow me for more Android tips and tutorials!

Why Every Android Dev Should Master Arrays Before Anything Else

Vrushali — Thu, 18 Sep 2025 14:59:20 +0000

Dive into the fundamentals of arrays and discover how they form the backbone of Android development. Learn about:

Array indexing & memory layout
Traversal, insertion, and deletion
How arrays power data structures like ArrayList, Stack, Queue, HashMap, and Heap

🔗 Read the full article here: Why Every Android Dev Should Master Arrays Before Anything Else

💬 Share your thoughts and experiences with arrays in Android development! Let's learn and grow together. 👩‍💻