Check system status

System status checkers (SSCs) are defined at the suite-level configuration and run between each module. They perform checks to determine if the module changed and didn't restore some given states, for example changing a system property value.

SSCs are mainly used to ensure that module writers do not forget to clean up after their tests; but if they do, provide a trace of it so it can be addressed.

A secondary use is to also restore the original state when possible, for example dismissing the keyguard if it was left open.

System status checker XML definition

<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" />

SSCs are defined under the system_checker tag in the Tradefed configuration XML.

Implementation

Every SSC must implement the ISystemStatusChecker interface, which provides the two main methods preExecutionCheck and postExecutionCheck that run before and after each module execution.

It's possible for a checker to implement only one of the two, or to implement both if there's a need to check the state before the module and compare it to the state after the module.

Several example implementations exist in Tradefed. Each implementation is recommended to focus on a single check to improve reusability. For example, SystemServerStatusCheck checks if the system_server process restarted on the device during the test suite execution. In the postExecutionCheck, it calls deviceSoftRestarted, which is defined in NativeDevice to check if the system_server process restarted.

Each operation returns StatusCheckerResult, which lets the harness decide if additional information, like a bug report, should be captured.

Where are they defined in CTS?

CTS system status checkers are defined in /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml.

How to find checker failures

By default, system checker failures show only in the logs and as bug reports captured for the invocation with name following the format bugreport-checker-post-module-<module name>.zip.

This lets you find out after which module the bug report was generated.

It's possible to make the system checker report as a test failure itself by setting the --report-system-checkers option to true. This results in a test run showing as failed with the reason for failure being the status checker particular check.