ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
โครงสร้างระดับสูงของการกําหนดค่า XML ของ Tradefed
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
การกําหนดค่าของ 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>
XML ของ Tradefed โดยรวมจะคั่นด้วยแท็ก <configuration>
Tradefed
objects
จะกําหนดไว้ในแท็กของตัวเอง เช่น build_provider
,
target_preparer
, test
ฯลฯ วัตถุประสงค์ของแต่ละรายการจะอธิบายไว้อย่างละเอียดในส่วนสถาปัตยกรรม
ออบเจ็กต์แต่ละรายการจะมีคลาส Java ที่เชื่อมโยงกับออบเจ็กต์ที่กําหนดไว้ใน class=
ที่แก้ไขได้เมื่อรันไทม์ ดังนั้น ตราบใดที่ไฟล์ JAR ที่มีคลาสอยู่ในเส้นทาง Class ของ Java ใน Tradefed เมื่อรัน ระบบก็จะพบและแก้ไขคลาสนั้นได้
ลำดับของออบเจ็กต์ Tradefed
ลำดับของแท็กต่างๆ ไม่สำคัญ เช่น ไม่ว่าจะระบุ build_provider
หลัง target_preparer
หรือไม่ก็ตาม ผลลัพธ์จะเหมือนกัน รันไทม์จะบังคับใช้ลําดับการเรียกใช้การทดสอบเอง ดังนั้นจึงจะเรียกใช้การทดสอบตามลําดับที่ถูกต้องเสมอ
ลําดับของออบเจ็กต์ที่มีแท็กเดียวกันมีความสําคัญ ตัวอย่างเช่น ระบบจะเรียกใช้ออบเจ็กต์ target_preparer
2 รายการที่กําหนดตามลําดับการกําหนดใน XML คุณควรทำความเข้าใจเรื่องนี้เนื่องจากอาจเปลี่ยนสถานะสุดท้ายของการตั้งค่าอุปกรณ์ เช่น การแฟลชแล้วติดตั้ง APK จะแตกต่างจากการติดตั้ง APK และการแฟลช เนื่องจากการแฟลชจะล้างข้อมูลในอุปกรณ์
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ 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."]]