2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
시스템 상태 확인
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
시스템 상태 검사기(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는 각 모듈 실행 전과 후에 실행되는 두 가지 기본 메서드인 preExecutionCheck
및 postExecutionCheck
를 제공하는 ISystemStatusChecker
인터페이스를 구현해야 합니다.
검사기는 둘 중 하나만 구현할 수 있으며, 모듈 전에 상태를 확인하여 모듈 이후의 상태와 비교하는 경우에는 둘 다를 구현할 수도 있습니다.
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
로 설정하여 시스템 검사기 보고서를 테스트 실패 자체로 만들 수도 있습니다. 그러면 테스트 실행이 실패로 표시되며, 실패 이유는 상태 검사기에 한정된 검사가 됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Check system status\n\nSystem status checkers (SSCs) are defined at the suite-level configuration and\nrun between each module. They perform checks to determine if the module changed\nand didn't restore some given states, for example changing a system property\nvalue.\n\nSSCs are mainly used to ensure that module writers do not forget to clean up\nafter their tests; but if they do, provide a trace of it so it can be addressed.\n\nA secondary use is to also restore the original state when possible, for example\ndismissing the keyguard if it was left open.\n\nSystem status checker XML definition\n------------------------------------\n\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.KeyguardStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.LeakedThreadStatusChecker\" /\u003e\n \u003csystem_checker class=\"com.android.tradefed.suite.checker.SystemServerStatusChecker\" /\u003e\n\nSSCs are defined under the `system_checker` tag in the Tradefed configuration\nXML.\n\nImplementation\n--------------\n\nEvery SSC must implement the [`ISystemStatusChecker`\ninterface](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/ISystemStatusChecker.java),\nwhich provides the two main methods `preExecutionCheck` and `postExecutionCheck`\nthat run before and after each module execution.\n\nIt's possible for a checker to implement only one of the two, or to implement\nboth if there's a need to check the state before the module and compare it to\nthe state after the module.\n\nSeveral [example\nimplementations](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker)\nexist in Tradefed. Each implementation is recommended to focus on a single check\nto improve reusability. For example,\n[`SystemServerStatusCheck`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/SystemServerStatusChecker.java)\nchecks if the `system_server` process restarted on the device during the\ntest suite execution. In the `postExecutionCheck`, it calls `deviceSoftRestarted`,\nwhich is defined in\n[`NativeDevice`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/device/NativeDevice.java)\nto check if the `system_server` process restarted.\n\nEach operation returns\n[`StatusCheckerResult`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/suite/checker/StatusCheckerResult.java),\nwhich lets the harness decide if additional information, like a bug report,\nshould be captured.\n\nWhere are they defined in CTS?\n------------------------------\n\nCTS system status checkers are defined in\n[/test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml](https://android.googlesource.com/platform/cts/+/refs/heads/android16-release/tools/cts-tradefed/res/config/cts-system-checkers.xml).\n\nHow to find checker failures\n----------------------------\n\nBy default, system checker failures show only in the logs and as bug reports\ncaptured for the invocation with name following the format\n`bugreport-checker-post-module-\u003cmodule name\u003e.zip`.\n\nThis lets you find out after which module the bug report was generated.\n\nIt's possible to make the system checker report as a test failure itself by\nsetting the `--report-system-checkers` option to `true`. This results in a\ntest run showing as failed with the reason for failure being the status checker\nparticular check."]]