از 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
، و غیره. اهداف فردی آنها با جزئیات بیشتری در بخش معماری توضیح داده شده است.
هر شی دارای کلاس جاوا است که با شی تعریف شده در class=
مرتبط است که در زمان اجرا حل می شود. بنابراین تا زمانی که فایل JAR حاوی کلاس هنگام اجرا در مسیر کلاس جاوا Tradefed باشد، پیدا و حل خواهد شد.
سفارشات اشیاء معامله شده
ترتیب تگ های مختلف مهم نیست. برای مثال، فرقی نمیکند که build_provider
بعد از target_preparer
مشخص شود. جریان فراخوانی آزمایشی توسط خود مهار اجرا می شود، بنابراین همیشه آنها را به ترتیب مناسب فراخوانی می کند.
ترتیب اشیاء با برچسب یکسان مهم است . به عنوان مثال، دو شی target_preparer
تعریف شده به ترتیب تعریف خود در XML فراخوانی می شوند. درک این موضوع مهم است زیرا میتواند وضعیت پایان راهاندازی دستگاه را تغییر دهد. به عنوان مثال، فلش کردن و سپس نصب یک apk با نصب apk و فلش یکسان نیست زیرا فلش باعث پاک شدن دستگاه می شود.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]