2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
システム ステータスを確認する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
システム ステータス チェッカー(SSC)は、スイートレベルの設定で定義され、各モジュール間で実行されます。システム プロパティ値の変更など、モジュールが変更されて特定の状態が復元されなかったかどうかのチェックを行います。
SSC は主に、モジュール作成者がテスト後にクリーンアップを忘れないようにするために使用されます。忘れた場合は、対処できるようにトレースを提供します。
もう 1 つの用途として、可能な場合に元の状態を復元することもできます。たとえば、キーガードが開いたままになっている場合にそのキーガードを閉じます。
システム ステータス チェッカーの 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" />
SSC は、Tradefed 設定 XML の system_checker
タグで定義されます。
実装
SSC はすべて、ISystemStatusChecker
インターフェースを実装する必要があります。これは各モジュールの前後に実行される 2 つの主要なメソッド preExecutionCheck
と postExecutionCheck
を提供します。
チェッカーは、この 2 つのうち 1 つのみを実装することも、両方実装することもできます(モジュールの前の状態をチェックしてモジュールの後の状態と比較する必要がある場合)。
Tradefed には実装例がいくつかあります。各実装は、再利用性を高めるため、1 つのチェックに集中することをおすすめします。たとえば SystemServerStatusCheck
は、テストスイートの実行中にデバイスで system_server
プロセスが再起動されたかどうかをチェックします。postExecutionCheck
では、NativeDevice
で定義されている deviceSoftRestarted
を呼び出して、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-03-26 UTC。
[[["わかりやすい","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-03-26 UTC。"],[],[],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."]]