החל מ-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 שמכיל את המחלקה נמצא במסלול הטעינה של Java ב-Tradefed בזמן הריצה, הוא יימצא וייפתר.
הזמנות של אובייקטים ב-Tradefed
הסדר של התגים השונים לא משנה. לדוגמה, אין הבדל אם build_provider
מצוין אחרי target_preparer
. תהליך ההפעלה של הבדיקות נאכף על ידי ערכת הכלי עצמה, כך שהיא תמיד תפעיל אותן בסדר הנכון.
הסדר של אובייקטים עם אותו תג חשוב. לדוגמה, שני אובייקטים מסוג target_preparer
שהוגדרו יקראו לפי סדר ההגדרה שלהם ב-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."]]