2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
Tradefed XML 구성의 상위 수준 구조
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Tradefed의 구성은 실행해야 하는 테스트와 준비/설정 단계를 설명하기 위해 XML 구성을 따릅니다.
이론적으로는 단일 명령어에 대해 모든 것을 XML에서 정의할 수 있습니다. 하지만 실제로는 기본 템플릿 XML 파일을 확보한 후 여기에 추가 명령줄 매개변수를 맞춤설정하는 것이 훨씬 실용적입니다.
구조
<configuration description="<description of the configuration>">
<!-- A build provider that takes local device information -->
<build_provider class="com.android.tradefed.build.BootstrapBuildProvider" />
<!-- Some target preparation, disabled by default -->
<target_preparer class="com.android.tradefed.targetprep.PreloadedClassesPreparer">
<option name="disable" value="true" />
</target_preparer>
<!-- One test running some unit tests -->
<test class="com.android.tradefed.testtype.HostTest">
<option name="class" value="com.android.tradefed.build.BuildInfoTest" />
</test>
<!-- [OPTIONAL] -->
<logger class="com.android.tradefed.log.FileLogger">
<option name="log-level" value="VERBOSE" />
<option name="log-level-display" value="VERBOSE" />
</logger>
<!-- [OPTIONAL] -->
<log_saver class="com.android.tradefed.result.FileSystemLogSaver" />
<!-- As many reporters as we want -->
<result_reporter class="com.android.tradefed.result.ConsoleResultReporter" />
<result_reporter class="com.android.tradefed.result.suite.SuiteResultReporter" />
<result_reporter class="com.android.tradefed.result.MetricsXMLResultReporter"/>
</configuration>
전체 Tradefed XML은 <configuration>
태그로 구분됩니다. Tradefed
objects
는 자체 태그에 build_provider
, target_preparer
, test
와 같이 정의되어 있습니다. 개별 용도에 대한 자세한 내용은 아키텍처 섹션에서 확인할 수 있습니다.
각 객체에는 런타임 시에 리졸브되는 class=
class=에 정의된 객체와 관련된 Java 클래스가 있습니다. 따라서 실행 시 클래스를 포함하는 JAR 파일만 Tradefed Java 클래스 경로에 있으면 이를 찾아 리졸브할 수 있습니다.
OTradefed 객체 순서
여러 태그의 순서는 상관없습니다. 예를 들어 build_provider
가 target_preparer
이후에 지정되면 차이가 없습니다. 테스트 호출의 흐름은 하네스 자체에 의해 적용되므로 항상 올바른 순서대로 호출됩니다.
같은 태그를 포함하는 객체의 순서는 상관이 있습니다. 예를 들어 정의된 두 개의 target_preparer
객체는 XML에서 정의 순서대로 호출됩니다. 기기 설정의 최종 상태가 변경될 수 있으므로 이를 이해하는 것이 중요합니다. 예를 들면 플래시에 이어 APK 설치는 APK 및 플래시 설치와 다르며, 이는 플래시로 기기가 삭제되기 때문입니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# High-level structure of Tradefed XML configuration\n\nTradefed's configurations follow an XML structure to describe the test to be run\nand the preparation/setup steps to be done.\n\nIn theory, everything can be defined in the XML for a single command. But in\npractice, it is more practical to have base template XML files and customize\nthem with extra command line parameters.\n\nStructure\n---------\n\n \u003cconfiguration description=\"\u003cdescription of the configuration\u003e\"\u003e\n \u003c!-- A build provider that takes local device information --\u003e\n \u003cbuild_provider class=\"com.android.tradefed.build.BootstrapBuildProvider\" /\u003e\n\n \u003c!-- Some target preparation, disabled by default --\u003e\n \u003ctarget_preparer class=\"com.android.tradefed.targetprep.PreloadedClassesPreparer\"\u003e\n \u003coption name=\"disable\" value=\"true\" /\u003e\n \u003c/target_preparer\u003e\n\n \u003c!-- One test running some unit tests --\u003e\n \u003ctest class=\"com.android.tradefed.testtype.HostTest\"\u003e\n \u003coption name=\"class\" value=\"com.android.tradefed.build.BuildInfoTest\" /\u003e\n \u003c/test\u003e\n\n \u003c!-- [OPTIONAL] --\u003e\n \u003clogger class=\"com.android.tradefed.log.FileLogger\"\u003e\n \u003coption name=\"log-level\" value=\"VERBOSE\" /\u003e\n \u003coption name=\"log-level-display\" value=\"VERBOSE\" /\u003e\n \u003c/logger\u003e\n\n \u003c!-- [OPTIONAL] --\u003e\n \u003clog_saver class=\"com.android.tradefed.result.FileSystemLogSaver\" /\u003e\n\n \u003c!-- As many reporters as we want --\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.ConsoleResultReporter\" /\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.suite.SuiteResultReporter\" /\u003e\n \u003cresult_reporter class=\"com.android.tradefed.result.MetricsXMLResultReporter\"/\u003e\n \u003c/configuration\u003e\n\nThe overall Tradefed XML is delimited by `\u003cconfiguration\u003e` tags. `Tradefed\nobjects` are defined in their own tags, for example: `build_provider`,\n`target_preparer`, `test`, etc. Their individual purposes are described in more\ndetail in the [Architecture](/docs/core/tests/tradefed/architecture)\nsection.\n\nEach object has the Java class associated with the object defined in `class=`\nthat is resolved at runtime; so as long as the JAR file containing the class is\non the Tradefed Java classpath when running, it will be found and resolved.\n\nOrders of Tradefed objects\n--------------------------\n\nThe order of the different tags does not matter. For example, it makes no\ndifference if `build_provider` is specified after `target_preparer`. The flow of\nthe test invocation is enforced by the harness itself, so it will always call\nthem in the right order.\n\nThe order of objects with the **same tag does matter** . For example, two\n`target_preparer` objects defined will be called in their order of definition in\nthe XML. It is important to understand this as it can change the end state of\nthe device setup. For example, *flashing then installing an apk* would not be the\nsame as *installing an apk and flashing* since flashing would wipe the device."]]