اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
CTS من إنشاء المطوّرين
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توضّح هذه الصفحة إرشادات الاستخدام الخاصة بميزة CTS التي ينشئها المطوّرون (CTS-D).
تغطية الاختبار
لا يمكن لمجموعة أدوات CTS-D، مثل مجموعة أدوات CTS وأداة التحقّق في مجموعة أدوات CTS، فرض ما يلي إلّا:
- جميع واجهات برمجة التطبيقات المتاحة للجميع والموضّحة في حزمة تطوير البرامج (SDK) للمطوّرين
(developer.android.com) لمستوى معيّن من واجهة برمجة التطبيقات
- جميع المتطلبات التي يجب استيفاؤها والمُدرَجة في مستند تعريف المتوافقة مع Android (CDD) لمستوى معيّن من واجهة برمجة التطبيقات
إنّ المتطلّبات غير الحتمية، مثل "يُنصح بشدة" و"يجب" و"يمكن"، هي اختيارية
ولا يمكن اختبارها باستخدام مجموعة اختبار التوافق (CTS).
بما أنّ جميع واجهات برمجة التطبيقات ومتطلبات CDD مرتبطة بمستوى معيّن لواجهة برمجة التطبيقات، فإنّ جميع اختبارات CTS (CTS وCTS-D وCTS Verifier) مرتبطة بمستوى واجهة برمجة التطبيقات نفسه المرتبط
بواجهات برمجة التطبيقات أو المتطلبات المرتبطة بها. إذا تم إيقاف واجهة برمجة تطبيقات معيّنة أو تغييرها،
يجب إيقاف الاختبار المقابل لها أو تعديله.
قواعد إنشاء اختبارات CTS
- يجب أن يقدّم الاختبار النتيجة الموضوعية نفسها بشكلٍ متّسق.
- يجب أن يحدِّد الاختبار ما إذا كان الجهاز يجتاز الاختبار أو لا من خلال اختبار ذلك الجهاز
مرة واحدة خارج العلبة.
- على صنّاع المحتوى المشاركين في الاختبار إزالة جميع العوامل المحتمَلة التي قد تؤثّر في نتائج الاختبار.
- إذا كان الجهاز يحتاج إلى حالة/بيئة/إعدادات أجهزة معيّنة، يجب تحديد هذه الإعدادات
بوضوح في رسالة التعليق التوضيحي. للحصول على أمثلة على تعليمات الإعداد،
اطّلِع على مقالة إعداد CTS.
- يجب عدم تنفيذ الاختبار لأكثر من 6 ساعات في المرة الواحدة. إذا كان يجب تشغيله مدّة
أطول، يُرجى تضمين السبب في اقتراح الاختبار لنتمكّن من مراجعته.
في ما يلي مثال على مجموعة من شروط الاختبار لاختبار أحد قيود التطبيقات:
- شبكة Wifi ثابتة (للاختبار الذي يعتمد على شبكة Wifi)
- يظل الجهاز ثابتًا أثناء الاختبار (أو لا يظل ثابتًا، حسب الاختبار).
- تم فصل الجهاز عن أي مصدر طاقة ويبلغ مستوى شحن البطارية %X.
- لا يتم تشغيل أي تطبيقات أو خدمات تعمل في المقدّمة أو في الخلفية، باستثناء
CTS.
- تكون الشاشة مطفأة أثناء تشغيل CTS.
- الجهاز ليس
isLowRamDevice.
- لم يتم تغيير قيود "توفير شحن البطارية" أو التطبيقات عن حالتها عند بدء الاستخدام.
متطلبات الأهلية للاختبار
نقبل الاختبارات الجديدة التي تفرض سلوكًا لم يتم اختباره من خلال اختبارات CTS أو
CTS Verifier أو CTS-D الحالية. سيتم رفض أي اختبار يتحقّق من سلوك خارج نطاق
تغطية الاختبار.
عملية إرسال CTS
- كتابة اقتراح اختبار: يُرسل مطوّر التطبيقات اقتراح اختبار باستخدام
أداة تتبُّع المشاكل من Google، ويصف المشكلة التي تم رصدها ويقترح اختبارًا للتحقق منها. يجب أن يتضمّن الاقتراح معرّف متطلبات 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 في ملف directory الخاص بوحدة الاختبار الجديدة.
- يجب أن يحتوي ملف OWNERS على المعلومات التالية، التي يتم الحصول عليها من
مالك الاختبار في Google الذي تتعامل معه:
# Bug component: xxx- ldap لمالك الاختبار في Google
- في
AndroidTest.xml، حدِّد المَعلمات التالية. يمكنك الرجوع إلى نماذج الملفات (1 و2) للاطّلاع على أمثلة:
-
Instant_app أو not_instant_app
-
secondary_user أو not_secondary_user
-
all_foldable_states أو no_foldable_states
- لتحديد الحد الأدنى الصحيح لإصدار حزمة تطوير البرامج (SDK)، يُرجى الرجوع إلى مستندات <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 أو أحد سلوكيات واجهة برمجة التطبيقات الموثَّقة. إذا تبيّن للفريق أنّ الاختبار يبحث عن شرط أو سلوك صالحَين، سيعيد توجيه حالة الاختبار هذه إلى أحد مهندسي Google لإجراء مراجعة إضافية. سيتواصل معك مهندس Google لإطلاعك على ملاحظاته حول كيفية تحسين الاختبار قبل قبوله في CTS.
اطّلِع على الجدول الزمني للإصدار ومعلومات الفرع للحصول على تفاصيل عن الجدول الزمني لإصدار CTS.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
