Android 16 的 Appfunctions API ，应用级 MCP 支持为 AI 场景打通最后一层壁垒
近期，大家在 Android 16 的文档里发现了一个名为 「Appfunctions 」 的 API ：「Appfunctions 」是一项允许 App 向系统暴露特定功能的机制，这些功能可以被集成到各种系统特性中 。
听起来是不是很熟悉？通过 「Appfunctions 」 App 可以向系统暴露各种各样的功能，并且可以和 Android 的系统服务集成，特别是与应用搜索框架的集成，从而让系统能够发现并索引到可用的 App 功能。
这不就是 Android 上类 MCP 支持么，大胆猜测，这个 API 最大的意义就是为了 Gemini 等 AI App 变得更加强大。
特别是对于 GenAI 类型的 App ，这些助手可以与设备上安装的其他 App 无缝交互，比如：
- “从我最喜欢的披萨应用订一份披萨” ，AI 就可以识别相关的应用，并利用其暴露的 “order food” 应用功能来启动订餐流程，甚至可以基于用户的偏好或历史订单预先填充信息。
- “使用我首选的航空公司应用预订下周去伦敦的航班” ，AI 可能会利用应用功能来导航应用界面，选择日期和目的地，甚至根据用户存储的偏好完成预订。
就算不针对 AI 场景，在其他场景上也可以联动 App，例如：
- 当用户在系统搜索中查找一家 KFC 时，搜索结果可能会包含一个由 KFC 餐厅应用提供的“VM50”选项
在之前需要唤起 App 执行然后再返回的操作，现在可以无缝直接联调，Appfunctions 支持异步处理，调用时 App 会收到成功响应、类似 HTTP 的错误代码或取消通知。
而实现这一功能的核心在于两个关键组件是：AppFunctionService 和 AppFunctionManager ：
-
AppFunctionService 是一个抽象基类，用户通过创建对应子类来提供具体的应用功能
-
AppFunctionManager 提供了与应用功能相关的管理功能
当系统需要执行某个应用提供的功能时，会调用 AppFunctionService 中的 onExecuteFunction 方法，开发者需要在这个方法里面，根据 ExecuteAppFunctionRequest 对象包含的功能标识符 (functionIdentifier) 来执行相应的逻辑 。
需要注意的是 onExecuteFunction 方法运行在主线程，因此不能执行耗时的操作，同时为了保护 AppFunctionService 不被任意应用绑定，开发者需要在应用的 AndroidManifest.xml 文件中声明该服务，并包含一个 action 为 android.app.appfunctions.AppFunctionService 的 intent-filter，同时声明权限 android.permission.BIND_APP_FUNCTION_SERVICE 。
而对于 AppFunctionManager ， 核心在于负责管理和调度各个应用暴露的功能，当包发生更改或设备启动时，AppSearchManager 会在设备上为可用函数的元数据编制索引，AppSearch 将索引信息存储为 AppFunctionStaticMetadata 文档，文档包含 functionIdentifier 以及 app 函数实现的架构信息，从而让后续其他 App 可以使用 AppSearch 搜索 API 发现这些函数。
而在需要执行 Appfunctions 时，调用方可以从 AppFunctionStaticMetadata 文档中检索 functionIdentifier，并使用它来构建 ExecuteAppFunctionRequest。
然后通过 executeAppFunction(ExecuteAppFunctionRequest, Executor, CancellationSignal, OutcomeReceiver) 异步执行请求来执行应用函数，并且调用方需要 android.permission.EXECUTE_APP_FUNCTIONS 权限声明。
而对于开发者来说，大多数开发人员最终是通过 AppFunctions SDK 实现和调用 Appfunctions
大致代码可能会如下所示（并非完整真正效果）：
class YourAppFunctionService : AppFunctionService() { override fun onExecuteFunction( request: ExecuteAppFunctionRequest, callingPackage: String, callingPackageSigningInfo: SigningInfo, cancellationSignal: CancellationSignal, callback: OutcomeReceiver ) { val functionIdentifier = request.functionIdentifier when (functionIdentifier) { "orderFood" -> { // 实现订餐逻辑 val result = ExecuteAppFunctionResponse.Builder(ExecuteAppFunctionResponse.RESULT_OK) .setResultDocument(GenericDocument.Builder("resultNamespace") .setProperty("orderId", "12345") .build()) .build() callback.onResult(result) } else -> { callback.onError(AppFunctionException(AppFunctionException.ERROR_FUNCTION_NOT_FOUND)) } } } override fun onBind(intent: Intent?): IBinder? { return object : IAppFunctionService.Stub() { override fun executeAppFunction( request: ExecuteAppFunctionRequest?, callback: IExecuteAppFunctionCallback? ) { if (request!= null && callback!= null) { val safeCallback = OutcomeReceiver { result -> callback.onResult(result) } onExecuteFunction( request, "", // callingPackage 在这里不直接可用 SigningInfo(), // callingPackageSigningInfo 在这里不直接可用 CancellationSignal(), safeCallback ) } } } } } fun executeFoodOrder(context: Context) { val appFunctionManager = context.getSystemService(AppFunctionManager::class.java) // 假设从 App Search 获取到的 com.example.foodapp 的 "orderFood" 功能的标识符是 "orderFood123" val targetPackageName = "com.example.foodapp" val functionIdentifier = "orderFood123" val request = ExecuteAppFunctionRequest.Builder(targetPackageName, functionIdentifier) .build() val executor = Executors.newSingleThreadExecutor() val cancellationSignal = CancellationSignal() val callback = object : OutcomeReceiver { override fun onResult(result: ExecuteAppFunctionResponse) { val resultDocument = result.resultDocument val orderId = resultDocument?.getPropertyString("orderId") Log.d("AppFunctions", "订餐成功，订单 ID：$orderId") } override fun onError(error: AppFunctionException) { Log.e("AppFunctions", "执行功能时发生错误：${error.errorCode}") } } if (ContextCompat.checkSelfPermission(context, Manifest.permission.EXECUTE_APP_FUNCTIONS) == PackageManager.PERMISSION_GRANTED) { appFunctionManager?.executeAppFunction(request, executor, cancellationSignal, callback) } else { Log.w("AppFunctions", "未授予 EXECUTE_APP_FUNCTIONS 权限") } }总结下来，整个交互流程：
-
App 提供 AppFunctionService 并在 AndroidManifest.xml 中注册
-
Android 系统检测到新的 AppFunctionService，并使用 App Search 索引其功能元数据
-
服务消费者（例如 AI 助手）使用 App Search 搜索实现了特定 schema 的 App Functions
-
消费者获取目标 App Function 的 functionIdentifier
-
消费者通过 AppFunctionManager 构建包含目标包名和 functionIdentifier 的 ExecuteAppFunctionRequest
-
AppFunctionManager 将请求发送给 Android 系统
-
系统识别出提供服务的应用，并绑定到其 AppFunctionService。
-
系统调用提供者应用中 AppFunctionService 的 onExecuteFunction 方法。
-
提供者应用执行请求的功能，并通过 OutcomeReceiver 回调返回 ExecuteAppFunctionResponse 给系统
-
系统将响应结果通过消费者应用在调用 executeAppFunction 时提供的 OutcomeReceiver 传递回去
最后，可以看到，Appfunctions 在 Android 上提供了类似 MCP 的能力支持，从而让 Android 上的 AI 应用可以拥有更强大服务能力，当然，也需要担心 MCP 是否会成为广告联盟在背后同步用户信息的全新手段，推测来说这个权限应该会审核更加严格吧？
那么，你对 Appfunctions 怎么看？
参考资料
- https://developer.android.com/reference/android/app/appfunctions/AppFunctionManager
-
-
- 当用户在系统搜索中查找一家 KFC 时，搜索结果可能会包含一个由 KFC 餐厅应用提供的“VM50”选项
