谷歌I/O 2026之眠者宣告，将易吾辈思应用之观

众人皆言I/O二十六之会，论及"先构式"（Compose First）、双子座（Gemini）之整合，及安卓十七之自适应布局。诚然——此皆大事。然吾思之不能已者，乃一未得见报之公告：即应用函数（AppFunctions）API。

吾筑安卓之应用者，十载有余。见诸API之兴衰。此番者，似异于常——非因其今所为之事，乃因其所昭示者，关乎应用将趋成之象.

应用功能之实然

其本，应用功能使汝之应用，直呈离散、有称之行于AI之助。思之：

"Create expense report"
"Book appointment"
"Send daily update"

非由用户启而用汝之应用，行至一屏，点而流过——似玄英之属，可代用户直唤此行，而应用永不出于前景。

此乃注册一AppFunction之粗略形貌：

@AppFunction
suspend fun createExpenseReport(
    context: AppFunctionContext,
    params: CreateExpenseParams
): ExpenseResult {
    // your business logic here
    return ExpenseResult(id = repo.create(params))
}

汝定其法。汝定其数。机心自辨其时与其术而用之。

如何融汇AppFunctions：逐步示范

吾辈当使其具体。此乃自零至可调用 Gemini 之全然整合也。

第一步—增依赖

// build.gradle.kts (module)
dependencies {
    implementation("androidx.appfunctions:appfunctions:1.0.0-alpha01")
    ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha01")
}

步骤二——明定输入输出之类型

AppFunctions 乃用 Kotlin 数据之类型。须使可序列化——人工智能之代理需自自然语言构之。

@Serializable
data class CreateExpenseParams(
    val title: String,
    val amount: Double,
    val category: String? = null  // nullable — agent may not always provide this
)

@Serializable
data class ExpenseResult(
    val id: String,
    val success: Boolean,
    val message: String
)

步骤三——注解尔之函数

用@AppFunction 乃悬于函数。注解处理器于编译时生成注册之范式，无冗余之XML。

class ExpenseAppFunctions(
    private val repo: ExpenseRepository
) {

    @AppFunction
    suspend fun createExpenseReport(
        context: AppFunctionContext,
        params: CreateExpenseParams
    ): ExpenseResult {
        val id = repo.create(params)
        return ExpenseResult(
            id = id,
            success = true,
            message = "Expense created: ${params.title}"
        )
    }
}

第四步——令其适于代理（此步众皆略过）

代理或于网络故障时重试。无幂等性，一用户语音指令或生重复之记录。

@AppFunction
suspend fun createExpenseReport(
    context: AppFunctionContext,
    params: CreateExpenseParams
): ExpenseResult {

    // Idempotency: return existing record if already created
    val existing = repo.findByTitle(params.title)
    if (existing != null) {
        return ExpenseResult(
            id = existing.id,
            success = true,
            message = "Already exists"
        )
    }
    return ExpenseResult(id = repo.create(params), success = true, message = "Created")
}

注：若欲精控，可藉AppFunctionContext.callerPackageName以限定各代理之幂等性键。

第五步 — 注册于AndroidManifest

无此，Gemini将无从于运行时发现尔之函数。

<!-- AndroidManifest.xml -->
<service
    android:name=".ExpenseAppFunctions"
    android:exported="true"
    android:permission="android.permission.BIND_APP_FUNCTION_SERVICE">

    <intent-filter>
        <action android:name="androidx.appfunctions.AppFunctionService"/>
    </intent-filter>

</service>

第六步——双子座如何处理之

既注册矣，用户言曰增四十五镑之车费于报销暗处触动之，无界面，无导航，无轻点：

// Gemini constructs and executes this on-device
val result = appFunctionManager.executeAppFunction(
    targetPackage = "com.yourapp",
    functionId = "createExpenseReport",
    params = CreateExpenseParams(
        title = "Taxi",
        amount = 45.0,
        category = "Transport"
    )
)
// result.message → "Expense created: Taxi"

此乃全环也。自依存至可由代理调用之行，凡六步——然实作多在三四步，非一二步也，亦非

。

吾直言之，此需心神之变也.

近十年来，安卓之应用，乃被动之器也。，用户启之，与之交，复闭之。应用候之。用户复归。此乃模式也。

，AppFunctions，是模式尽破。

，注：，汝之应用，非复仅界面。乃一组可由外智所唤之能，此智代用户而行，越诸应用，无需显性导航。

此非渐进之更，乃别样之范式也。

思此意于吾辈久持之 UX 之想也。

引导用户之流程，若代理可越之，则其设似无谓矣。
导引之构？犹存其意，然今非昔比矣。唯入径。
状态管理乎？今需兼顾触发于UI生命周期之外之行动。

所不言者部分：此于开发者之要求

此乃吾以为多数报道失之所在。

众人视AppFunctions为可"加"于应用之功能。略加注解，暴露数行动作，毕。然此视法失于架构之影响。

汝之应用逻辑，须得安于智能体。

此意谓：

幂等性尤重。若网络偶有波澜，智能体或会重唤createExpenseReport。汝已善处之乎？
错误讯息，须得机器可读。若函数失意，智能体需结构之信息以复或报——非徒然之提示。
权限与认证须明示之。代理人代为行事，仍需恪守界限。不可妄认用户认证之常态。

此非增一功能之事，实乃重思服务之层也。

吾之诚见：甚为欣喜，然未可即行

吾欲直言于此——安卓开发者之社群，大抵未备此变也。

吾辈犹处迁至Compose之中途。众团队犹在理乱麻之MVVM。今复命吾辈视吾辈之应用为可兼容之代理API乎？

注： "Google既布AppFunctions"与"众生产应用皆善呈AppFunctions"之间之距，将计年而度，非计月也。然则可也——惟吾辈始思架构尔。今.

当先者，乃今始视其业务逻辑为上乘之API——明净之用例，清晰之输入输出契约，妥当之错误处理。非因代理方今始调用，实因良构之术，利在长远.

明日吾告诸君之语

若吾明日入 I/O 2026 之会，独得其一义，则此是：

当审己之用例，察其可应于智能之需。

非为次速递 AppFunctions，而当自问：若智能无人力于键前而发此令，吾之码可立乎？其错态可明乎？其认证之模可行乎？

此一问，纵无AppFunctions，亦将显诸多架构之负，亟待清算。

论隐私——终须有人言之

吾甚悦AppFunctions。然若不指此隐私之隙，实乃负尔也。

既使僕役得無需用者顯然觸擊，即引用吾之應用，則許可之模態漸趨混沌。有數事堪深思焉：

僕役默行。 用者曾言「增乘車之費」——彼未審何資料留其器，或何系統被觸。吾之函數，必須僅作其言所云。
機要之資，需明確界定範圍。若汝之AppFunction触及其财、其康、其讯，则视其出如公API之应。返其所需之极，非多。
核验呼叫者包名。 AppFunctionContext授尔呼者之包。凡涉机密，当白名单可信赖之呼者——勿谓所有者皆当等量相信。
每唤必录之。 世人当得见其代行者所为。自始即建其稽核之迹。

善讯：安卓之BIND_APP_FUNCTION_SERVICE权限，唯系统所赐之代理如杰尼米得默认可调用尔之功能。平台之规约尚合宜。然代理之生态日滋，攻击之域亦随之广。

注：每事皆当@AppFunction若公API之端，核验其入，限其出，录其呼。注解虽简，所负之责非轻。

实所现者何

此令开发者惊：非现源码，乃现其应用之能面——此亦有其风险。实现之

《AppFunctions》示于外者何：

尔之函数名若createExpenseReport或deleteUserAccount，乃可寻之公契——具适器者，皆可枚举尔所注册之应用
尔之参数类型，显尔内里之数据模。CreateExpenseParams之形貌可见，非独其名耳
尔之商理界限——若archiveAllRecords 乃一应用功能，尔尝广宣其能，而未及运其界面也

当思实战之攻伐：

一探查之应用，列尔所注册之功能，以逆构尔之数据模
一管治级之功能，无内审之认证，为不信任之代理所唤——仅凭表册之许诺，未足为凭
竞者察尔函数之名于发轫之先，知其将至矣

当如何处之：

勿注册未显式声明之函数匠心所制为可代理 — 汝之仓库中非事事皆宜有@AppFunction
增验认证内里凡诸功能，不拘显许之权
敏感之务，宜用泛名，使函数之名自泄其意
审核@AppFunction之注，于每度发布，如审公然之REST API然

Google I/O 2026之会，盛陈新意。Compose First久违矣，诚可喜也。AI开发者之工具有实用之效。Android Automotive实为可探之途也。

然AppFunctions者，将易吾人所谓"Android之应用"也。此为潜龙，五年之后，吾辈当回首I/O 2026，以为变局之始也。

若今有吏员始呼吾之函数，吾于今之服务层当如何处不增性？诸君且于注中陈其架构之“噩梦”境况，吾甚欲闻之。

相关会话：开发者之旨——谷歌IO二二六年

推薦訂閱源

DEV Community