近期，大家在 Android 16 的文档里发现了一个名为 「Appfunctions 」 的 API ：「Appfunctions 」是一项允许 App 向系统暴露特定功能的机制，这些功能可以被集成到各种系统特性中。

听起来是不是很熟悉？通过 「Appfunctions 」 App 可以向系统暴露各种各样的功能，并且可以和 Android 的系统服务集成，特别是与应用搜索框架的集成，从而让系统能够发现并索引到可用的 App 功能。

备注：这不就是 Android 上类 MCP 支持么，大胆猜测，这个 API 最大的意义就是为了 Gemini 等 AI App 变得更加强大。

特别是对于 GenAI 类型的 App ，这些助手可以与设备上安装的其他 App 无缝交互，比如：
1.“从我最喜欢的披萨应用订一份披萨” ，AI 就可以识别相关的应用，并利用其暴露的 “order food” 应用功能来启动订餐流程，甚至可以基于用户的偏好或历史订单预先填充信息。
2.“使用我首选的航空公司应用预订下周去伦敦的航班” ，AI 可能会利用应用功能来导航应用界面，选择日期和目的地，甚至根据用户存储的偏好完成预订。

就算不针对 AI 场景，在其他场景上也可以联动 App，例如：

1.当用户在系统搜索中查找一家 KFC 时，搜索结果可能会包含一个由 KFC 餐厅应用提供的“VM50”选项

在之前需要唤起 App 执行然后再返回的操作，现在可以无缝直接联调，Appfunctions 支持异步处理，调用时 App 会收到成功响应、类似 HTTP 的错误代码或取消通知。而实现这一功能的核心在于两个关键组件是：AppFunctionService和 AppFunctionManager：

1.AppFunctionService是一个抽象基类，用户通过创建对应子类来提供具体的应用功能
2.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<ExecuteAppFunctionResponse, AppFunctionException>
    ) {
        val functionIdentifier = request.functionIdentifier
        when (functionIdentifier) {
            "orderFood" -> {
                // 堆代码 duidaima.com
                // 实现订餐逻辑
                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<ExecuteAppFunctionResponse, AppFunctionException> { result ->
                        callback.onResult(result)
                    }
                    onExecuteFunction(
                        request,
                        "", // callingPackage 在这里不直接可用
                        SigningInfo(), // callingPackageSigningInfo 在这里不直接可用
                        CancellationSignal(),
                        safeCallback
                    )
                }
            }
        }
    }
}


fun executeFoodOrder(context: Context) {
    val appFunctionManager = context.getSystemService(AppFunctionManager::class.java)
    // 堆代码 duidaima.com
    // 假设从 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<ExecuteAppFunctionResponse, AppFunctionException> {
        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 权限")
    }
}

总结下来，整个交互流程：
1.App 提供 AppFunctionService并在 AndroidManifest.xml中注册
2.Android 系统检测到新的 AppFunctionService，并使用 App Search 索引其功能元数据
3.服务消费者（例如 AI 助手）使用 App Search 搜索实现了特定 schema 的 App Functions
4.消费者获取目标 App Function 的 functionIdentifier
5.消费者通过 AppFunctionManager构建包含目标包名和 functionIdentifier的 ExecuteAppFunctionRequest
6.AppFunctionManager将请求发送给 Android 系统
7.系统识别出提供服务的应用，并绑定到其 AppFunctionService。
8.系统调用提供者应用中 AppFunctionService的 onExecuteFunction方法。
9.提供者应用执行请求的功能，并通过 OutcomeReceiver回调返回 ExecuteAppFunctionResponse给系统
10.系统将响应结果通过消费者应用在调用 executeAppFunction时提供的 OutcomeReceiver传递回去

最后，可以看到，Appfunctions 在 Android 上提供了类似 MCP 的能力支持，从而让 Android 上的 AI 应用可以拥有更强大服务能力，当然，也需要担心 MCP 是否会成为广告联盟在背后同步用户信息的全新手段，推测来说这个权限应该会审核更加严格吧？
那么，你对 Appfunctions 怎么看？