Check System Status

Stay organized with collections Save and categorize content based on your preferences.

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="" />
<system_checker class="" />
<system_checker class="" />

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


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

It is possible for a checker to implement only one of the two, or to implement both if there is 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 re-usability. For example SystemServerStatusCheck will check 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 system_server process restarted.

Each operation returns a StatusCheckerResult that allows the harness to decide if additional information, like a bugreport, 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 bugreports captured for the invocation with name following the format: bugreport-checker-post-module-<module name>.zip

This allows you to find out after which module the bugreport was generated.

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