Generated banner for Appfunctions
Generated logo for Appfunctions

Appfunctions

Android (Google)OfficialCreated by Google LLCDistributed by Android (Google)

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • No issues found

From the author

Analyzes Android apps to find user workflows to expose as AppFunctions, such as creating a note, playing media, or sending a message. AI agents, voice commands, and system shortcuts then run them without opening the app UI. Generates Kotlin code with the androidx.appfunctions library, and refines KDoc and the app description so that agents choose and call functions correctly. Use this skill when discovering, implementing, documenting, testing, or upgrading AppFunctions in an Android app, including @AppFunctionDeclaration, @AppFunctionSerializable, @AppFunctionServiceEntryPoint, AppFunctionService, app_metadata.xml, appfn:instructions, adb shell cmd app_function, and legacy @AppFunction or AppFunctionConfiguration.Provider code. Don't use for building agents that call AppFunctions or for remote MCP servers.
— the description by Google LLC

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The appfunctions skill provides a structured approach to exposing Android app workflows as AppFunctions. It covers the full development lifecycle, including feature discovery, Kotlin implementation using the androidx.appfunctions library, KDoc optimization for AI agents, and local testing via ADB. It ensures developers can build modular, secure, and discoverable tools that allow AI agents, voice commands, and system shortcuts to interact with app functionality without requiring the user to open the app UI.

What it does

  • Analyzes Android codebases to identify workflows suitable for AppFunctions.
  • Generates Kotlin code using the androidx.appfunctions library and KSP.
  • Refines KDoc and app metadata to improve AI agent understanding and tool selection.
  • Provides ADB commands for listing, executing, and managing AppFunction states.
  • Supports migration from legacy AppFunction APIs to the modern Service Entry Point architecture.
  • Enforces security constraints to ensure only safe, non-destructive tasks are exposed.

When to use it

  • When you need to expose app features to AI agents or system-level voice commands.
  • When implementing or upgrading to the latest androidx.appfunctions library.
  • When you need to optimize existing function descriptions for better LLM or MCP compatibility.
  • When testing or debugging AppFunction registration and execution on a local device or emulator.
  • When migrating legacy AppFunction implementations to the current service entry point pattern.

Advantages

  • Enables seamless, UI-less interaction between AI agents and Android applications.
  • Standardizes the implementation process through clear, step-by-step development workflows.
  • Improves discoverability and reliability of app tools for AI models.
  • Provides robust testing capabilities via direct ADB command integration.
  • Ensures backward compatibility through the use of Jetpack libraries.

Usage examples

“Analyze my app to find features that should be exposed as AppFunctions.”
The agent will perform a feature discovery analysis, identifying key user workflows and recommending which should be implemented as AppFunctions.
“How do I implement a 'send message' AppFunction in my Kotlin project?”
The agent will guide you through generating the necessary Kotlin code, configuring the service entry point, and adding the required annotations.
“Optimize my AppFunction KDocs so an AI agent knows how to use them.”
The agent will review your existing KDoc and app metadata, providing refinements to ensure clear, intent-based descriptions for AI models.
“List all registered AppFunctions on my device for package com.example.app.”
The agent will provide the specific ADB command to query and display the registered functions for your application.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/android/appfunctions/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip appfunctions.zip -d .agents/skills

Documentation by Google LLC

Analyzes Android apps to identify key user workflows to expose as AppFunctions, such as creating a note, playing media, or sending a message, for AI agents, voice commands, and system shortcuts to run without opening the app UI.

Generates Kotlin code to expose these workflows to the Android system, allowing agents to discover and execute them on-device.

Also refines KDoc documentation and the app description so AI agents correctly understand and use the provided functionality.

Prerequisites

The app must targetSdk 36 or newer and use compileSdk 37 or newer as AppFunctions, part of the Android platform API, are available from Android 16 onwards. Always use the Jetpack library because it handles backward compatibility. Use androidx.appfunctions:appfunctions and the KSP compiler androidx.appfunctions:appfunctions-compiler, version 1.0.0-beta01 or later.

Workflows

This skill enables the caller to discover features that will be provided to system agents, implement these with AppFunctions, improve function description for agents, and use ADB commands for local evaluation and testing.

The full AppFunction development flow consists of these four steps:

  • Step 1: Discovery: Analyze Android codebases to identify and recommend potential AppFunctions. Use this step when a user asks to "discover AppFunctions," "find features for AI," or "analyze my app for agentic tools."

  • Step 2: Implementation and configuration: Generate Kotlin implementations of AppFunctions, manage system-wide configuration, and configure build dependencies. Use this step when a user asks to "implement AppFunctions," "set up the AppFunctions framework," or "configure Hilt for AppFunctions."

  • Step 3: KDoc refinement: Optimize AppFunction KDoc and the app description for AI agents and Model Context Protocol. If a user asks to "write KDoc", "optimize for MCP", or "refactor tool descriptions for LLMs", use this step.

  • Step 4: Testing and debugging: Provide commands to interact with AppFunctions using ADB for testing and debugging. If a user wants to "list app functions", "invoke an app function", or "verify app function registration" on a device, use this step.

When the user asks for a subset of the steps, run those steps and any step that the critical constraints require. Then list the skipped steps and ask whether to run them.

If they apply, you must load the following references:

  • Context and terminology: Defines the ubiquitous language, architecture definitions, and design patterns across the AppFunctions skill suite. Load when you need to understand core architecture terminology or check the distinctions between modern and legacy AppFunctions APIs.

  • Migration to service entry point : Migrates apps on AppFunctions 1.0.0-alpha09 or lower to the AppFunctionServiceEntryPoint architecture from 1.0.0-alpha10, and upgrades apps to 1.0.0-beta01. Load it when a user asks to migrate or upgrade existing AppFunctions code. When you find legacy AppFunctionConfiguration.Provider implementations, @AppFunction annotations, or appfn:description attributes, load it and ask the user before you migrate.

Critical constraints

  • Modular consistency: You must refine KDocs immediately after you generate AppFunction implementations.

  • Security: Expose only safe, non-destructive tasks that the app's UI already offers on that form factor. Never give agents wide-ranging access to user data or system resources. Never require or return passwords, financial details, private keys, or other highly sensitive personal information.

  • Descriptions: Describe what each function does, never how an agent must behave. Put call order across functions in the app description, not in function KDoc.

Troubleshooting

Files

references/migrate-to-service-entry-point.md

Follow this systematic procedure to migrate Android applications that use the AppFunctions API in version 1.0.0-alpha09 and lower to the compile-time @AppFunctionServiceEntryPoint architecture introduced in version 1.0.0-alpha10. Then follow the Upgrade to 1.0.0-beta01 section. Apps that already use @AppFunctionServiceEntryPoint only need that section.


Architectural shift overview

In lower versions of the AppFunctions API, for example version 1.0.0-alpha09:

  • Applications require separate dependencies for core functionality, specifically androidx.appfunctions:appfunctions, and service components, specifically androidx.appfunctions:appfunctions-service.

  • The application implements AppFunctionConfiguration.Provider on its Application class.

  • You manually register enclosing class instantiation using AppFunctionConfiguration.Builder().addEnclosingClassFactory(...).

  • You place metadata property tags directly under <application>.

In version 1.0.0-alpha10 featuring @AppFunctionServiceEntryPoint:

  • The core and service dependencies are consolidated into a single runtime artifact, androidx.appfunctions:appfunctions, which eliminates the need for the standalone appfunctions-service library.

  • A dedicated wrapper class extending AppFunctionService is annotated with @AppFunctionServiceEntryPoint and Hilt's @AndroidEntryPoint or an alternative dependency injection framework.

  • The KSP compiler generates a concrete service subclass and an XML metadata schema file in assets/.

  • The OS discovers and routes executions using a consolidated <service> and app_metadata declaration in AndroidManifest.xml.

Required changes from 1.0.0-alpha09 to the entry point API

When focusing solely on the mandatory API changes required by the new @AppFunctionServiceEntryPoint architecture, the migration consists of four strict requirements that you must complete:

  1. Build dependency consolidation : Remove the merged appfunctions-service dependency while retaining core appfunctions and the KSP compiler.

  2. Service wrapper creation : Replace the legacy AppFunctionConfiguration.Provider on the Application class with an abstract class extending AppFunctionService, annotated with @AppFunctionServiceEntryPoint.

  3. Annotation and context decoupling : Move AppFunction annotations to the new wrapper methods as @AppFunctionDeclaration. Drop AppFunctionContext parameters, because AppFunctionService inherits directly from Context.

  4. Manifest registration : Register the KSP-generated concrete service in AndroidManifest.xml with BIND_APP_FUNCTION_SERVICE, the AppFunctionService intent filter, and metadata property tags.


Systematic migration steps

Consolidate AppFunctions build dependencies

Remove the standalone appfunctions-service library from your module build files like build.gradle.kts and version catalog like libs.versions.toml. In version 1.0.0-alpha10, all core service capabilities are consolidated directly within the main appfunctions artifact.

// build.gradle.kts
dependencies {
    implementation(libs.androidx.appfunctions)
-   implementation(libs.androidx.appfunctions.service)
    ksp(libs.androidx.appfunctions.compiler)
}

# libs.versions.toml
[versions]
appfunctions = "1.0.0-beta01"

[libraries]
androidx-appfunctions = { module = "androidx.appfunctions:appfunctions", version.ref = "appfunctions" }
-   androidx-appfunctions-service = { module = "androidx.appfunctions:appfunctions-service", version.ref = "appfunctions" }
androidx-appfunctions-compiler = { module = "androidx.appfunctions:appfunctions-compiler", version.ref = "appfunctions" }

[!NOTE] Note: If another dependency in your project uses snapshot builds like 1.0.0-SNAPSHOT or custom snapshot repositories from https://androidx.dev/snapshots/..., preserve your custom snapshot repository configuration in settings.gradle.kts. Otherwise, standard Google Maven repositories resolve 1.0.0-beta01 directly.


Create a dedicated wrapper service extending AppFunctionService

Instead of annotating standalone business logic classes or implementing manual configuration providers, create an abstract service wrapper across your project, for example BaseAppFunctionService, extending AppFunctionService and annotated with @AppFunctionServiceEntryPoint.

Annotate your service with @AndroidEntryPoint and inject your data repositories or use cases using standard @Inject internal lateinit var:

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "MyAppFunctionService",
    appFunctionXmlFileName = "my_app_function_service", // Do NOT include .xml extension
)
abstract class BaseAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var messageRepository: MessageRepository

    @AppFunction(isDescribedByKDoc = true)
    internal suspend fun send(
        name: String,
        endpointValue: String,
        messageBody: String,
    ): MessageResult {
        return messageRepository.send(name, endpointValue, messageBody)
    }
}

<br />

Framework-agnostic approach using alternative dependency injection or a service locator

While Hilt is recommended, many Android applications implement AppFunctions with alternative dependency injection frameworks like Koin, Anvil, or manual Service Locators. Because AppFunctionService inherits from Android android.app.Service and therefore Context, you are able access your application's DI container directly through applicationContext in property getters or during service lifecycle execution:

@RequiresApi(36)
@AppFunctionServiceEntryPoint(
    serviceName = "ServiceLocatorMyAppFunctionService",
    appFunctionXmlFileName = "service_locator_my_app_function_service",
)
abstract class ServiceLocatorBaseAppFunctionService : AppFunctionService() {
    // Example using a manual Service Locator or Application container
    private val messageRepository by lazy {
        (applicationContext as AppFunctionApplication).appContainer.messageRepository
    }
    // Or with Koin / alternative DI locators:
    // private val messageRepository: MessageRepository by inject()

    @AppFunction(isDescribedByKDoc = true)
    internal suspend fun send(
        name: String,
        endpointValue: String,
        messageBody: String,
    ): MessageResult {
        return messageRepository.send(name, endpointValue, messageBody)
    }
}

<br />

[!IMPORTANT] Important: The appFunctionXmlFileName parameter, for example "my_app_function_service", mustn't include the .xml extension, as the KSP compiler automatically appends .xml. Passing "my_app_function_service.xml" results in the asset being named "my_app_function_service.xml.xml".


Simplify method signatures and decouple context

Remove legacy AppFunctionContext parameters from your core methods. When a method requires an Android Context, for example when constructing a PendingIntent, access this directly from your AppFunctionService wrapper because the wrapper inherently extends android.content.Context.

-   suspend fun makeCall(appFunctionContext: AppFunctionContext, contactName: String?): PendingIntent
+   suspend fun makeCall(contactName: String?): PendingIntent

Remove legacy configuration provider

Update your Application class by removing AppFunctionConfiguration.Provider and its associated builder entry points:

-   abstract class BaseChatApplication : Application(), AppFunctionConfiguration.Provider { ... }
+   abstract class BaseChatApplication : Application()

Avoid redundant abstraction layers

Don't attempt to make an AppFunction class or method OS-agnostic---AppFunctions are inherently part of the Android platform integration through the androidx.appfunctions package. For architectural cleanliness, use existing application functionality, such as existing repositories, use cases, or domain orchestrators, to execute the behavior within the @AppFunctionDeclaration methods rather than creating redundant abstraction layers around the OS service.


Consolidate service and metadata manifest declarations

Register the KSP-generated service declaration and app_metadata property inside your module manifest, for example in src/main/AndroidManifest.xml within the <application> tag:

<service
    android:name="com.example.snippets.ai.MyAppFunctionService"
    android:permission="android.permission.BIND_APP_FUNCTION_SERVICE"
    android:exported="true"
    tools:targetApi="36">
    <property
        android:name="android.app.appfunctions.schema"
        android:value="app_functions_schema.xsd" />
    <property
        android:name="android.app.appfunctions.v2"
        android:value="my_app_function_service.xml" />
    <intent-filter>
        <action android:name="android.app.appfunctions.AppFunctionService" />
    </intent-filter>
</service>
<property
    android:name="android.app.appfunctions.app_metadata"
    android:resource="@xml/app_metadata" />

<br />

Set android:name to the class that KSP generates from serviceName, and the android.app.appfunctions.v2 value to appFunctionXmlFileName plus .xml.


Upgrade to 1.0.0-beta01

Apply these changes to every app that uses @AppFunctionServiceEntryPoint, including apps migrated with the preceding steps:

  1. Annotation rename : Replace each @AppFunction annotation with @AppFunctionDeclaration, and update its import. Match the whole name, so annotations such as @AppFunctionSerializable stay unchanged. Version 1.0.0-alpha13 renamed this annotation.

  2. Explicit KDoc flag : Set isDescribedByKDoc = true on every @AppFunctionDeclaration, @AppFunctionSerializable, and @AppFunctionSignature. Since 1.0.0-beta01, it has no default value.

  3. App description attribute : In app_metadata.xml, rename appfn:description to appfn:instructions.

  4. Imports : Import AppFunctionName from androidx.appfunctions, not from androidx.appfunctions.metadata.

  5. Removed APIs : Remove remaining uses of AppFunctionConfiguration and AppFunctionContext. Version 1.0.0-alpha12 removed them.

  6. Other API changes : If the app uses these APIs, update them:

    • @AppFunctionStringValueConstraint: Replace regular expression patterns with patternMatchers (1.0.0-beta01).

    • AppFunctionResourceContainer and AppFunctionTextResource: Opt in with @OptIn(ExperimentalAppFunctionsApi::class) (1.0.0-beta01).

    • AppFunctionAppMetadata.description: Read instructions instead (1.0.0-beta01).

    • AppFunctionMetadata.isEnabled: Call AppFunctionManager.getAppFunctionStates instead (1.0.0-alpha11).

    • ObserveAppFunctionsEvent: Use AppFunctionsChangeEvent instead (1.0.0-alpha13).


Verification and troubleshooting

  1. Clean rebuild and deploy : bash ./gradlew clean installDebug

  2. Verify AppSearch discovery / indexing : Run the following ADB command to confirm the OS successfully discovered and indexed your functions: bash adb shell cmd app_function list-app-functions --package com.example.chatapp If the output is empty, confirm that android.app.appfunctions.v2 matches the exact asset name generated in assets/.

  3. Verify execution using ADB : bash adb shell "cmd app_function execute-app-function \ --package com.example.chatapp \ --function 'com.example.chatapp.appfunctions.BaseAppFunctionService#send' \ --parameters '{\"name\": \"Alice\", \"endpointValue\": \"1\", \"messageBody\": \"Hello Alice!\"}'"

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Google LLC
Publisher
Android (Google) (Official)
Distributed by
Android (Google)
Source
android/skills · device-ai/appfunctions · commit bf68e2d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.txt)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google LLC or Android (Google).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download appfunctions.zip