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" />
SSCs are defined under the
system_checker tag in the Tradefed configuration
Every SSC must implement the
which provides the two main methods
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.
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:
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
--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.