हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

CTS v2 कमांड कंसोल
संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

CTS v2 कंसोल का इस्तेमाल करना

Android 7.0 या इसके बाद के वर्शन के लिए, CTS v2 का इस्तेमाल करें.

प्लान चुनना

टेस्ट के लिए उपलब्ध प्लान में ये शामिल हैं:

cts—पहले से मौजूद सीटीएस इंस्टॉलेशन से सीटीएस चलाता है.
cts-camera— पहले से मौजूद सीटीएस इंस्टॉलेशन से CTS-camera चलाता है.
cts-java— पहले से मौजूद CTS इंस्टॉलेशन से, कोर Java टेस्ट चलाता है.
cts-pdk— PDK फ़्यूज़न बिल्ड की पुष्टि करने के लिए, काम की जांच करता है.
everything— Compatibility suites के लिए सामान्य कॉन्फ़िगरेशन.

उपलब्ध अन्य कॉन्फ़िगरेशन में ये शामिल हैं:

basic-reporters— बुनियादी सीटीएस रिपोर्टर के साथ कॉन्फ़िगरेशन.
collect-tests-only—यह पहले से मौजूद CTS इंस्टॉलेशन से CTS चलाता है.
common-compatibility-config— Compatibility suites के लिए सामान्य कॉन्फ़िगरेशन.
cts-filtered-sample— Compatibility Suite के लिए सामान्य कॉन्फ़िगरेशन.
cts-known-failures— सीटीएस की जानी-पहचानी गड़बड़ियों वाला कॉन्फ़िगरेशन.
cts-preconditions— सीटीएस की शर्तों के कॉन्फ़िगरेशन.
होस्ट— किसी मौजूदा डिवाइस पर, होस्ट पर आधारित एक टेस्ट चलाता है.
instrument— किसी मौजूदा डिवाइस पर, Android इंस्ट्रूमेंटेशन टेस्ट चलाता है.
native-benchmark— किसी मौजूदा डिवाइस पर नेटिव स्ट्रेस टेस्ट चलाता है.
native-stress— किसी मौजूदा डिवाइस पर नेटिव स्ट्रेस टेस्ट चलाता है.
फिर से चार्ज करें— यह एक फ़र्ज़ी टेस्ट है, जो बैटरी पूरी तरह खत्म होने के बाद डिवाइसों को चार्ज करने के लिए रोकता है.
testdef— किसी मौजूदा डिवाइस पर, test_def.xml फ़ाइलों में मौजूद टेस्ट चलाता है.
util/wifi— डिवाइस पर वाई-फ़ाई कॉन्फ़िगर करने के लिए यूटिलिटी कॉन्फ़िगरेशन.
util/wipe— डिवाइस पर उपयोगकर्ता का डेटा मिटाता है.

इन सभी प्लान और कॉन्फ़िगरेशन को run cts कमांड की मदद से लागू किया जा सकता है.

CTS v2 कंसोल कमांड का रेफ़रंस

इस टेबल में, अलग-अलग कामों के लिए, CTS v2 कंसोल कमांड की खास जानकारी दी गई है.

होस्ट	ब्यौरा
`help`	सबसे ज़्यादा इस्तेमाल किए जाने वाले कमांड की खास जानकारी दिखाना
`help all`	उपलब्ध निर्देशों की पूरी सूची दिखाना
`version`	वर्शन दिखाएं.
`exit`	CTS कंसोल से आसानी से बाहर निकलें. फ़िलहाल चल रहे सभी जांचें पूरी होने पर, कंसोल बंद हो जाता है.
`extdir`	डाउनलोड की गई फ़ाइल को zip से निकालकर `extdir` में बदल दिया जाता है. अगर आपको गलत आउटपुट से छुटकारा पाना है, तो `-q` विकल्प का इस्तेमाल करें: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` अगर आपको मौजूदा डायरेक्ट्री में अनज़िप करना है, तो `-d` विकल्प का इस्तेमाल न करें. इसके बजाय, यह तरीका अपनाएं: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
चलाएं	ब्यौरा
`run cts`	Android 10 में, डिफ़ॉल्ट सीटीएस प्लान और सीटीएस-इंस्टैंट को एक साथ चलाएं. Android 9 या इससे पहले के वर्शन के लिए, सिर्फ़ डिफ़ॉल्ट CTS प्लान चलाएं. डिवाइस की पुष्टि करने के लिए, इस विकल्प का इस्तेमाल करें. इसमें, ज़रूरी शर्तें भी शामिल हैं. शामिल किए गए आइटम के लिए, cts.xml देखें. टेस्ट चलने के दौरान, CTS कंसोल अन्य निर्देश स्वीकार कर सकता है. अगर कोई डिवाइस कनेक्ट नहीं है, तो जांच शुरू करने से पहले, सीटीएस डेस्कटॉप मशीन (या होस्ट) किसी डिवाइस के कनेक्ट होने का इंतज़ार करेगी. अगर एक से ज़्यादा डिवाइस कनेक्ट हैं, तो सीटीएस होस्ट अपने-आप कोई डिवाइस चुन लेगा.
`run cts-instant`	Android 9 के लिए, डिफ़ॉल्ट CTS-Instant प्लान चलाएं.
`run cts --module-parameter INSTANT_APP`	Android 10 में, डिफ़ॉल्ट CTS-Instant प्लान चलाएं.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	Android 10 में, तय किए गए CTS-Instant टेस्ट मॉड्यूल या मॉड्यूल चलाएं.
`run retry`	यह सुविधा सिर्फ़ Android 9 या इसके बाद के वर्शन वाले डिवाइसों के लिए उपलब्ध है. पिछले सेशन में, जिन टेस्ट को पूरा नहीं किया जा सका या जिन्हें पूरा नहीं किया गया था उन सभी को फिर से आज़माएं. उदाहरण के लिए, TF sharding के साथ `run retry --retry -s` या `run retry --retry --shard-count`. Android 9 या उसके बाद के वर्शन के लिए, `run cts --retry` का इस्तेमाल करने की अनुमति नहीं है.
`run cts-sim`	Android 11 या इसके बाद के वर्शन के लिए. सिम कार्ड वाले डिवाइस पर, टेस्ट के सबसेट को चलाता है.
`--device-token`	Android 8.1 या इससे पहले के वर्शन के लिए. इससे पता चलता है कि किसी डिवाइस में दिया गया टोकन है. उदाहरण के लिए, `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	सिर्फ़ Android 10 या इसके बाद के वर्शन के लिए. अपने-आप उस टेस्ट से मैच हो जाता है जिसके लिए उस सिम टाइप की ज़रूरत होती है. सिम से जुड़े टेस्ट केस को लागू करने के लिए, डिवाइस का सीरियल नंबर देने की ज़रूरत नहीं है. इस्तेमाल किए जा सकने वाले सिम: `SIM_CARD`, `UICC_SIM_CARD`, और `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	डिफ़ॉल्ट सीटीएस प्लान (यानी, सीटीएस को पूरी तरह से लागू करना) चलाएं, लेकिन किसी नए टेस्ट को बार-बार डेवलप करने के लिए, रन टाइम बचाने के लिए, पहले से तय शर्तें छोड़ें. इससे डिवाइस के कॉन्फ़िगरेशन की पुष्टि और सेटअप की प्रोसेस को बायपास किया जाता है. जैसे, मीडिया फ़ाइलें पुश करना या वाई-फ़ाई कनेक्शन की जांच करना. यह प्रोसेस, `--skip-preconditions` विकल्प का इस्तेमाल करने पर की जाती है. इस कमांड से, डिवाइस की जानकारी इकट्ठा करने की प्रोसेस और सिस्टम की स्थिति की जांच करने वाली सभी प्रोसेस भी स्किप हो जाती हैं. यह सिर्फ़ एक एबीआई पर भी टेस्ट चलाता है. डिवाइस की पुष्टि करने के लिए, इस ऑप्टिमाइज़ेशन से बचें और सभी शर्तें और जांच शामिल करें. बाहर रखे गए आइटम के लिए, cts-dev.xml देखें. टेस्ट चलने के दौरान, CTS कंसोल अन्य निर्देश स्वीकार कर सकता है. अगर कोई डिवाइस कनेक्ट नहीं है, तो जांच शुरू करने से पहले, सीटीएस डेस्कटॉप मशीन (या होस्ट) किसी डिवाइस के कनेक्ट होने का इंतज़ार करेगी. अगर एक से ज़्यादा डिवाइस कनेक्ट हैं, तो सीटीएस होस्ट अपने-आप कोई डिवाइस चुन लेगा.
`--subplan subplan_name`	तय किया गया सबप्लान चलाएं.
`--module/-m test_module_name --test/-t test_name`	चुने गए मॉड्यूल और टेस्ट को चलाएं. उदाहरण के लिए, `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` किसी खास पैकेज, क्लास या टेस्ट को चलाता है. चेतावनी: `--include-filter` विकल्प का इस्तेमाल करते समय, इस विकल्प का इस्तेमाल न करें.
`--retry`	पिछले सेशन में पूरे नहीं हो पाए या लागू नहीं किए गए सभी टेस्ट फिर से चलाएं. सेशन आईडी पाने के लिए, `list results` का इस्तेमाल करें.
`--retry-type NOT_EXECUTED`	सिर्फ़ उन टेस्ट को दोबारा चलाएं जो पिछले सेशन में नहीं चलाए गए थे. सेशन आईडी पाने के लिए, `list results` का इस्तेमाल करें.
`--shards number_of_shards`	Android 8.1 या इससे पहले के वर्शन के लिए. एक से ज़्यादा डिवाइसों पर एक साथ चलाने के लिए, किसी सीटीएस को कई इंडिपेंडेंट चंक में बांटना.
`--shard-count number_of_shards`	Android 9 के लिए. एक से ज़्यादा डिवाइसों पर एक साथ चलाने के लिए, सीटीएस को तय संख्या में अलग-अलग हिस्सों में बांटें.
`--serial/-s deviceID`	उस डिवाइस पर CTS चलाएं.
`--include-filter "test_module_name test_name"`	तय किए गए मॉड्यूल या टेस्ट पैकेज, क्लास, और केस के साथ चलाएं. उदाहरण के लिए, `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` में तय किया गया मॉड्यूल शामिल है. 'फिर से कोशिश करें' निर्देश चलाते समय, यह कमांड विकल्प काम नहीं करता. चेतावनी: `--module/-m` विकल्प का इस्तेमाल करते समय, इस विकल्प का इस्तेमाल न करें.
`--exclude-filter "test_module_name test_name"`	रन से, चुने गए मॉड्यूल या टेस्ट पैकेज, क्लास, और केस को बाहर रखें. उदाहरण के लिए, `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` बताए गए मॉड्यूल को बाहर रखता है.
`--log-level-display/-l log_level`	`STDOUT` को दिखाए गए लॉग लेवल के साथ चलाएं. मान्य वैल्यू: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	टेस्ट को दिए गए एबीआई, 32 या 64 पर चलाने के लिए मजबूर करें. डिफ़ॉल्ट रूप से, CTS हर उस एबीआई के लिए एक बार टेस्ट करता है जिस पर डिवाइस काम करता है.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	इससे गड़बड़ियों के बारे में ज़्यादा जानकारी मिलती है. साथ ही, गड़बड़ी का पता लगाने में भी मदद मिलती है.
`--device-token`	इससे पता चलता है कि किसी डिवाइस में दिया गया टोकन है, जैसे कि `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	डिवाइस की जानकारी इकट्ठा नहीं की जाती. चेतावनी: अनुमति के लिए सीटीएस चलाते समय, इस विकल्प का इस्तेमाल न करें.
`--skip-preconditions`	किसी नए टेस्ट के बार-बार किए जाने वाले डेवलपमेंट के लिए, रन टाइम बचाने के लिए, पहले से तय शर्तें छोड़ें. इससे डिवाइस के कॉन्फ़िगरेशन की पुष्टि और सेटअप की प्रोसेस को बायपास किया जाता है. जैसे, मीडिया फ़ाइलें पुश करना या वाई-फ़ाई कनेक्शन की जांच करना.
सूची में देखें	ब्यौरा
`list modules`	रिपॉज़िटरी में उपलब्ध सभी टेस्ट मॉड्यूल की सूची बनाएं.
`list plans` या `list configs`	रिपॉज़िटरी में मौजूद सभी टेस्ट प्लान (कॉन्फ़िगरेशन) की सूची बनाएं.
`list subplans`	रिपॉज़िटरी में मौजूद सभी सबप्लान की सूची बनाएं.
`list invocations`	डिवाइसों पर फ़िलहाल चल रहे रन निर्देशों की सूची.
`list commands`	डिवाइसों को असाइन किए जाने के लिए, फ़िलहाल सूची में मौजूद सभी रन कमांड की सूची बनाएं.
`list results`	रिपॉज़िटरी में मौजूद सीटीएस के नतीजों की सूची.
`list devices`	फ़िलहाल कनेक्ट किए गए डिवाइसों और उनकी स्थिति की सूची. उपलब्ध डिवाइस, काम करने वाले और काम न करने वाले डिवाइस होते हैं. ये टेस्ट करने के लिए उपलब्ध होते हैं. उपलब्ध नहीं डिवाइस, ऐसे डिवाइस होते हैं जो adb के ज़रिए दिखते हैं, लेकिन adb के निर्देशों का जवाब नहीं देते. साथ ही, इन्हें टेस्ट के लिए नहीं चुना जाएगा. असाइन किए गए डिवाइस, वे डिवाइस होते हैं जिन पर फ़िलहाल टेस्ट चल रहे हैं.
डंप करें	ब्यौरा
`dump logs`	चल रहे सभी अनुरोधों के लिए, tradefed लॉग को डंप करें.
जोड़ें	ब्यौरा
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	पिछले सेशन से लिया गया सबप्लान बनाएं; यह विकल्प एक ऐसा सबप्लान जनरेट करता है जिसका इस्तेमाल, टेस्ट के सबसेट को चलाने के लिए किया जा सकता है. सिर्फ़ `--session` विकल्प ज़रूरी है. अन्य एट्रिब्यूट की वैल्यू देना ज़रूरी नहीं है. हालांकि, अगर वैल्यू दी जाती है, तो उसके बाद वैल्यू देना ज़रूरी है. `--result-type` विकल्प को दोहराया जा सकता है. उदाहरण के लिए, `add subplan --session 0 --result-type passed --result-type failed` मान्य है.