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.