診斷資料保留：在重新啟動後儲存檢查結果

診斷資料持續性功能會自動擷取並儲存裝置重新啟動時的檢查資料。這可用於保留可寫入檢查的任何內容。

總覽

  • 開發期間自動收集：在 eng 和 userdebug 建構作業中，系統會自動保留所有 Inspect 資料，即使重新啟動也不會遺失。不需要設定。

  • 正式版 (user) 需要隱私權設定：在正式版裝置上，必須在產品的 previous_boot 管道 (例如 go/previous-boot-pipeline) 中，明確將持續性檢查資料加入允許清單，並接受隱私權審查。

  • 適用於意見回饋和當機報告：系統會自動將保存的檢查資料擷取到意見回饋中，並在生成意見回饋或當機報告時，將資料納入快照封存檔 (如 inspect.previous_boot.json)。

收集使用者建構的欄位

在正式版 (user) 中，為保護使用者隱私權，系統會限制診斷資料外洩。如要在正式版裝置上保留特定「檢查」屬性或樹狀結構，請將選取器新增至產品的 previous_boot 管道，並完成隱私權審查。

Persistence 的隱私權規定與 go/tq-feedback-privacy 在功能上完全相同。

1. 找出「檢查」選取器

找出所需屬性或節點的確切檢查選取器。 您可以使用 ffx inspect，在執行中的裝置或模擬器上檢查元件。

2. 將選取器新增至 previous_boot 管道

在產品存放區的管道目錄中，為元件建立或更新選取器設定：

  1. 在產品的 previous_boot 管道下建立元件目錄：

    //vendor/*/privacy/pipelines/previous_boot/<component_name>/inspect/

  2. 新增 .cfg 檔案 (例如 <component_name>.cfg)，其中包含要保留的確切選取器：

    core/my_component:root/my_node:error_count
core/my_component:root/my_node:last_failure_reason

  3. 更新對應的 BUILD.bazel 或管道清單，加入新設定。

3. 送交隱私權審查

請參閱 go/tq-feedback-privacy。

存取保留的資料

意見回饋報告和快照

如果是在重新啟動後擷取意見回饋報告或當機快照，意見回饋應用程式會自動從 Persistence 擷取先前啟動的檢查資料。產生的快照包含：

  • inspect.previous_boot.json：先前啟動的完整或經過篩選的檢查 JSON 樹狀結構。

技術架構和行為

在幕後，診斷持續性會以排定的事件驅動管道快照服務運作：

┌───────────────────────────┐
│ Archivist                 │
│ ArchiveAccessor           │
│ .previous_boot pipeline   │
└─────────────┬─────────────┘
              │ Snapshot query
              ▼
┌───────────────────────────┐   writes active snapshot
│ Diagnostics Persistence   ├───► /cache/active/active.json
│                           │     /cache/active/metadata.json
│ • Periodic (every 300s)   │
│ • Low battery trigger     │   on reboot: rotate
│ • Wait for update check   ├───► /cache/previous_boot/active.json
└─────────────┬─────────────┘     /cache/previous_boot/metadata.json
              │ Serves via FIDL
              ▼
┌───────────────────────────┐
│ PreviousBootDataProvider  │
│ (e.g. Feedback component) │
└───────────────────────────┘

1. Archivist previous_boot 管道

Persistence 會連線至 fuchsia.diagnostics.ArchiveAccessor.previous_boot。 Archivist 會動態套用為管道設定的許可清單選取器，或在出現 DISABLE_FILTERING.txt 時略過篩選程序 (例如 eng 和 userdebug 建構作業)。

2. 快照觸發條件

持續性記錄會使用下列兩種觸發條件，記錄使用中系統的快照：

  • 週期性間隔：每 $N$ 秒執行一次 (由 fuchsia.diagnostics.persist.PersistencePeriodSeconds 設定，預設為 300 秒)。

  • 電量不足觸發條件：連線至 fuchsia.power.battery.BatteryManager 監控電池狀態。如果電量降至 fuchsia.diagnostics.persist.LowBatteryThresholdPercent (預設為 10%) 以下，系統會立即擷取快照，以保留即將關機前的狀態。

3. 從現用啟動輪替切換至上一個啟動輪替

  • 系統會將有效快照和中繼資料儲存至 /cache/active/active.json 和 /cache/active/metadata.json。

  • 啟動時，Persistence 會以原子方式清除 /cache/previous_boot，並將 /cache/active 移至 /cache/previous_boot。

  • 系統只會保留上一個開機週期的持續性資料。

4. 軟體更新檢查閘道

為防範更新期間持續發生當機迴圈，Persistence 會向 fuchsia.update.Listener 註冊，並保留先前的開機資料，直到完成首次開機後軟體更新檢查為止。在 eng 和 userdebug 建構作業中，可以略過這項檢查 (skip_update_check: true)。

組裝設定

您可以在「diagnostics.persistence」部分下方的產品組裝設定中，自訂持續性參數：

  • persistence_period_seconds (整數，預設值：300)： ArchiveAccessor.previous_boot 上定期快照之間的間隔時間 (以秒為單位)。

  • low_battery_threshold_percent (整數，預設值：10)： 觸發立即主動快照的電量百分比閾值。

  • skip_update_check (布林值，預設值：使用者為 false，userdebug/eng 為 true)： 如果為 true，則不會等待開機後更新檢查，就發布先前的開機資料。一律 false 使用者建構版本。

常見問題

Persistence 是否適用於延遲節點？

可以。由於 Persistence 會透過 ArchiveAccessor 向 Archivist 要求快照，因此 Archivist 會在每個快照的時間點，主動評估與管道有效選取器相符的所有延遲節點。

.persist 設定檔去了哪裡？

舊版 .persist 檔案和依代碼擷取排程已由 Archivist previous_boot 管道取代。元件不再發布個別 .persist 檔案，也不會重新匯出 core/diagnostics/persistence:root/persist 下方即時檢查階層中的保存資料。所有先前的開機檢查作業都會整合為單一快照檔案，直接提供給意見回饋。