自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
检查系统状态
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
系统状态检查工具 (SSC) 在套件级配置中定义,并在每个模块之间运行。它们会执行检查以确定模块是否更改了某些状态但未恢复这些状态,例如更改了系统属性值。
SSC 主要用于确保模块编写者不会在测试后忘记清理;但是,如果他们忘记了清理,该工具会提供跟踪记录,以方便解决问题。
其次要用途是尽可能恢复原始状态,例如在忘了关掉锁屏设置时将其关闭。
系统状态检查工具 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
接口,该接口提供了两种主要方法,即 preExecutionCheck
和 postExecutionCheck
,它们分别在每个模块执行之前和之后运行。
检查工具可以仅实现这两种方法之一,如果需要检查模块执行之前的状态并将其与模块执行之后的状态进行比较,也可以同时实现这两种方法。
Tradefed 中存在多个实现示例。建议每个实现专注于一项检查,以提高可重用性。例如,SystemServerStatusCheck
将检查 system_server
进程是否会在测试套件执行期间在设备上重启。在 postExecutionCheck
中,它会调用在 NativeDevice
中定义的 deviceSoftRestarted
以检查 system_server
进程是否已重启。
每项操作都会返回 StatusCheckerResult
,这使自动化测试框架能够决定是否应捕获附加信息,如 bug 报告。
它们在 CTS 中的定义位置在哪里?
CTS 系统状态检查工具的定义位置如下:/test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml。
如何查找检查工具发现的故障
默认情况下,系统检查工具故障仅显示在日志中,并会捕获为相应调用的 bug 报告,其名称遵循以下格式:bugreport-checker-post-module-<module name>.zip
根据此名称,您可以弄清是在哪个模块后生成的 bug 报告。
通过将 --report-system-checkers
选项设置为 true
,可以将系统检查工具本身报告为测试失败。这将导致测试运行显示为失败,并且失败的原因是状态检查工具的特定检查。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[null,null,["最后更新时间 (UTC):2025-03-26。"],[],[],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."]]