Posted by Ben Weiss, Senior Developer Relations Engineer, Android Developer Relations
Welcome back to the blog post series "Build intelligent Android apps" where we take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post, we explored how to leverage Firebase AI Logic to build cloud-hosted and hybrid AI features.
In this article, we'll show you how we designed and integrated these capabilities into our travel planning app, JetPacker, using Android AppFunctions. We'll explore the rationale behind our feature choices, discuss the specialized tooling we used to accelerate development, and dive into the code that makes it all work.
To select which features to provide to the intelligence system, we looked for tasks where a voice or text command is objectively faster than tapping through screens. In this side-by-side screen recording you can see this contrast perfectly: on the left, a user tapping through multiple screens to log an expense; on the right, the same task completed instantly in the background via a privileged agent.
Our first choice was expense tracking. Logging a coffee expense during a trip usually takes quite a few taps—unlocking the phone, opening the app, finding the active trip, navigating to the expenses tab, tapping the add button, taking a picture of the receipt, and checking the result. By providing the addExpense
and getExpenses
features as AppFunctions, the system agent handles the heavy lifting. When the user says, "Add a five-dollar coffee expense to my Paris trip," the agent automatically searches for the correct trip ID in the background and inserts the expense, skipping the manual UI flow entirely.
We also prioritized itinerary management. Finding what activity is next on a busy trip itinerary usually requires scrolling through a dense timeline view. By providing getItinerary
and addItineraryEvent
to the system, the user can simply ask, "What am I doing next in Paris?" and get an immediate answer.
Finally, we focused on hands-free note capturing. Typing out reminders or notes while walking down a busy street is difficult and unsafe. Exposing a voice note capability allows the user to say, "The flight was amazing, I saw a beautiful sunset and managed to sleep well," and the privileged agent automatically transcribes and saves it directly into the travel database using the addVoiceNote AppFunction.
Under the Android MCP model, your app acts as a local MCP server that exposes structured tools, while the Android platform serves as the central tool registry. On the MCP client side, agent apps are registered with the intelligence system after being granted system-privileged permissions to access the registry.
When a user interacts with a registered agent, its LLM determines if the request can be handled by an AppFunction, queries the platform's metadata, and executes the appropriate registered functions in the background. This local MCP client-server design gives you full control: you choose exactly which features are accessible to the agent, keeping the rest of your app's data private.
Service
entry points, refining our KDoc
documentation to ensure the LLM understands parameter boundaries, and setting up automated testing using ADB. Enough with the theory, let's dive into the implementation.
We begin by adding the AppFunctions dependencies. One for the API and one for the Kotlin Symbol Processing compiler.
implementation("androidx.appfunctions:appfunctions:1.0.0-alpha10")
ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha10")
Any custom object exchanged with the agent must be annotated with @AppFunctionSerializable
. In our TripSerializable.kt file, we define our trip data model:
@AppFunctionSerializable(isDescribedByKDoc = true)
data class TripSerializable(
/** The trip's unique identifier. */
val id: String,
/** The trip's title. */
val title: String,
/** The trip's destination location. */
val location: String,
/** The trip's start date in milliseconds. */
val startDate: Long,
/** The trip's end date in milliseconds. */
val endDate: Long,
/** A list of participants. */
val participants: List<String>,
)
Next, the skill wrote the Kotlin functions that perform the database queries and annotate them with @AppFunction
. We can view this in searchTrip:
/**
* Looks for trips based on optional filters like id, title (name), location, and dates.
*
* @param id The unique identifier of the trip.
* @param title The title or name of the trip.
* @param location The destination location.
* @param startDate The minimum start date in milliseconds.
* @param endDate The maximum end date in milliseconds.
* @return A list of trips matching the filters.
*/
@AppFunction(isDescribedByKDoc = true)
suspend fun searchTrip(
id: String? = null,
title: String? = null,
location: String? = null,
startDate: Long? = null,
endDate: Long? = null
): List<TripSerializable> {
return withContext(Dispatchers.IO) {
// implementation
}
Since AppFunctions run on the UI thread by default, we use withContext(Dispatchers.IO)
to switch to a background dispatcher. Additionally, we refine our KDoc to use clear, imperative verbs and specify parameter constraints. This documentation compiles directly into the tool's schema, which the privileged agent uses to resolve parameters and handle runtime errors.
To register these features with the intelligence system, we create an abstract base class that extends AppFunctionService
. We annotate it with @AppFunctionServiceEntryPoint
:
@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
serviceName = "JetPackerAppFunctionService",
appFunctionXmlFileName = "jetpacker_app_function_service"
)
abstract class BaseJetPackerAppFunctionService : AppFunctionService() {
@Inject internal lateinit var tripDao: TripDao
// DAOs and database references are injected here...
}
During compilation, KSP generates the final concrete service subclass, JetPackerAppFunctionService
, as declared with the serviceName
parameter. We also register app_metadata.xml
in the app's manifest. This file provides global operational rules for JetPacker's declared AppFunctions.
Once implemented, you should verify that your AppFunctions are registered and working correctly.
Running devices or emulators with Android 17 or newer, you can use ADB commands from your terminal to list and invoke your functions. Running adb shell cmd app_function list-app-functions
displays all registered functions for your package. You can then execute a specific function and test its database integration by running adb shell cmd app_function execute-app-function
while passing a raw JSON parameters string.
Instead of these ADB commands, you can also use the AppFunctions Testing Agent to inspect your configuration, list and execute AppFunctions, and even see how your AppFunctions behave in a real conversational flow.
When thinking about app features that can be contributed to the intelligence system using AppFunctions requires a slight shift in how we think about code and documentation. AppFunctions enable you to use this new interaction model for apps, which allows using an agent to access app features..
First, the AppFunctions development skill is an essential lifecycle tool, helping you discover features, implement and refine AppFunctions for your apps. Second, KDoc comments are a compiled API asset; clear parameter descriptions directly impact the execution accuracy of the system agent. Finally, Android MCP provides local-first execution allowing apps to safely collaborate with AI agents.
Contributing app features through AppFunctions makes your application ready for the intelligence system. Let us know how you are adapting your apps for the agentic era!
Check out the other parts of this blog post series:** Part 1:** Introduction of the app and a high-level overview.
Interested in more on Android Development? Follow Android Developers on YouTube or LinkedIn!
All code snippets in this blog post follow the following copyright notice:
Copyright 2026 Google LLC.
SPDX-License-Identifier: Apache-2.0