自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
檢查系統狀態
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
系統狀態檢查器 (SSC) 是在套件層級設定，並在各個模組之間執行。這些檢查項目會執行檢查，判斷模組是否已變更，且未還原某些指定狀態，例如變更系統屬性值。
SSC 主要用於確保模組編寫者不會忘記在測試後清理；但如果他們忘記，請提供追蹤記錄，以便解決問題。
次要用途則是盡可能還原原始狀態，例如在 Keyguard 處於開啟狀態時將其關閉。
系統狀態檢查器 XML 定義
<system_checker class="com.android.tradefed.suite.checker.KeyguardStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.LeakedThreadStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.SystemServerStatusChecker" />
在 Tradefed 設定 XML 的 system_checker 標記下方定義 SSC。
實作
每個 SSC 都必須實作 ISystemStatusChecker 介面，該介面提供兩個主要方法 preExecutionCheck 和 postExecutionCheck，分別在每個模組執行前後執行。
檢查器可以只實作這兩者之一，如果需要檢查模組前的狀態，並將其與模組後的狀態進行比較，則可以實作這兩者。
Tradefed 中包含多個實作範例。建議每個實作項目都專注於單一檢查，以提高重複使用性。舉例來說，SystemServerStatusCheck 會檢查在執行測試套件期間，裝置上是否重新啟動 system_server 程序。在 postExecutionCheck 中，它會呼叫 deviceSoftRestarted，該函式在 NativeDevice 中定義，用於檢查 system_server 程序是否已重新啟動。
每個作業都會傳回 StatusCheckerResult，讓測試套件決定是否應擷取其他資訊 (例如錯誤報告)。
這些定義在 CTS 中位於何處？
CTS 系統狀態檢查器會在 /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml 中定義。
如何找出檢查器失敗情形
根據預設，系統檢查器失敗情況只會顯示在記錄中，並以錯誤報告形式記錄，且該呼叫的名稱會採用 bugreport-checker-post-module-<module name>.zip 格式。
這可讓您瞭解錯誤報告是在哪個模組之後產生。
您可以將 --report-system-checkers 選項設為 true，讓系統檢查器回報本身為測試失敗。這會導致測試執行作業顯示為失敗，失敗原因為狀態檢查器的特定檢查。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Check system status\n\nSystem status checkers (SSCs) are defined at the suite-level configuration and\nrun between each module. They perform checks to determine if the module changed\nand didn't restore some given states, for example changing a system property\nvalue.\n\nSSCs are mainly used to ensure that module writers do not forget to clean up\nafter their tests; but if they do, provide a trace of it so it can be addressed.\n\nA secondary use is to also restore the original state when possible, for example\ndismissing the keyguard if it was left open.\n\nSystem status checker XML definition\n------------------------------------\n\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.KeyguardStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.LeakedThreadStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.SystemServerStatusChecker\" /\u003e\n\nSSCs are defined under the `system_checker` tag in the Tradefed configuration\nXML.\n\nImplementation\n--------------\n\nEvery SSC must implement the [`ISystemStatusChecker`\ninterface](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/ISystemStatusChecker.java),\nwhich provides the two main methods `preExecutionCheck` and `postExecutionCheck`\nthat run before and after each module execution.\n\nIt's possible for a checker to implement only one of the two, or to implement\nboth if there's a need to check the state before the module and compare it to\nthe state after the module.\n\nSeveral [example\nimplementations](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker)\nexist in Tradefed. Each implementation is recommended to focus on a single check\nto improve reusability. For example,\n[`SystemServerStatusCheck`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/SystemServerStatusChecker.java)\nchecks if the `system_server` process restarted on the device during the\ntest suite execution. In the `postExecutionCheck`, it calls `deviceSoftRestarted`,\nwhich is defined in\n[`NativeDevice`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/device/NativeDevice.java)\nto check if the `system_server` process restarted.\n\nEach operation returns\n[`StatusCheckerResult`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/StatusCheckerResult.java),\nwhich lets the harness decide if additional information, like a bug report,\nshould be captured.\n\nWhere are they defined in CTS?\n------------------------------\n\nCTS system status checkers are defined in\n[/test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml](https://android.googlesource.com/platform/cts/+/refs/heads/android16-release/tools/cts-tradefed/res/config/cts-system-checkers.xml).\n\nHow to find checker failures\n----------------------------\n\nBy default, system checker failures show only in the logs and as bug reports\ncaptured for the invocation with name following the format\n`bugreport-checker-post-module-\u003cmodule name\u003e.zip`.\n\nThis lets you find out after which module the bug report was generated.\n\nIt's possible to make the system checker report as a test failure itself by\nsetting the `--report-system-checkers` option to `true`. This results in a\ntest run showing as failed with the reason for failure being the status checker\nparticular check."]]
