fuchsia.feedback

不明

INVALID_ARGS_ERROR

SERVER_ERROR

PERSISTENCE_ERROR

QUOTA_REACHED_ERROR

不明

REPORT_UPLOADED

REPORT_ON_DISK

REPORT_IN_MEMORY

REPORT_NOT_FILED_USER_OPTED_OUT

不明

如果伺服器傳送了用戶端未編譯的新列舉值，用戶端就會取得這個值。

COLD

裝置從冷啟動狀態啟動。

這很可能是因為裝置長時間未通電，或首次使用 Fuchsia 啟動。

BRIEF_POWER_LOSS

裝置因短暫斷電而重新啟動。

在某些硬體上，這可能是因為使用者快速連續拔除並重新連接裝置的電源。

BROWNOUT

裝置電壓低於允許值，但未降至 0，因此重新啟動。

KERNEL_PANIC

SYSTEM_OUT_OF_MEMORY

HARDWARE_WATCHDOG_TIMEOUT

SOFTWARE_WATCHDOG_TIMEOUT

ROOT_JOB_TERMINATION

使用者空間根工作終止，因此裝置重新啟動，這很可能是因為其中一項重要程序異常終止。

USER_HARD_RESET

使用者刻意按住電源鍵，強制重設裝置，因此裝置重新啟動。

USER_REQUEST

裝置使用者啟動重新啟動程序，因此裝置已重新啟動。

請勿用於任何與使用者明確重新啟動動作無直接關聯的程式碼路徑。請改用下方的 DEVELOPER_REQUEST。

USER_REQUEST_DEVICE_STUCK

裝置因當機而由使用者重新啟動。

DEVELOPER_REQUEST

開發人員啟動重新啟動程序，通常是透過殼層指令或類似介面 (包括在自動化測試中)，因此裝置重新啟動。

RETRY_SYSTEM_UPDATE

套用 OTA 失敗，因此裝置重新啟動，我們想重試。

HIGH_TEMPERATURE

系統判定裝置過熱，因此重新啟動。

SESSION_FAILURE

裝置因工作階段問題而重新啟動，或工作階段管理員無法從錯誤中復原。

SYSMGR_FAILURE

系統管理員 (sysmgr) 無法從錯誤中復原，因此裝置重新啟動。

FACTORY_DATA_RESET

裝置已恢復原廠設定並重新啟動。 請參閱 fuchsia.recovery.FactoryReset。

CRITICAL_COMPONENT_FAILURE

sysmgr 管理的重要元件故障，因此裝置重新啟動。

ZBI_SWAP

裝置已重新啟動，套用 Zircon 開機映像檔的切換。

ANDROID_UNEXPECTED_REASON

Starnix 無法辨識 Android 啟動重新啟動的原因。

ANDROID_NO_REASON

Android 啟動關機程序，但 Starnix 不知道原因。

ANDROID_RESCUE_PARTY

Android 呼叫「RescueParty」，因此裝置重新啟動。

ANDROID_CRITICAL_PROCESS_FAILURE

Android 的其中一項重要程序失敗，因此裝置重新啟動。

BATTERY_DRAINED

裝置電池電量耗盡。

SUSPENSION_FAILURE

系統無法在預期時間內暫停或恢復。

CRITICAL_DRIVER_FAILURE

重要驅動程式庫故障，導致裝置重新啟動。

SYSTEM_UPDATE

裝置因 OTA 重新啟動。

NETSTACK_MIGRATION

Netstack 元件正在變更版本。

POWEROFF

重新啟動

REBOOT_TO_RECOVERY

REBOOT_TO_BOOTLOADER

2

鍵/值字串組合的向量。鍵保證不重複。

1

與資料相關聯的頂層命名空間：

• 用於將相關資料分組，並減少命名空間之間的資料鍵衝突。
• 可由多個用戶端共用，例如，同一個元件或多個元件中可能有多個用戶端想要公開相關資料，且這些用戶端都會使用相同的命名空間。
• 在所有意見回饋報告中，系統會將這個前置字串加到該命名空間內傳遞的每個資料鍵前面。舉例來說，如果命名空間是「foo」，則在所有意見回饋報告中，註解「version」會顯示為「foo.version」。
• 必須符合 [a-z-]+，也就是只能使用小寫英文字母和連字號，否則會導致 ZX_ERR_INVALID_ARGS 墓誌銘。
• 不得與平台資料內部使用的保留命名空間 (例如「build」) 相符，否則會導致 ZX_ERR_INVALID_ARGS 墓誌銘。保留的命名空間清單為內部清單，目前可能會有變動。

2

鍵/值字串組合的向量，例如 <"version", "1.2.3.45">。

金鑰：

• 應為不重複的值，因為系統只會考量向量中指定鍵的最新值。
• 必須符合 [a-z-.]+，也就是只能使用小寫英文字母、連字號和半形句號。使用句號建立子命名空間，例如「build.label」和「build.type」，這樣一來，相關註解 (此處與「build」相關) 就會按照字母順序分組。

1

當機程式的名稱，例如程序或元件的名稱。

在內部，程式名稱用於在無法立即上傳報告時保留報告。因此，當做檔案系統路徑使用時，系統會進行清理，例如移除任何 fuchsia-pkg:// 前置字元。如果經過清理的程式名稱為下列任一項，系統會傳回 ZX_ERR_INVALID_ARGS：

• ""
• "。
• ".."

2

特定報表，取決於當機類型。

如需傳送當機程式的其他資訊 (例如小型傾印)，請設定這個欄位。

3

鍵/值字串組合的向量，代表應附加至當機報告的任意資料。

鍵不得重複，因為系統只會考量向量中指定鍵的最新值。

4

鍵/值字串對 VMO 配對的向量，代表應附加至當機報告的任意資料。

鍵不得重複，因為系統只會考量向量中指定鍵的最新值。

如果符合下列任一情況，系統會傳回 ZX_ERR_INVALID_ARGS：

• 鍵為「」
• a 鍵是「.」
• 鍵為「..」
• 鍵包含正斜線「/」
• 鍵包含空格「 」
• 金鑰包含可列印 ASCII 以外的字元
• 意見回饋專用鍵：
  • annotations.json
  • minidump.dmp
  • snapshot_uuid.txt
  • snapshot.zip
  • uploadFileMinidump

5

當機伺服器可使用的文字 ID，用於將與同一事件相關的多個當機報告分組。

與當機簽章不同，共用相同 ID 的當機報告對應到不同的當機，但可以視為屬於同一個事件，例如低層級伺服器當機導致高層級 UI 小工具當機。

6

程式在當機前執行的時間。

7

當機伺服器可用來追蹤相同異常終止情形的文字簽章，例如「核心錯誤」或「記憶體不足」。這個簽章的優先順序高於從其餘資料衍生的任何自動簽章。

與事件 ID 不同，共用相同簽章的當機報告對應到相同的當機，但發生在多個事件中，例如，每當伺服器收到相同要求時，就會發生空值指標例外狀況。

必須符合 [a-z][a-z-]*，也就是只能使用小寫英文字母和連字號，否則會導致 ZX_ERR_INVALID_ARGS 墓誌銘。

8

指出當機報告是否針對執行中程序、元件或系統本身的非典型停止。

以下是會導致嚴重當機報告的事件範例：

• ELF 程序異常終止
• 系統因記憶體不足而重新啟動。
• 系統因重要元件當機而重新啟動。
• 裝置過熱，系統重新啟動。

以下是會產生非致命當機報告的事件示例：

• Dart 程式中未捕捉到的例外狀況，其中包含多個執行環境。執行階段可能會選擇終止該特定執行環境，並為其提交當機報告，而不是整個程式。
• 偵測到嚴重事件 (例如 OOM) 的元件可能很快就會發生，但不保證一定會發生。

這個欄位主要用於將當機情形分為致命、非致命和未知，分別對應到設為 true、設為 false 或未設定的欄位。

9

選用。用於表示這份報告不只代表這個當機例項。舉例來說，如果選擇每 10 個這類當機事件只回報 1 個，則應將這個欄位設為 10。

如未設定這個欄位，則會使用權重 1。明確設定的值為 0 則無效，系統會拒絕。

1

當機伺服器上的產品名稱。

• 第一個字元必須是英數字元。其餘字元必須是可顯示的字元，但不能是空格，因此 ASCII 表中的值為 33 到 127。任何其他字元都會導致 ZX_ERR_INVALID_ARGS 墓誌銘。
• 如果缺少這個必要欄位，會導致 ZX_ERR_INVALID_ARGS 墓誌銘。

2

元件的產品版本 (選用)。

• 第一個字元必須是英數字元。其餘字元必須是可顯示的字元，但不能是空格，因此 ASCII 表中的值為 33 到 127。任何其他字元都會導致 ZX_ERR_INVALID_ARGS 墓誌銘。

如未指定版本，則不會向當機伺服器回報任何版本。

3

元件的選用產品發布管道，例如「canary」、「beta」、「stable」。

如未指定，就不會向當機伺服器回報任何管道。

1

成功類型。

2

如果 |result| 為 FilingSuccess::REPORT_UPLOADED，則為非空值。

1

系統會從平台上的多個位置平行收集註解，每個位置都有逾時限制。

collection_timeout_per_annotation 可讓用戶端控管每個註解集合的時間。用戶端可在特定時間內取得部分註解。

1

快照會匯總從平台平行收集的各種資料 (裝置運作時間、記錄、檢查資料等)。在內部，每項資料收集作業都會在逾時時間內完成。

collection_timeout_per_data 可讓用戶端控制每次資料收集的時間。用戶端可藉此在特定時間內取得部分但有效的快照。

請注意，這項設定不會控管快照生成作業可能耗費的總時間，因為用戶端可以透過在呼叫 GetSnapshot() 時設定逾時時間，來控管總時間，因此總時間在結構上會高於 collection_timeout_per_data。

2

如果設定，系統會透過這個管道將快照封存檔傳送為 |fuchsia.io.File|，而不是在 |Snapshot| 回應的 |archive| 欄位中設定。如果用戶端位於主機上，且不支援 VMO，這個方法通常很實用。

1

上次重新啟動是否正常，也就是裝置並非因錯誤而重新啟動，而是以受控方式重新啟動。

用戶端可透過這個欄位，瞭解上次重新啟動是否正常，而不必剖析選用的 |reason| 欄位。如果未設定 |reason| (例如系統只知道重新啟動正常，但不知道其他資訊)，或 API 演進到支援新的 RebootReason 值，但用戶端尚未更新，這個方法就很有用。

如果提供 |reason|，這個欄位一律會有值。不過，|reason| 不一定會提供這個欄位的值。

2

裝置上次重新啟動的原因。

3

裝置重新啟動前的正常運作時間。這是自開機後經過的時間，包括在暫停至閒置狀態的時間。

4

上次重新啟動是否為預定，即裝置是否按照系統套用的排程重新啟動。

用戶端可透過這個欄位，瞭解上次重新啟動是否為預定作業，不必剖析 |reason| 欄位。

計畫性重新啟動作業本質上是正常關機。

5

裝置重新啟動前的執行時間。這是指自開機以來經過的時間，不包括在暫停至閒置狀態中花費的時間。

6

裝置上次關機的方式。

1

Minidump 格式的核心 dump。

2

當機程序的名稱。

3

當機程序的核心物件 ID。

4

當機執行緒的名稱。

5

當機執行緒的核心物件 ID。

1

例外狀況類型，例如「FileSystemException」。

2

例外狀況訊息，例如「無法開啟檔案」。

3

例外狀況堆疊追蹤的文字表示法。

1

<檔案名稱, ZIP 封存檔> 配對。

ZIP 封存檔包含多個檔案，對應從平台收集的各種資料。通常會有一個檔案包含所有註解 (裝置運作時間、建構版本等)，以及一個檔案包含每個附件 (記錄、檢查資料等)。

如果要求中已設定 |response_channel|，則不會設定。

3

鍵/值字串組合的向量。鍵保證不重複。

雖然 ZIP 封存檔本身就包含註解，但有些用戶端也希望個別取得註解，以便建立索引或擴充註解，因此我們也會個別提供註解。

1

Fuchsia 符號標記格式的回溯文字表示法。

2

當機程序的名稱。

3

當機程序的核心物件 ID。

4

當機執行緒的名稱。

5

當機執行緒的核心物件 ID。

1

2

2

用於原生例外狀況。

3

適用於 Dart 例外狀況。

4

適用於 Fuchsia 符號標記格式的文字堆疊追蹤。

註解鍵的長度上限。

註解值的長度上限。