Android Vibe 包含 chunk、embedding 與 Top-K，也包含 Android Framework 的結構索引。結構索引保留 method、path、subsystem 與 module 關係。

核心工作是建立可閱讀的實作路徑。系統判斷 code 在架構中的角色，並辨識 framework API、service entry、Binder transaction boundary 與 HAL 實作。這一層結構決定閱讀順序。

Android Vibe 是面向 Android Framework 的 code-indexing 與 retrieval 系統。系統讀取 source tree，並把 method、path、subsystem、module 與結構線索整理成可檢索索引。查詢結果提供優先閱讀的候選節點。

Android Vibe 需要找到 code，並整理合理的實作閱讀路徑。

Android Framework 需要結構索引

Android Framework 的功能路徑可能跨越 Java API、system service、Binder、native service 與 HAL。結構索引提供明確的閱讀起點。

Android Vibe 將大型 source tree 轉成可查詢的結構圖。查詢結果逐步接近實作主線。Retrieve 結果形成一份閱讀順序建議。

以 camera permission enforcement path 為例

以下範例分析 Camera 功能背後的權限檢查路徑。查詢目標如下：

camera permission enforcement path 定位功能的實作路徑

這時可以直接執行：

% npm run android-vibe:retrieve -- --query "camera permission enforcement path" --topK 8

若只從第一輪 retrieve 來看，系統可能回傳像下面這樣的候選節點：

{
  "query": "camera permission enforcement path",
  "query_tokens": ["camera", "permission", "enforcement", "path"],
  "matches": [
    {
      "path": "frameworks/base/core/java/android/hardware/Camera.java",
      "method_name": "setPreviewCallback",
      "score": 0.962915,
      "why_ranked": "lexical:camera | path-boost | exact:0.26"
    },
    {
      "path": "frameworks/base/core/java/android/hardware/Camera.java",
      "method_name": "handleMessage",
      "score": 0.945753,
      "why_ranked": "lexical:camera | path-boost | exact:0.26"
    },
    {
      "path": "hardware/ti/omap4xxx/camera/CameraHal.cpp",
      "method_name": "CameraHal::autoFocus",
      "score": 0.82969,
      "why_ranked": "lexical:camera | path-boost | exact:0.08"
    },
    {
      "path": "frameworks/base/services/camera/libcameraservice/CameraService.cpp",
      "method_name": "CameraService::onTransact",
      "score": 0.822687,
      "why_ranked": "lexical:permission,camera | path-boost | exact:0.08"
    }
  ]
}

前兩筆結果指向 Camera.java。結構判讀需要檢查 transaction boundary。setPreviewCallback() 位於 framework API 界面，handleMessage() 位於 Java 層。Permission enforcement path 需檢查 CameraService::onTransact。

判讀關鍵是權限檢查的實際邊界。Android 的權限檢查通常接近 service 與 Binder transaction 的接點。UI callback 與 Java API 包裝層提供上層流程。

第一輪 retrieve 的結果

第一輪 retrieve 將整棵 source tree 縮小為幾個優先閱讀區域。工程師據此建立 call path。

閱讀順序可從以下三層開始。

  • frameworks/base/services/camera/libcameraservice/CameraService.cpp
    先看 CameraService::onTransact。因為它更接近 Binder transaction boundary，也比較像 permission enforcement 真正會穿過的位置。
  • frameworks/base/core/java/android/hardware/Camera.java
    接著讀 setPreviewCallback 與 handleMessage。這一層呈現 Java API 與底層 service 的 camera 操作連接方式。
  • hardware/ti/omap4xxx/camera/CameraHal.cpp
    HAL 層可列入候選。這個查詢的閱讀順序先從 framework service 開始，再進入下游實作。

Android Vibe 的 retrieve 先排出閱讀順序。大型 codebase 因此具備明確的起點。

結構索引與向量搜尋

向量搜尋會取得與 camera 相關的 method。這些 method 需要放回 Android Framework 結構中判讀。工程師可從功能意圖逐步定位實作路徑。

Android Vibe 建立可工作的 indexing。Indexing 整合 embedding、AST、path、symbol metadata 與 Android-specific structure。Retrieve 結果可用於 tracing、planning 與 AI handoff。

從 retrieve 到工作流

Retrieve 結果可作為 code reading 起點。工程師整理關鍵 method、permission boundary 與相鄰實作，接著建立 handoff bundle。Claude 依據 bundle 進行分析與 patch planning。

Android Vibe 先整理 Android-specific truth。LLM 依據這份內容進行後續推理與修改。

快速整理

  • Android Vibe 是面向 Android Framework 的 code-indexing 與 retrieval 系統。
  • 它先整理閱讀順序與候選實作節點。
  • 像 camera permission enforcement path 這種查詢需要判斷候選節點與 permission enforcement 邊界的距離。
  • 第一輪 retrieve 往往先縮小搜尋範圍，再由工程師依 Android 結構判讀 service、Binder 與 HAL 的閱讀順序。
  • Code indexing 與 retrieval 建立完整上下文。LLM 接著處理 analysis、planning 與 handoff。