החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
שימוש בבקרים של מודולים
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כל מודול בחבילה (שנקבע על ידי AndroidTest.xml) יכול להכיל אובייקט module_controller מיוחד שיכול לשנות התנהגות מסוימת של המודול:
האם להריץ את המודול או לא, על סמך תנאים מסוימים
מטמיעים את BaseModuleController ומוסיפים אותו ל-AndroidTest.xml כך:
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.<NAME>" />
באמצעות בקר המודול אפשר לקבוע אם המודול צריך לפעול או לא, על סמך ההטמעה של public abstract RunStrategy shouldRun(IInvocationContext context);.
האם לאסוף יומנים מסוימים במקרה של כשלים
כשמריצים חבילת בדיקות מלאה, אפשר לבקש ברמת החבילה את האיסוף של יומנים מסוימים במקרה של כשלים (צילום מסך, דיווח על באג, logcat). עם זאת, במודולים מסוימים, יכול להיות שליומן ספציפי שביקשתם לא יהיה ערך כלשהו, והוא פשוט יאבד זמן בזמן האיסוף שלו. במקרה כזה, מודול יכול לציין במפורש את היומנים שבהם הוא מעוניין:
<object type="module_controller"
class="com.android.tradefed.testtype.suite.module.TestFailureModuleController">
<option name="screenshot-on-failure" value="<true OR false>" />
<option name="bugreportz-on-failure" value="<true OR false>" />
<option name="logcat-on-failure" value="<true OR false>" />
</object>
הערה: אם אפשר, כדאי להטמיע את הבקרים באופן כללי כדי למקסם את האפשרות לשימוש חוזר. בנוסף, בעל המודול צריך לבדוק אם דילוג על מודול על סמך התנאי שלו הוא ההתנהגות המתאימה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Employ module controllers\n\nEach suite module (defined by `AndroidTest.xml`) can contain a special\n`module_controller` object that can alter some behavior of the module:\n\nWhether to run the module or not based on some conditions\n---------------------------------------------------------\n\nBy implementing [BaseModuleController](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/suite/module/BaseModuleController.java)\nand adding it to the `AndroidTest.xml` like this: \n\n \u003cobject type=\"module_controller\" class=\"com.android.tradefed.testtype.suite.module.\u003cNAME\u003e\" /\u003e\n\nThe module controller will be used to determine whether the module should run\nor not, based on the\n`public abstract RunStrategy shouldRun(IInvocationContext context);`\nimplementation.\n\nWhether to collect some logs or not on failures\n-----------------------------------------------\n\nWhen running a full suite, it's possible to request at the suite level the\ncollection of some logs on failures (screenshot, bugreport, logcat). But for\nsome modules, a particular log requested might not have any value and will\nsimply waste time to be collected. In that situation, a module can explicitly\nspecify which logs they are interested in: \n\n \u003cobject type=\"module_controller\"\n class=\"com.android.tradefed.testtype.suite.module.TestFailureModuleController\"\u003e\n \u003coption name=\"screenshot-on-failure\" value=\"\u003ctrue OR false\u003e\" /\u003e\n \u003coption name=\"bugreportz-on-failure\" value=\"\u003ctrue OR false\u003e\" /\u003e\n \u003coption name=\"logcat-on-failure\" value=\"\u003ctrue OR false\u003e\" /\u003e\n \u003c/object\u003e\n\nNOTE: Implementation of controllers should be generic if possible in order to\nmaximize re-usability. And skipping a module based on its condition should\nbe reviewed by the module owner to get the approval that skipping a module is\nthe proper behavior for them."]]
