החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
CTS שמופעל על ידי מפתחים
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בדף הזה מפורטות הנחיות השימוש ב-CTS שמופעל על ידי מפתחים (CTS-D).
כיסוי הבדיקה
CTS-D, כמו CTS ו-CTS Verifier, יכול לאכוף רק את הדברים הבאים:
- כל ממשקי ה-API הציבוריים שמתוארים ב-SDK למפתחים (developer.android.com) לרמת API מסוימת.
- כל הדרישות החובה שכלולות במסמך ההגדרה של תאימות ל-Android (CDD) לרמת API מסוימת.
דרישות שאינן חובה, כמו 'מומלץ מאוד', 'צריך', 'יכול להיות', הן אופציונליות ואי אפשר לבדוק אותן באמצעות CTS.
מאחר שכל ממשקי ה-API והדרישות של CDD קשורים לרמת API ספציפית, כל בדיקות CTS (CTS, CTS-D ו-CTS Verifier) קשורות לאותה רמת API כמו ממשקי ה-API או הדרישות המשויכים. אם ממשק API ספציפי הוצא משימוש או השתנה, צריך להוציא משימוש או לעדכן את הבדיקה התואמת.
כללי יצירת בדיקות CTS
- הבדיקה צריכה להניב את אותה תוצאה אובייקטיבית באופן עקבי.
- כדי לקבוע אם מכשיר עובר את הבדיקה או נכשל בה, צריך לבדוק אותו פעם אחת אחרי פתיחת האריזה.
- יוצרים של בדיקות חייבים להסיר את כל הגורמים האפשריים שיכולים להשפיע על תוצאות הבדיקה.
- אם המכשיר צריך סביבה, הגדרה או תנאי חומרה מסוימים, צריך להגדיר אותם בבירור בהודעת ה-commit. הוראות להגדרה לדוגמה מפורטות במאמר הגדרת CTS.
- אסור להפעיל את הבדיקה למשך יותר מ-6 שעות בכל פעם. אם הבדיקה צריכה לפעול למשך זמן ארוך יותר, עליך לכלול את הסיבה לכך בהצעה לבדיקה כדי שנוכל לבדוק אותה.
בהמשך מופיעה דוגמה לקבוצת תנאי בדיקה לבדיקת הגבלת אפליקציה:
- חיבור ה-Wi-Fi יציב (בבדיקה שמבוססת על Wi-Fi).
- המכשיר נשאר נייח במהלך הבדיקה (או לא, בהתאם לבדיקה).
- המכשיר לא מחובר למקור חשמל ורמת הטעינה של הסוללה היא X אחוזים.
- אין אפליקציות, שירותים שפועלים בחזית או שירותים שפועלים ברקע שפועלים, מלבד CTS.
- המסך כבוי בזמן הרצת CTS.
- המכשיר הוא לא
isLowRamDevice.
- לא בוצעו שינויים בהגדרות ברירת המחדל של התכונה 'חיסכון בסוללה' או של הגבלות האפליקציות.
בדיקת הזכאות
אנחנו מקבלים בדיקות חדשות שמאכפות התנהגות שלא נבדקה בבדיקות CTS, CTS Verifier או CTS-D קיימות. כל בדיקה שבודקת התנהגות מחוץ להיקף של היקף הבדיקות שלנו תידחה.
תהליך שליחת CTS
- כתיבת הצעת בדיקה: מפתח האפליקציה שולח הצעת בדיקה באמצעות Google Issue Tracker, ומציין בה את הבעיה שזוהתה ומציע בדיקה כדי לבדוק אותה. ההצעה חייבת לכלול את מזהה הדרישה המשויך ל-CDD.
צוות Android בודק את ההצעה.
- פיתוח בדיקת CTS: אחרי שההצעה מאושרת, מי ששלח אותה יוצר בדיקת CTS ב-AOSP בהסתעפות הגרסה האחרונה של Android (
android16-release). צוות Android בודק את הקוד, ואם הוא מאושר, הוא בוחר את השינוי וממזג אותו עם ההסתעפות הפנימית של הפיתוח. פרטים נוספים זמינים במאמר איפה צריך להציע שינויים ב-AOSP?
הנחיות לכתיבת בדיקות CTS-D
- פועלים לפי מדריך הסגנון של קוד Java.
- פועלים לפי כל השלבים שמפורטים במאמר פיתוח CTS.
- מוסיפים את הבדיקות לתוכנית הבדיקה המתאימה:
- משתמשים ב-
include-filters כדי להוסיף את הבדיקות החדשות לתוכנית הבדיקה של CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- משתמשים ב-
exclude-filters כדי להחריג את הבדיקות החדשות מתוכנית הבדיקה הראשית של CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- לטפל בכל האזהרות וההצעות ב-
errorprone.build_error.log
- מבצעים ריבס של השינויים ב-
head. זה כולל את תוכניות הבדיקה cts-developer.xml ו-cts-developer-exclude.xml.
- עליכם לפנות לאיש הקשר שלכם מהנדס ב-Google כדי לבדוק אם אפשר לכלול את תרחיש הבדיקה שלכם במודול CTS קיים. אם לא, הם יעזרו לכם ליצור מודול חדש.
- לכל מודול בדיקה חדש שיוצרים, יוצרים קובץ OWNERS בספרייה של מודול הבדיקה החדש.
- קובץ ה-OWNERS צריך להכיל את הפרטים הבאים, שצריך לקבל מבעל הבדיקה ב-Google שאיתו אתם עובדים:
# Bug component: xxx- Google test owner ldap
- ב-
AndroidTest.xml, מציינים את הפרמטרים הבאים. תוכלו לעיין בקבצים לדוגמה (1, 2) כדי לראות דוגמאות:
Instant_app או not_instant_appsecondary_user או not_secondary_userall_foldable_states או no_foldable_states
- כדי לציין את גרסת ה-minSDK הנכונה, אפשר לעיין במסמכי התיעוד של <uses-sdk>.
- כשאתם שומרים שיטות בדיקה, כיתות או מודולים חדשים, מוסיפים אותם לתוכנית הבדיקה של CTS-D ומחריגים אותם מתוכנית הבדיקה הראשית של CTS באותו אופן שבו מוסיפים ומחריגים בדיקות חדשות.
הרצת הבדיקה של CTS-D
מריצים את תוכנית הבדיקה של CTS-D משורת הפקודה באמצעות run cts --plan cts-developer.
כדי להריץ תרחיש בדיקה ספציפי, משתמשים ב-run cts --include-filter "test_module_name test_name".
מידע על הפעלת ה-CTS המלא זמין במאמר הפעלת בדיקות CTS.
אישור והפצה
אחרי שליחת בקשת הבדיקה, צוות פנימי יבדוק אותה כדי לוודא שהיא בודקת דרישה של CDD או התנהגות מתועדת של API. אם יתברר שהבדיקה בודקת דרישה או התנהגות תקינים, הצוות יעביר את תרחיש הבדיקה הזה למהנדס של Google לבדיקה נוספת. מהנדס Google ייצור איתכם קשר עם משוב על הדרכים לשיפור הבדיקה, לפני שהיא תתקבל ל-CTS.
לפרטים על לוח הזמנים של הגרסאות של CTS, קראו את המאמר לוח זמנים להשקות ומידע על ההסתעפויות.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Developer-Powered CTS\n\nThis page outlines the usage guidelines for Developer-Powered CTS (CTS-D).\n\nTest coverage\n-------------\n\nCTS-D, like CTS \\& CTS Verifier, can only enforce the following:\n\n- All public APIs that are described in the developer SDK (developer.android.com) for a certain API level.\n- All MUST requirements that are included in the Android Compatibility Definition Document (CDD) for a certain API level.\n\nNon-MUST requirements, such as STRONGLY RECOMMENDED, SHOULD, MAY, are optional\nand can't be tested using CTS.\n\nBecause all APIs and CDD requirements are tied to a specific API level, all CTS\ntests (CTS, CTS-D, and CTS Verifier) are tied to the same API level as their\nassociated APIs or requirements. If a specific API is deprecated or changed,\nits corresponding test must be deprecated or updated.\n\nCTS test creation rules\n-----------------------\n\n- A test must produce the same objective result consistently.\n- A test must determine whether a device passes or fails by testing that device one time out of the box.\n- Test creators must remove all possible factors that could affect test results.\n- If a device needs a certain hardware condition/environment/setup, that setup must be clearly defined in the commit message. For example setup instructions, see [Setting Up CTS](/docs/compatibility/cts/setup).\n- The test must not run for more than 6 hours at a time. If it needs to run for longer, please include the reasoning in your test proposal so that we can review it.\n\nThe following is an example set of test conditions for testing an app\nrestriction:\n\n- Wifi is stable (for a test that relies on Wifi).\n- The device remains stationary during the test (or not, depending on the test).\n- The device is unplugged from any power source with X percent of battery level.\n- No apps, foreground services, or background services are running, except for CTS.\n- The screen is off while running CTS.\n- The device is NOT `isLowRamDevice`.\n- Battery saver / app restrictions have not been changed from the \"out-of-the-box\" state.\n\n### Test eligibility\n\nWe accept new tests that enforce a behavior that isn't tested by existing CTS,\nCTS Verifier, or CTS-D tests. Any test that checks a behavior outside the scope\nof [our test coverage](#coverage) will be rejected.\n\nCTS submission process\n----------------------\n\n1. **Write a test proposal:** An app developer submits a test proposal using [Google Issue Tracker](https://issuetracker.google.com/issues/new?component=1124973&template=1633344), describing the issue that has been identified and proposing a test to check for it. The proposal must include the associated [CDD requirement ID](/docs/compatibility/cts/development#annotation). The Android team reviews the proposal.\n2. **Develop a CTS test:** After a proposal is approved, its submitter creates a CTS test on AOSP on the Android latest release branch (`android16-release`). The Android team reviews the code and if accepted, cherrypicks the change and merges it into the internal development branch. For details, see [Where should I propose changes to AOSP?](/docs/setup/about/faqs#changes-aosp).\n\nCTS-D test writing guidelines\n-----------------------------\n\n- Follow the [Java Code Style Guide](/docs/setup/contribute/code-style).\n- Follow all the steps described in [CTS Development](/docs/compatibility/cts/development).\n- Add your tests to the appropriate test plan:\n - Use `include-filters` to add your new tests to the CTS-D test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer.xml`.\n - Use `exclude-filters` to exclude your new tests from the main CTS test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml`.\n- Handle all `errorprone` warnings and suggestions in `build_error.log`.\n- Rebase your changes to `head`. This includes the `cts-developer.xml` and `cts-developer-exclude.xml` test plans.\n- Work with your Google engineering contact to determine whether your test case can be included in an existing CTS module. If it can't, they'll help you create a new module.\n- For each new test module created, create an OWNERS file in the new test module directory.\n - Your OWNERS file should contain the following information, obtained from the Google test owner you're working with:\n - `# Bug component: xxx`\n - Google test owner ldap\n- In `AndroidTest.xml`, specify the following parameters. Refer to the sample files ([1](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/sample/), [2](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/sample/)) for examples:\n - `Instant_app` or `not_instant_app`\n - `secondary_user` or `not_secondary_user`\n - `all_foldable_states` or `no_foldable_states`\n- To specify the correct minSDK, refer to [the \\\u003cuses-sdk\\\u003e documentation](https://developer.android.com/guide/topics/manifest/uses-sdk-element).\n- When checking in new test methods, classes, or modules, add them to the CTS-D test plan and exclude them from the main CTS test plan in the same way as for new tests.\n\nRun your CTS-D test\n-------------------\n\nRun the CTS-D test plan [from the command line](/docs/compatibility/cts/command-console-v2)\nusing `run cts --plan cts-developer`.\n\nTo run a specific test case, use `run cts --include-filter \"test_module_name test_name\"`.\n\nFor information on running the full CTS, see [Run CTS tests](/docs/compatibility/cts/run).\n\nAcceptance and release\n----------------------\n\nOnce a test request is submitted, an internal team will review it to make sure\nit tests a CDD requirement or a documented API behavior. If the test is\ndetermined to be checking for a valid requirement or behavior, the team\nwill forward this test case to a Google engineer for further review. The Google\nengineer will reach out to you with feedback on how the test can be improved\nbefore it can be accepted into CTS.\n\nSee\n[Release schedule and branch information](/docs/compatibility/cts/development#release-schedule)\nfor details on the CTS release schedule."]]
