Android 17 宣告自己是「intelligence system」而非僅僅是 operating system。AppFunctions 把 app 變成 agent 可呼叫的工具。Prompt API 把 Gemini Nano 放到設備端。LiteRT 抽象化了跨晶片的 NPU（Neural Processing Unit，神經網路處理器）加速。這些都是目前 AOSP 平台正在經歷的變化，有實在的 API interface 定義。它們同時引入了現有 Android 測試實踐從未被設計來覆蓋的 regression surface。
一切還在早期階段
跳進去之前我們先講清楚：一切都還很早。AppFunctions 與 Gemini 的整合仍在 private preview with trusted testers。AEP 對 Android MCP 的強制要求被延後到 2027 年 3 月 1 日或 self-service registration 啟動後三個月，取較晚者。Prompt API 是 beta，沒有 SLA 或 deprecation policy，且可能有 backward-incompatible changes。AppFunctions Jetpack library 本身目前是 alpha。
這些都還沒有大規模 shipping 到 production fleet。今天要談的這個問題的是 early adopters，不是主流。
正確的論述不是「每個 Android 團隊今天都需要新基礎設施」。反而正確的論述是：Android 正在加入 agent-callable 和 model-mediated 的行為到平台中，testing surface 在市場完全成形之前就已經可見了。
這個可見性是現在寫這篇的原因。也許 Google 會把 gap 填滿，所以對GMS 團隊來說大部分問題不成立。但對建置在 AOSP-derived 平台的團隊 —那些原生 Google toolchain 觸及不到的地方 — 今天正在被 bake in 的測試假設，等這些 API 穩定時就會是一個需要解決的問題。
Android 不再只是等著被點擊
Android 歷史上大部分時候，測試契約是非常直觀的: 使用者點擊然後系統派發事件，app 處理它，或者網路呼叫發生，狀態改變影響UI 渲染。輸入是確定性的。輸出是可觀測的。regression surface 就是從點擊到渲染之間的狀態機。
AppFunctions 改變了這件事。它把 app 能力暴露成 Android MCP 的可編排 “tools”，AI agents 和 assistants 可以 discover 並 execute AppFunctions，代替使用者執行工作流程，且直接存取 app 的 local state。呼叫鏈不再是點擊驅動的。它變成：
agent 發出 intent -> function discovery -> [EXECUTE_APP_FUNCTIONS 權限檢查](https://developer.android.com/ai/appfunctions) -> model 生成參數 -> local state 存取 -> model-mediated 決策 -> function 執行 -> side effect。這條鏈上好幾個步驟涉及非確定性行為。Agent 決定呼叫哪個 function。Model 生成參數。KDoc（Kotlin 的文件註解格式）中的 function description 影響 discovery。呼叫時的 local state 可能和開發者測試時不同。
被測試的單元正在改變。以前你測的是 app 是否正確處理已知輸入。現在你還需要考慮 agent 是否選對了 function、生成了有效參數、以及 function 的行為在開發者無法控制的 runtime state 下是否適當。
新的 Regression Surface
以下每個維度單獨看都不新鮮。Android 工程師早就習慣 device matrix、runtime state、delivery path 和 memory pressure。新的是：這些維度現在會直接影響 model-mediated behavior，而且很多不再由 app binary 單獨決定。
Binary 不再決定行為
三件以前在 build time 固定的事，現在是 runtime 變數：
Model version。 Google 文件說明不同 device type 的 hardware 差異可能導致 Gemini Nano base model version 不同，進而導致 API 輸出不同。這不是 flaky test 反而是 model 在不同硬體上產生略微不同的輸出，是按設計運作。
Model 選擇。 Prompt API 的 ModelConfig 暴露 releaseStage（STABLE 或 PREVIEW）和 modelPreference（FULL 或 FAST）。同一個 app binary 因設備 enrollment 狀態不同而行使不同的 model 能力——這是不改 code 就能改變行為的 release policy 決策。
Model 可用性。 checkStatus() 針對特定 model configuration 回報 AVAILABLE、DOWNLOADABLE、DOWNLOADING 或 UNAVAILABLE。Connection、binding、preparation 類錯誤全是 runtime failure。Unlocked bootloader 不被支援——常見的開發和 CI 設備配置。
你的 CI pipeline 說功能正常。Field 裡的設備說 AICore 從來沒下載完成。兩邊都沒說謊。
Quota、lifecycle、system health 進入測試計畫
即使 AICore 可用，operational constraints 仍然存在。Google 記錄了頻繁測試時出現 BUSY error。Quota bypass 機制只在 Pixel 設備上可用，並有明確警告：這會影響設備上所有使用 AICore 的 app，可能對 system health 有影響。Model 初始化需要大約一分鐘，下載僅限 Wi-Fi。
在冷啟動、idle 的開發者設備上通過的測試，一旦 inference 取決於 quota、lifecycle 和 system health，就說明不了多少。
Thermal 和 memory pressure 是 production 變數
On-device model inference 消耗可觀的 compute、memory 和 thermal budget。高階手機有更強的 SoC、更大的 memory budget、更好的散熱設計和更新的 runtime stack 是一回事。低成本、無風扇、長時間運行的 embedded device 是另一回事。在 thermal 受限硬體的持續負載下，系統可能 throttle inference、延遲 model loading、或讓 hosting process 在 memory pressure 下被殺掉。
在 memory-constrained Android 設備上 debug 過 LMKD kill 的人都知道：failure 不是「model 回傳了錯誤輸出」。是 app 卡住、process 重啟、畫面短暫消失，或整個設備 responsiveness 下降。
Delivery 和 targeting 把 model 變成 release artifact
Play for On-device AI 引入了最大 1.5GB 壓縮的 AI packs，三種 delivery mode（install-time、fast-follow、on-demand）和按 SoC、device model、RAM、system features 做 device targeting。不同 device cohort 可能收到不同 model variant。要重現回報的問題，現在需要知道哪個 model pack 被 deliver 到那個 device cohort。
所以「app 有通過測試嗎？」已經不夠了。問題變成：哪個 model、怎麼 deliver 的、到哪些設備、在什麼狀態下？
Function description 成為 interface surface
AppFunctions 是 Model Context Protocol 中 tools 的 mobile 等價物。在 MCP 風格的 tool use 中，function 的 description — 通常是它的 KDoc中定義 — 是 agent 用來決定是否及如何呼叫它的依據。一個對傳統測試不可見的 description 變更（畢竟只是註解）可能改變 agent 行為。
以前一個只改 KDoc comment 的 PR 是無腦 approve。在 AppFunctions 的世界裡，同一個 PR 可能改變 agent 選擇哪個 function。
Happy Path 不是空的
Google 為這個轉型建了實在的基礎設施。AppFunctions API 提供結構化方式暴露 app 能力。AppFunctions Testing Agent 提供確定性呼叫和 LLM-based agent testing 來做 local debugging。AICore 管理 on-device model lifecycle。Prompt API 提供 developer-facing surface 給 Gemini Nano。Play for On-device AI 處理 model delivery 和 targeting。LiteRT 的 NPU 抽象提供跨晶片 vendor 的統一介面。
這是非常大量的基礎設施工作。然而，重點不是 Google 沒有因為這些基礎設施而添加測試。重點是 local integration debugging 和 fleet-level release confidence 是不同的問題。
Local Debugging 不是 Release Engineering
這個區別值得明確化：
| 維度 | Local debugging | Release engineering |
|---|---|---|
| 範圍 | 單一設備，已知配置 | 設備群，異質配置 |
| Model version | 已知，通常 pinned | 跨設備和時間變化 |
| AICore 狀態 | AVAILABLE（開發者設定） | 四種狀態皆有可能 |
| Thermal/memory | 受控（桌面、充電中） | 不受控（field conditions） |
| Model delivery | 手動或 fast-follow | Targeting matrix x 網路 x 時機 |
| 故障重現 | 立即（設備在手） | 需要環境重建 |
| 證據 | 開發者觀察 | 能留存的 artifact |
一次成功的呼叫證明了 integration。它不證明 release safety。
AOSP 斷崖
以上所有內容都假設 Google Mobile Services 存在。對於在沒有 GMS 的 AOSP 上建置的團隊 —- Android TV 營運商、車載系統、嵌入式設備、kiosk、工業控制器 —- 情況在結構上不同。
預設基礎設施消失
GMS 提供 Play Services、AICore、Play for On-device AI、AI packs 作為 managed infrastructure。在沒有 GMS 的 AOSP 上，這些全都不存在。Model hosting、delivery、lifecycle management、update mechanism 成為 platform team 的責任。沒有 AICore 來報告 AVAILABLE/UNAVAILABLE。沒有 Play 來 deliver 1.5GB AI packs 並做 device targeting。
問題從「這個 API 能產生好的回應嗎？」變成「這個產品線能否安全地 ship、update、diagnose、roll back 這些行為 — 跨越我們可能無法實體接觸的設備？」
NPU 加速不是一件事
LiteRT 提供統一介面來使用 NPU，不需要你去處理 vendor-specific 的 compiler、runtime 或 library dependency，支援 Google Tensor、Qualcomm、MediaTek、Intel、Samsung，並有自動 fallback 到 CPU/GPU。「統一介面」不等於「統一行為」。不同 NPU 有不同的 quantization 支援、memory 限制、thermal envelope、numerical precision 特性。一個在某 vendor DSP 上跑得合格的 model，在另一個 vendor 的 APU 上可能產生不同輸出，兩者都可能與 CPU fallback 不同。
讓一個 model 在一顆晶片上跑得快是 demo。知道哪個加速路徑在異質 fleet 上是安全的以及 fallback 啟動時會發生什麼那才是真正的工作。
OTA 和 partition 現實
AOSP 支援可在 OTA（over-the-air 無線更新）期間 create、resize、destroy 的 dynamic partitions。當 model artifact 成為 system image 的一部分 —— 在沒有 Play-based delivery mechanism 時就是這樣 —— 它們就成為 OTA 策略的一部分。System partition 中的大型 model artifact 影響 OTA payload size、A/B update slot 需求、rollback 行為。Model 更新要麼跟 OTA cadence 走（慢，耦合到系統 release），要麼需要 platform team 自建獨立 delivery mechanism。
在 cloud deployment 中看起來合理的 model artifact，放進設計用於 system image 和 rollback safety 的 OTA 策略時就可能變得尷尬。
老舊 fleet 不跟隨發表會時程
AppFunctions 需要 Android 16+。嵌入式 Android 設備通常服役五到十年。跑 Android 12 或 14 的 fleet 不會在沒有大型平台升級的情況下採用 AppFunctions，而嵌入式設備的大型平台升級是昂貴、高風險、低頻率的。
「需要 Android 16+」在這些環境中反而恰恰是一堵牆。
Policy、certification、field reproduction
三個 constraint 在 AOSP-derived 平台上疊加：
安全 policy。 Android 的 SELinux（強制存取控制）是 default-deny；所有存取都必須被 policy 明確允許。在 Google-managed path 上，AICore、Play delivery 和相關平台整合替 app developer 吸收了大量權限和 lifecycle 複雜度。到了 AOSP-derived path，model 放在哪、誰能讀、哪個 process 能 map、哪個 domain 有 policy，全都變成 platform team 的系統設計問題。
Certification。 嵌入式 Android 產品通常需要 operator certification（機上盒）、safety certification（車載）、regulatory certification（醫療/工業）。這些流程假設穩定的 system image。頻繁 model 更新與此衝突。快速迭代在 web deployment 聽起來自然；release path 經過 OEM qualification 時就不那麼自然了。
Field reproduction。 當 model-dependent feature 在電視後方或工廠地板上的設備失敗時，報告通常模糊且沒有 log。重現需要重建 model version、runtime state、thermal conditions、memory pressure、以及觸發問題的具體呼叫——這些資訊如果故障時沒有結構化捕獲就會丟失。對這類失敗，local debugging tool 不夠。團隊需要 provenance：當時在跑什麼、從哪裡來、能否在其他地方 replay。
從 Binary Release 到 Behavior Release
以前，Android release artifact 是：APK 或 system image + configuration + feature flags。Release 的問題可以是「build 有通過測試嗎？」
加入 agent-callable 和 model-mediated 行為後，artifact 擴展為：model version、model configuration、prompt templates、function schema、function descriptions、runtime state、device cohort targeting、delivery state、behavior expectations。
需要保全的 artifact 不再只是「app build 通過了測試」。而是「這個 app build，配合這個 function contract、model configuration、runtime state、和 device profile，在已知 constraints 下產出了可接受的行為。」
Confidence 可能長什麼樣
目標不是 deterministic AI。On-device model 會在不同設備上產生不同輸出——這是設計如此。目標是圍繞 nondeterministic behavior 的 reproducible evidence：知道當時跑的是什麼 model、被問了什麼、輸出是否落在可接受範圍內。
至少需要三件事：runtime provenance（哪個 model version 和 configuration 在哪個設備上 active）、replay 能力（對已知 configuration 重新執行捕獲的 scenario）、behavioral diff（偵測輸出在跨 model version 或 device cohort 時是否超出容忍範圍）。其餘的——release gates、rollback 證據、environmental state 捕獲——都從這三者延伸出來。
為什麼這可能還不重要
說了這麼我們還沒說到為什麼現在這個議題可能不重要 - 四個合理的反論：
今天受苦的團隊太少。 AppFunctions 是 alpha。Prompt API 是 beta。Gemini 整合是 private preview。碰到 model-mediated regression 問題的 production 團隊數量很少。
Google 可能解掉 GMS happy path。 隨著 API 穩定，Google 可能把 testing toolchain 延伸到涵蓋 fleet-level concerns——CI 中的 model version pinning、AICore state simulation、test lab 中的 device cohort targeting。這裡描述的 gap 可能在變得尖銳之前就被 first-party tooling 填補。
AOSP fleet 可能完全避開 on-device GenAI。 嵌入式 Android 營運商可能決定 on-device model inference 不值得那個複雜度，繼續用 server-side AI 或乾脆不做 AI 功能。
平台測試市場總是晚熟。 Android UI testing、accessibility testing、performance testing 的工具都是在它們測試的功能推出數年後才出現。這可能遵循同樣的 pattern。
都合理。也許 gap 會一直很小。也許 Google 會填掉。也許嵌入式 fleet 根本不會採用 on-device AI。
但方向已經很清楚：Android app 的行為正在從 deterministic UI flow，走向 agent-callable、model-mediated、runtime-dependent 的 shipped behavior。這會改變 testing 的單位。
對 Google-managed Android，很多問題會被平台吸收。對 AOSP-derived、embedded、fleet-managed Android，真正困難的可能不是讓 model 跑起來，而是證明它在正確的設備、正確的 runtime、正確的 release channel 下產生了可接受的行為。
越遠離 Google-managed Android，「AI feature」就越不像 app feature，越像 systems engineering problem。