از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
مجموعه تست سازگاری (CTS) یک مجموعه آزمایشی و ابزاری رایگان و تجاری است که برای اطمینان از سازگاری دستگاههای شما با Android استفاده میشود. CTS در نظر گرفته شده است که در جریان کار روزانه شما، مانند یک سیستم ساخت مداوم، یکپارچه شود. CTS روی یک ماشین رومیزی اجرا می شود و آزمایش ها را مستقیماً روی دستگاه های متصل یا شبیه ساز انجام می دهد. برای یک نمای کلی از سازگاری Android، به نمای کلی برنامه سازگاری Android مراجعه کنید.
شکل 1. تست خودکار CTS.
شکل 1 روند اجرای تست های خودکار CTS را نشان می دهد:
CTS را دانلود و نصب کنید. این مرحله همچنین شامل راهاندازی محیط آزمایش، ایستگاه کاری آزمایش، و دستگاهی است که آزمایش میکنید یا دستگاه تحت آزمایش (DUT)
تست های خودکار CTS را اجرا کنید.
نتایج را ذخیره و مرور کنید.
عیب یابی مشکلات و اجرای مجدد تست ها.
از CTS استفاده کنید تا ناسازگاریها را زودتر آشکار کنید و اطمینان حاصل کنید که پیادهسازیهای Android شما در طول فرآیند توسعه سازگار هستند.
اجزای CTS
CTS شامل اجزای اصلی زیر است:
فدراسیون تجارت
یک مهار و چارچوب تست امکان اجرای خودکار تست ها را فراهم می کند.
تست های خودکار CTS
تست هایی که از چارچوب فدراسیون تجارت استفاده می کنند و می توانند با استفاده از مهار تست فدراسیون تجارت اجرا شوند.
تست های تایید کننده CTS (CTS-V).
تست هایی که باید به صورت دستی اجرا شوند.
برنامه CTS Verifier (CTS-V).
برنامه ای که برای انجام تست های CTS-V و جمع آوری نتایج تست CTS-V استفاده می شود.
مورد آزمایشی
یک آزمایش انفرادی که در DUT اجرا می شود. کیسهای تست خودکار در جاوا بهعنوان آزمایشهای JUnit نوشته میشوند و فایلهای APK Android بستهبندی شدهاند تا روی هدف دستگاه اجرا شوند.
موارد تست می توانند تست های واحد یا تست های عملکردی باشند. یک تست واحد واحدهای اتمی کد را در پلتفرم اندروید آزمایش می کند. به عنوان مثال، یک تست واحد ممکن است یک کلاس اندروید را آزمایش کند.
یک تست عملکردی ترکیبی از روش ها و کلاس های مورد استفاده برای یک مورد خاص را تمرین می کند.
پیکربندی تست
مجموعه خاصی از تست های خودکار که روی DUT اجرا می شوند. پیکربندیهای آزمایشی فایلهای XML هستند که در WORKING_DIRECTORY /cts/tools/cts-tradefed/res/config قرار دارند. تنظیمات آزمایشی وجود دارد که شامل تمام موارد تست خودکار و تنظیمات آزمایشی است که شامل زیرمجموعه ای از موارد آزمایشی است.
ماژول تست
یک پیکربندی آزمایشی متشکل از مجموعه ای از موارد آزمایشی برای همان ناحیه ویژگی.
طرح تست
یک پیکربندی آزمایشی متشکل از مجموعه ای از ماژول های آزمایشی.
پوشش تست
موارد تست برای اطمینان از سازگاری، زمینه های زیر را پوشش می دهند:
منطقه
توضیحات
تست های امضا
برای هر نسخه اندروید، فایلهای XML وجود دارد که امضای همه APIهای عمومی موجود در نسخه را توصیف میکند. CTS حاوی ابزاری برای بررسی آن امضاهای API در برابر APIهای موجود در دستگاه است. نتایج بررسی امضا در فایل XML نتیجه آزمون ثبت می شود.
تست های پلتفرم API
APIهای پلتفرم (کتابخانههای هسته و چارچوب برنامه Android) را همانطور که در فهرست SDK Class مستند شده است آزمایش کنید تا از صحت API، از جمله امضاهای کلاس، ویژگی و روش صحیح، رفتار روش صحیح و آزمایشهای منفی اطمینان حاصل کنید تا از رفتار مورد انتظار برای کنترل نادرست پارامتر اطمینان حاصل کنید.
تست های دالویک
تمرکز این تست ها بر روی تست فرمت اجرایی Dalvik است.
مدل داده پلت فرم
CTS مدل داده های پلتفرم اصلی را همانطور که در بسته android.provider SDK (شامل مخاطبین، مرورگرها و تنظیمات) مستند شده است، از طریق ارائه دهندگان محتوا در معرض توسعه دهندگان برنامه آزمایش می کند.
مقاصد پلت فرم
CTS اهداف پلتفرم اصلی را همانطور که در مقاصد مشترک SDK مستند شده است آزمایش می کند.
مجوزهای پلتفرم
CTS مجوزهای پلتفرم اصلی را، همانطور که در SDK Manifest.permission مستند شده است، آزمایش می کند.
منابع پلت فرم
همانطور که در نمای کلی انواع منابع SDK مستند شده است، 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,["# The Compatibility Test Suite (CTS) overview\n\n*Compatibility Test Suite (CTS)* is a free, commercial-grade test suite and\ntools used to help ensure that your devices are Android compatible. CTS is\nintended to be integrated into your daily workflow, such as through a\ncontinuous build system. CTS runs on a desktop machine and executes tests\ndirectly on attached devices or on an emulator. For an overview of Android compatibility, see [Android compatibility program overview](/docs/compatibility).\n\n**Figure 1.** CTS automated testing.\n\nFigure 1 shows the process of executing CTS automated tests:\n\n1. Download and install CTS. This step also involves setting up the test environment, the testing workstation, and the device you are testing or *device under test (DUT)*\n2. Run CTS automated tests.\n3. Store and review the results.\n4. Troubleshoot issues and rerun tests.\n\nUse CTS to reveal incompatibilities early, and to ensure that your Android\nimplementations remain compatible throughout the development process.\n\nCTS components\n--------------\n\nCTS contains the following major components:\n\n*Trade Federation*\n: A test harness and framework allow for the automated execution of tests.\n\n*CTS automated tests*\n: Tests that use the Trade Federation framework and can be run using the Trade\n Federation test harness.\n\n*CTS Verifier (CTS-V) tests*\n: Tests that must be run manually.\n\n*CTS Verifier (CTS-V) app*\n: An app used to conduct CTS-V tests and collect CTS-V test results.\n\n*Test case*\n\n: An individual test executed on the DUT. Automated test cases are\n written in Java as JUnit tests and packaged Android APK files to run on the\n device target.\n\n Test cases can be *unit tests* or *functional tests*. A unit test tests atomic\n units of code within the Android platform. For example, a unit test might test\n a single Android class.\n\n A functional test exercises a combination of methods and classes used for a\n specific use case.\n\n*Test configuration*\n\n: A specific set of automated tests that are run on the\n DUT. Test configurations are XML files located in\n \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e`/cts/tools/cts-tradefed/res/config`.\n There are test configurations that contains all automated test cases and test\n configurations that contain a subset of test cases.\n\n*Test module*\n\n: A test configuration consisting of a collection of test cases for the same\n feature area.\n\n*Test plan*\n\n: A test configuration consisting of a collection of test modules.\n\n| **Note:** The Android Open Source Project accepts contributions to improve CTS just as for any other component. Improving the coverage and quality of CTS tests is one of the best ways to contribute to Android. To make contributions to CTS, follow the same process in [Submit code changes](/docs/setup/contribute/submit-patches).\n\nTest coverage\n-------------\n\nTest cases cover the following areas to ensure compatibility:\n\n| Area | Description |\n|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Signature tests | For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file. |\n| Platform API tests | Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK [Class Index](https://developer.android.com/reference/classes) to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling. |\n| Dalvik tests | The tests focus on testing the Dalvik executable format. |\n| Platform data model | The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK [`android.provider`](https://developer.android.com/reference/android/provider/package-summary) package (including contacts, browsers, and settings) |\n| Platform intents | The CTS tests the core platform intents, as documented in the SDK [Common intents](https://developer.android.com/guide/appendix/g-app-intents). |\n| Platform permissions | The CTS tests the core platform permissions, as documented in the SDK [`Manifest.permission`](https://developer.android.com/reference/android/Manifest.permission). |\n| Platform resources | The CTS tests for correct handling of the core platform resource types, as documented in the SDK [Resource types overview](https://developer.android.com/guide/topics/resources/available-resources). The CTS tests include tests for simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources. |\n\nWhat's next\n-----------\n\nAfter reading this document, continue to [Set up CTS](/docs/compatibility/cts/setup)."]]