AppFunctions, revisited

An Android developer updated the Be Nice app to use Jetpack AppFunctions alpha10, which removed the appfunctions-service artifact and requires hosting an @AppFunctionServiceEntryPoint AppFunctionService. The implementation now matches app display names instead of package names, and the developer corrected an earlier article's claim about package name usage.

In Agentic interaction using AppFunctions https://dev.to/tkuenneth/agentic-interaction-using-appfunctions-m8k I showed how Be nice publishes createAppPair for agents, using Jetpack appfunctions 1.0.0-alpha08 . That setup leaned on a library-merged PlatformAppFunctionService , an AppFunctionContext parameter, and aggregate XML named app functions.xml / app functions v2.xml . When I bumped toward what Android Studio was suggesting as of mid July, Sync failed: Could not find androidx.appfunctions:appfunctions-service:1.0.0-alpha10. On 1 July 2026 https://developer.android.com/jetpack/androidx/releases/appfunctions , alpha10 stopped publishing appfunctions-service Maven still lists it through alpha09 . The Add the AppFunctions API https://developer.android.com/ai/appfunctions/add-appfunctions guide now expects you to host an @AppFunctionServiceEntryPoint AppFunctionService . Spoiler: that is the real change. The rest of this post is how that landed in Be nice , plus an important update to the earlier article that is easy to miss if you only chase compile errors. In the earlier post I wrote that agents would pass package names for app1 and app2 . That was wrong for Be nice . The implementation matches display names , case-insensitively, against installed apps. Package names are a convenient engineer habit; they are a poor agent habit when the user said “Clock” and “Contacts”. KDoc and app-level metadata have to say what the code accepts — agents lean on that text harder than on your mental model of the APK. Before alpha10 you annotated a helper class and let the service AAR merge a stock entry point into the manifest. Starting with alpha10: @AppFunction lives in androidx.appfunctions not androidx.appfunctions.service AppFunctionService marked @AppFunctionServiceEntryPoint serviceName and the XML named in appFunctionXmlFileName AppFunctionContext parameter; the service Context appfunctions:aggregateAppFunctions . Grepping for empty app functions.xml / app functions v2.xml is no longer the success signalAlpha09 still shipped the service artifact. Jumping from the first article to today skips that soft landing and hits alpha10. versions appfunctions = "1.0.0-alpha10" libraries androidx-appfunctions = { group = "androidx.appfunctions", name = "appfunctions", version.ref = "appfunctions" } androidx-appfunctions-compiler = { group = "androidx.appfunctions", name = "appfunctions-compiler", version.ref = "appfunctions" } dependencies { implementation libs.androidx.appfunctions ksp libs.androidx.appfunctions.compiler } compileSdk stays at 36 or higher Be nice is on 37 . I still keep each merge Assets task depending on the matching ksp Kotlin task. Alpha10 still emits XML under KSP-generated assets — benice app functions.xml for me — and on my AGP/KSP combo packaging was flaky without that edge. Same class of problem as in the first article; new file name. @RequiresApi Build.VERSION CODES.BAKLAVA @AppFunctionServiceEntryPoint serviceName = "BeNiceAppFunctionService", appFunctionXmlFileName = "benice app functions", abstract class BeNiceFunctions : AppFunctionService { / Launches two installed apps together in split screen an app pair . @param app1 Name of the first app in the pair. @param app2 Name of the second app in the pair. @return A localized message describing success or failure. / @AppFunction isDescribedByKDoc = true suspend fun createAppPair app1: String, app2: String : String = withContext Dispatchers.IO { val success = performPairing applicationContext, app1, app2 if success { getString R.string.pair created success, app1, app2 } else { getString R.string.pair created failure } } } AppFunctionService is API 36 Baklava , so the abstract host carries @RequiresApi . Where the old code used context.context , I use applicationContext / getString on the service. I still use suspend . The docs also say AppFunctions run on the UI thread unless you move work elsewhere. Resolving installed apps and publishing a dynamic shortcut is not UI-thread work; withContext Dispatchers.IO is not optional once the body does real I/O. isDescribedByKDoc = true still folds KDoc into agent metadata. Treat that block as public API surface for a model, not as a comment for the next human on your team. Official snippets often put @AndroidEntryPoint and @Inject on the abstract service. I did not. KSP already generates a subclass BeNiceAppFunctionService . Hilt would want to subclass the same type for injection. Stacking two code generators on one service is a fight I do not need for two collaborators. A small @EntryPoint plus EntryPointAccessors.fromApplication for InstalledAppsManager and ShortcutsRepository keeps the host boring. Point at the generated class and at the XML name you chose: <service android:name=".appfunctions.BeNiceAppFunctionService" android:exported="true" android:permission="android.permission.BIND APP FUNCTION SERVICE" 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="benice app functions.xml" / <intent-filter <action android:name="android.app.appfunctions.AppFunctionService" / </intent-filter </service The v2 property value is appFunctionXmlFileName plus .xml . Wrong name, silent packaging miss; especially if you still grep for app functions v2.xml . Under <application the guide also wants app-level metadata. That is where I put the display-name contract in writing: <property android:name="android.app.appfunctions.app metadata" android:resource="@xml/app metadata" / <AppFunctionAppMetadata xmlns:appfn="http://schemas.android.com/apk/androidx.appfunctions" appfn:description="This app creates app pairs that launch two installed apps together in split screen. Operational Patterns: - Use 'createAppPair' with the display names of two installed apps. Constraints: - Both app names must match installed apps case-insensitive ." appfn:displayDescription="@string/appfunctions display description" / description is for agents; displayDescription is for people. The resolver can return null if the property is absent. I would not ship without it: this is how you stop an agent from inventing package-name parameters your code never accepted. After a debug build, the generated assets directory should show benice app functions.xml , not the old aggregate pair. If empty app functions.xml / app functions v2.xml are still what you find, the aggregate KSP flag is probably still on. unzip -l app/build/outputs/apk/debug/app-debug.apk | grep -E 'benice app functions|app functions' You want benice app functions.xml in the APK. Once that is true, install and check the function on device. After install, the same adb path from the first article still works. On a debug build the package id carries the .debug suffix; release stays de.thomaskuenneth.benice . Grep with the shared prefix either way: adb shell cmd app function list-app-functions | grep -F de.thomaskuenneth.benice You want the stable id de.thomaskuenneth.benice.appfunctions.BeNiceFunctions createAppPair . Do not take the first something something match blindly — the current list dump also contains other fragments, and a wrong id comes back as App function not found . Execute with AppSearch-style --parameters each string as a one-element JSON array . Use display names , not package names: adb shell "cmd app function execute-app-function \ --package de.thomaskuenneth.benice.debug \ --function 'de.thomaskuenneth.benice.appfunctions.BeNiceFunctions createAppPair' \ --parameters '{\"app1\": \"Settings\" ,\"app2\": \"Clock\" }'" That returned the localized success string on my API 37 emulator. The same call with com.foo / com.bar still runs the function, but resolves to the failure string — which is what you want if the names are wrong. Swap --package to de.thomaskuenneth.benice for a release install. Some API 36 images still lack the shell until you pick a revision that includes it I needed 36.1 last time . appfunctions-service and aggregateAppFunctions @AppFunction onto an @AppFunctionServiceEntryPoint AppFunctionService ; drop AppFunctionContext app metadata in the manifest adb on a capable image suspend ; put blocking work on a background dispatcherIf you are already on alpha09, Android Studio documents a migration skill for the hop. From alpha08 you touch the same surfaces, and you also leave behind anything that assumed the service AAR and aggregate assets. The first article is still useful for motivation, R8 notes, and the habit of unzipping the APK. Its dependency list, AppFunctionContext signature, aggregate greps, and the package-name claim for Be nice are not. Day to day I treat the Add the AppFunctions API https://developer.android.com/ai/appfunctions/add-appfunctions guide and the alpha10 release notes https://developer.android.com/jetpack/androidx/releases/appfunctions as source of truth — and I re-read them on every bump. The gap between alpha08 and alpha10 is the kind of gap alphas are for: the library stopped hosting your functions, so your app has to. 1.0.0-alpha10 AppFunctionApiSnippets.kt