Android 官方正式官宣 AI 支援 AppFunctions ，Android 官方 MCP 和系統級 OpenClaw 雛形

Android 官方正式官宣 AI 支持 AppFunctions ，Android 官方 MCP 和系統級 OpenClaw 雛形

去年五月的時候，我們通過《Android 16 的 Appfunctions API ，應用級 MCP 支持為 AI 場景打通最後一層壁壘》聊了 Android 正在規劃 Appfunctions API，為 AI 應用提供系統級的 MCP 支持。

而現在官方正式官宣了 Appfunctions，並展示了在 Galaxy S26 系列上與 Gemini 的三星圖庫集成的功能支持，例如用戶只需要告訴 Gemini “從三星圖庫裡找找我貓的照片”，Gemini 會接收用戶的查詢，智能識別並觸發相應的功能，將三星圖庫中的照片直接顯示在 Gemini，並且支持通過語音或文字完成：

Untitled design

谷歌表示 AppFunctions 目前會先在 Galaxy S26 系列和部分 Pixel 10 設備上推出早期預覽版，用戶只需長按電源鍵，就可將複雜任務直接交給 Gemini，早期會先支持美國和韓國精選的外賣、百貨和網約車等場景：

對於 AppFunctions 支持，官方預計 Android 17 會全面拓展推廣。

那什麼是 AppFunctions 呢？簡單來說就是 ：讓你的 App 能被 AI 當成工具調用。

應用把一部分能力（數據/動作）以“自描述函數”的方式暴露出來，AI agent（例如 Gemini）能發現並執行這些函數，從而完成跨 App 的任務，而這個過程，不需要打開目標 App，類似於一個本地 MCP。

這裡有個有趣的是，它不一定要 App 本身做了支持：

對還沒做 AppFunctions 的應用，Google 在做一套“AI 代理 UI 自動化框架”，由系統/助手去操作 UI 完成多步驟任務，並提供通知 “live view” 讓用戶隨時接管，對敏感操作（如支付）會在完成前提醒。

這個降級操作，等於是 Google 在系統層做了一套自動操作 App 的行為，這就有點「強人所難」的味道了，不過也可以看出 Google 強推 Gemini 的決心。

而對於 AppFunctions 的實際原理，其實就是在系統建立了一套可索引、可執行的本地函數體系：

AppFunctions 在 API 是一個 Jetpack 體系的包支持，開發者可以用注解（@AppFunction 和 @AppFunctionSerializable）標記要暴露的函數和數據結構，讓函數參數/返回值變成可以被 agent 理解為 schema。

之後系統會把可用函數的 metadata 索引到本地 AppSearch，形成 AppFunctionStaticMetadata 文檔，裡面包含：

functionIdentifier（後續執行要用的唯一標識）
函數實現的 schema 信息（讓 agent 知道這函數能做什麼、需要什麼參數）

最後 agent 用 functionIdentifier 發起執行請求，調用方（agent app / assistant）拿到 functionIdentifier 後構造 ExecuteAppFunctionRequest，再通過平台側的 AppFunctionManager.executeAppFunction(...) 執行，結果通過 OutcomeReceiver 回調返回成功/失敗。

對於開發者，主要是通過 AndroidX AppFunctions 庫進行集成：

核心庫：
- androidx.appfunctions:appfunctions：客戶端 API，用於管理和查詢
- androidx.appfunctions:appfunctions-service：伺服器端 API，用於 App 內部暴露功能
- androidx.appfunctions:appfunctions-compiler：基於 KSP 的編譯器，處理注解
關鍵元素：
- @AppFunction 注解：標記在 Kotlin 函數上
- AppFunctionService：一種特殊的 Bound Service，系統通過它與 App 通信
- AppFunctionSerializable：用於定義 AI 可理解的複雜參數類型
權限模型：
- 調用方（如 Gemini）必須持有 EXECUTE_APP_FUNCTIONS 權限
- App 可以通過配置決定哪些函數需要用戶明示授權才能運行

例如下方就是一個筆記應用的 AppFunctions 示例，對外支持創建、編輯和列出筆記的功能：

class NoteFunctions(
  private val noteRepository: NoteRepository
) {
    /**
     * A note.
     *
     * @param id The note's ID.
     * @param title The note's title.
     * @param content The note's content.
     */
    @AppFunctionSerializable(isDescribedByKDoc = true)
    data class Note(val id: Int, val title: String, val content: String)

    /**
     * Lists all available notes.
     *
     * @param appFunctionContext The context in which the AppFunction is executed.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun listNotes(appFunctionContext: AppFunctionContext): List<Note>? {
        return if (noteRepository.appNotes.isEmpty()) null else viewModel.appNotes
    }

    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The context in which the AppFunction is executed.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
      appFunctionContext: AppFunctionContext,
      title: String,
      content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }

    /**
     * Edits a single note.
     *
     * @param appFunctionContext The context in which the AppFunction is executed.
     * @param noteId The target note's ID.
     * @param title The new title if it should be updated.
     * @param content The new content if it should be updated.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun editNote(
      appFunctionContext: AppFunctionContext,
      noteId: String,
      title: String?,
      content: String,
    ): Note? {
        return noteRepository.updateNote(noteId, title, content)
    }
}

一般情況下，應用不需要驗證是否支持 AppFunction，因為 Jetpack 會自動處理這個問題，AppFunctionManager 會幫你判斷功能是否可用。

最後，可以看到這更多屬於一個協議，比起粗暴打開 App 進行模擬操作，這種不需要喚起 App 的 MCP 操作顯得更加規範，最主要 App 本身也可以選擇性公開支持，用戶也可以直接在一個界面下完成所有任務，這才是符合手機 Agent 的一個理想形態。