系统状态检查器 (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 ，它允许工具决定是否应捕获其他信息，例如错误报告。
它们在 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 ，可以使系统检查程序本身报告为测试失败。这将导致测试运行显示为失败，失败的原因是状态检查器的特定检查。
系统状态检查器 (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 ，它允许工具决定是否应捕获其他信息，例如错误报告。
它们在 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 ，可以使系统检查程序本身报告为测试失败。这将导致测试运行显示为失败，失败的原因是状态检查器的特定检查。
系统状态检查器 (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 ，它允许工具决定是否应捕获其他信息，例如错误报告。
它们在 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 ，可以使系统检查程序本身报告为测试失败。这将导致测试运行显示为失败，失败的原因是状态检查器的特定检查。