از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
CTS مبتنی بر توسعه، CTS با پشتیبانی از توسعه
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این صفحه دستورالعمل‌های استفاده از CTS مبتنی بر توسعه‌دهنده (CTS-D) را تشریح می‌کند.
پوشش تست
CTS-D، مانند CTS و CTS Verifier، فقط می‌تواند موارد زیر را اعمال کند:
- همه APIهای عمومی که در SDK توسعه دهنده (developer.android.com) برای سطح API خاصی توضیح داده شده اند.
- همه الزامات MUST که در سند تعریف سازگاری Android (CDD) برای یک سطح API خاص گنجانده شده است.
الزامات غیر ضروری، مانند STRONGLY RECOMMENDED، SHOULD، MAY، اختیاری هستند و با استفاده از CTS قابل آزمایش نیستند.
از آنجایی که همه APIها و الزامات CDD به یک سطح API خاص مرتبط هستند، همه آزمایش‌های CTS (CTS، CTS-D، و CTS Verifier) به همان سطح API مرتبط با APIها یا الزامات مرتبط هستند. اگر یک API خاص منسوخ یا تغییر کند، آزمایش مربوطه آن باید منسوخ یا به‌روزرسانی شود.
قوانین ایجاد آزمون CTS
- یک آزمون باید همان نتیجه عینی را به طور مداوم ایجاد کند.
- یک آزمایش باید با آزمایش یک بار خارج از جعبه مشخص کند که آیا یک دستگاه موفق می شود یا ناموفق.
- سازندگان آزمون باید همه عوامل احتمالی را که می‌توانند بر نتایج آزمایش تأثیر بگذارند حذف کنند.
- اگر دستگاهی به شرایط سخت افزاری/محیط/تنظیم خاصی نیاز دارد، این تنظیمات باید به وضوح در پیام commit تعریف شود. برای مثال دستورالعمل‌های راه‌اندازی، به تنظیم CTS مراجعه کنید.
- آزمون نباید بیش از 6 ساعت در یک زمان اجرا شود. اگر نیاز است مدت بیشتری اجرا شود، لطفاً استدلال را در پروپوزال آزمایشی خود وارد کنید تا بتوانیم آن را بررسی کنیم.
در زیر مجموعه نمونه ای از شرایط آزمایش برای آزمایش محدودیت برنامه آورده شده است:
- Wifi پایدار است (برای آزمایشی که به Wifi متکی است).
- دستگاه در طول آزمایش ثابت می ماند (یا نه، بسته به آزمایش).
- دستگاه از هر منبع تغذیه ای با X درصد از سطح باتری جدا شده است.
- به جز CTS، هیچ برنامه، سرویس پیش‌زمینه یا سرویس پس‌زمینه در حال اجرا نیست.
- هنگام اجرای CTS صفحه خاموش است.
- دستگاه
isLowRamDevice نیست. - محدودیت های صرفه جویی در باتری / برنامه از حالت "خارج از جعبه" تغییر نکرده است.
واجد شرایط بودن آزمون
ما آزمایش‌های جدیدی را می‌پذیریم که رفتاری را اعمال می‌کنند که توسط آزمایش‌های CTS، CTS Verifier یا CTS-D موجود آزمایش نشده است. هر آزمونی که رفتاری خارج از محدوده پوشش آزمون ما را بررسی کند رد خواهد شد.
فرآیند ارسال CTS
- یک پیشنهاد آزمایشی بنویسید: یک توسعه‌دهنده برنامه با استفاده از Google Issue Tracker یک پیشنهاد آزمایشی ارائه می‌کند و مشکل شناسایی‌شده را شرح می‌دهد و آزمایشی برای بررسی آن پیشنهاد می‌کند. پیشنهاد باید شامل شناسه الزام CDD مرتبط باشد. تیم اندروید پیشنهاد را بررسی می کند.
- ایجاد یک تست CTS: پس از تایید یک پروپوزال، ارسال کننده آن یک تست CTS در AOSP در آخرین شاخه نسخه اندروید (
android16-release ) ایجاد می کند. تیم اندروید کد را بررسی می‌کند و در صورت پذیرش، تغییر را انتخاب می‌کند و آن را در شاخه توسعه داخلی ادغام می‌کند. برای جزئیات، ببینید کجا باید تغییرات AOSP را پیشنهاد کنم؟ .
دستورالعمل نوشتن آزمون CTS-D
- راهنمای سبک کد جاوا را دنبال کنید.
- تمام مراحل توضیح داده شده در توسعه CTS را دنبال کنید.
- تست های خود را به طرح آزمون مناسب اضافه کنید:
- برای افزودن آزمایش‌های جدید خود به طرح آزمایشی CTS-D
include-filters استفاده کنید: 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 - ldap مالک تست گوگل
- در
AndroidTest.xml ، پارامترهای زیر را مشخص کنید. برای نمونه به فایل های نمونه ( 1 , 2 ) مراجعه کنید:-
Instant_app یا not_instant_app -
secondary_user یا not_secondary_user -
all_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 ، برنامه زمان بندی انتشار و اطلاعات شعبه را ببینید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# 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."]]
