साल 2026 से, हम दूसरी और चौथी तिमाही में AOSP के लिए सोर्स कोड पब्लिश करेंगे. ऐसा इसलिए किया जाएगा, ताकि हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ काम कर सकें और यह पक्का कर सकें कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. AOSP बनाने और उसमें योगदान देने के लिए, android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव देखें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

सीटीएस डेवलपमेंट

Repo क्लाइंट शुरू करना

Android सोर्स कोड पाने और उसे बनाने के लिए, सोर्स कोड डाउनलोड करने से जुड़े निर्देश देखें. `repo init` कमांड देते समय, सीटीएस की कोई खास ब्रांच तय करने के लिए -b का इस्तेमाल करें. इससे यह पक्का होता है कि सीटीएस में किए गए आपके बदलाव, सीटीएस की आने वाली रिलीज़ में शामिल किए जाएं.

repo init का इस्तेमाल करने का तरीका बताने वाला कोड का उदाहरण यहां दिया गया है.

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

सीटीएस बनाना और उसे चलाना

सीटीएस बनाने और इंटरैक्टिव सीटीएस कंसोल शुरू करने के लिए, ये निर्देश चलाएं:

ध्यान दें: aosp_arm64 के बजाय aosp_x86_64 का इस्तेमाल किया जा सकता है.

सीटीएस बनाना (AOSP 14 या इससे पहले का वर्शन)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

सीटीएस बनाना (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

target-release की वैल्यू चुनने के लिए, कृपया यह टेबल देखें:

ब्रांच	टारगेट रिलीज़
android15-tests-dev	ap3a

सीटीएस चलाना

सीटीएस कंसोल में, यह डालें:

tf> run cts --plan CTS

सीटीएस टेस्ट लिखना

सीटीएस टेस्ट में JUnit और Android टेस्टिंग एपीआई का इस्तेमाल किया जाता है. cts/tests डायरेक्ट्री में, अपने ऐप्लिकेशन की जांच करें ट्यूटोरियल और मौजूदा टेस्ट देखें. सीटीएस टेस्ट में, आम तौर पर Android के अन्य टेस्ट में इस्तेमाल किए जाने वाले कन्वेंशन का पालन किया जाता है.

सीटीएस, प्रोडक्शन के कई डिवाइसों पर चलता है. इसलिए, टेस्ट इन नियमों के मुताबिक होने चाहिए:

स्क्रीन के अलग-अलग साइज़, ओरिएंटेशन, और कीबोर्ड लेआउट को ध्यान में रखें.
सिर्फ़ सार्वजनिक एपीआई के तरीकों का इस्तेमाल करें. दूसरे शब्दों में, `hide` एनोटेशन वाली सभी क्लास, तरीकों, और फ़ील्ड से बचें.hide
व्यू लेआउट का इस्तेमाल करने या ऐसे ऐसेट के डाइमेंशन पर भरोसा करने से बचें जो कुछ डिवाइसों पर मौजूद नहीं हो सकते.
रूट के खास अधिकारों पर भरोसा न करें.

Java एनोटेशन जोड़ना

अगर आपका टेस्ट, एपीआई के व्यवहार की पुष्टि करता है, तो अपने टेस्ट कोड में @ApiTest एनोटेशन जोड़ें. साथ ही, apis फ़ील्ड में शामिल सभी एपीआई की सूची बनाएं. इन उदाहरणों में से सही फ़ॉर्मैट का इस्तेमाल करें:

एपीआई का टाइप	एनोटेशन का फ़ॉर्मैट	नोट
तरीका	`android.example.ClassA#methodA`	इसका इस्तेमाल सबसे ज़्यादा किया जाता है.
कुंजी-वैल्यू वाले तरीके	`android.example.ClassB#methodB(KeyA)`	इसका इस्तेमाल सिर्फ़ तब करें, जब आपका टेस्ट किसी फ़ील्ड की पुष्टि करने के लिए, एपीआई के किसी तरीके का इस्तेमाल करता हो. जैसे, इस उदाहरण में किया गया है.
फ़ील्ड	`android.example.ClassC#FieldA`	इसका इस्तेमाल सिर्फ़ तब करें, जब आपका टेस्ट सीधे तौर पर एपीआई के किसी फ़ील्ड की पुष्टि करता हो. जैसे, इस उदाहरण में किया गया है.

अगर आपका टेस्ट, सीडीडी की किसी ज़रूरी शर्त की पुष्टि करता है, तो सीटीएस टेस्ट कोड में, ज़रूरी शर्त के आईडी (इसमें सीडीडी सेक्शन आईडी और ज़रूरी शर्त का आईडी शामिल है) में @CddTest एनोटेशन जोड़ें. जैसे, इस उदाहरण में दिखाया गया है. कमिट मैसेज में, यह बताएं कि आपके टेस्ट से सीडीडी की किस ज़रूरी शर्त की जांच की गई है. इसके लिए, सीडीडी की ज़रूरी शर्तों के आईडी का रेफ़रंस दें. सीडीडी की ज़रूरी शर्तों के आईडी, सेक्शन आईडी और ज़रूरी शर्त के आईडी का कॉम्बिनेशन होते हैं. इन्हें स्लैश (/) से जोड़ा जाता है. जैसे, 7.3.1/C-1-1.


/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

सीटीएस वेरिफ़ायर के लिए, अपने AndroidManifest.xml में मौजूद हर ऐक्टिविटी में, सीडीडी का सही आईडी जोड़ें. वैल्यू फ़ील्ड के फ़ॉर्मैट, सीटीएस में Java एनोटेशन के फ़ॉर्मैट जैसे ही होते हैं. कमिट मैसेज में, यह बताएं कि सीडीडी की किस ज़रूरी शर्त को लागू किया गया है. इसके लिए, सीडीडी की ज़रूरी शर्त के आईडी का रेफ़रंस दें.


  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

कमिट मैसेज में

साफ़ तौर पर बताएं कि आपके टेस्ट को जोड़ने की ज़रूरत क्यों है. साथ ही, सहायता के लिए काम के लिंक जोड़ें. सीटीएस-डी टेस्ट के लिए, Google Issue Tracker में बनाए गए टेस्ट के प्रपोज़ल का लिंक शामिल करें. यह लिंक, सीटीएस-डी सबमिट करने की प्रोसेस का हिस्सा है.

सबप्लान बनाना

उदाहरण के लिए, android-cts/subplans में SubPlan.xml फ़ाइल इस तरह जोड़ी जा सकती है:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

सबप्लान चलाने के लिए:

run cts --subplan aSubPlan

सबप्लान एंट्री का फ़ॉर्मैट यह है:

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

टेस्ट के नाम और जगह की जानकारी

सीटीएस के ज़्यादातर टेस्ट केस, Android API में मौजूद किसी खास क्लास को टारगेट करते हैं. इन टेस्ट के Java पैकेज के नाम में cts सफ़िक्स और क्लास के नाम में Test सफ़िक्स होता है. हर टेस्ट केस में कई टेस्ट शामिल होते हैं. आम तौर पर, हर टेस्ट में, टेस्ट की जा रही क्लास के किसी खास तरीके का इस्तेमाल किया जाता है. इन टेस्ट को डायरेक्ट्री स्ट्रक्चर में व्यवस्थित किया जाता है. इसमें टेस्ट को अलग-अलग कैटगरी में बांटा जाता है. जैसे, "विजेट" या "व्यू".

उदाहरण के लिए, Java पैकेज android.widget.TextView के लिए सीटीएस टेस्ट android.widget.cts.TextViewTest है. इसमें Java पैकेज का नाम android.widget.cts और क्लास का नाम TextViewTest है.

Java पैकेज का नाम
सीटीएस टेस्ट के लिए Java पैकेज का नाम उस क्लास का पैकेज का नाम होता है जिसकी जांच की जा रही है. इसके बाद, .cts जोड़ा जाता है. हमारे उदाहरण के लिए, पैकेज का नाम होगा android.widget.cts.
क्लास का नाम
सीटीएस टेस्ट के लिए क्लास का नाम, टेस्ट की जा रही क्लास का नाम होता है. इसके बाद, "Test" जोड़ा जाता है. उदाहरण के लिए, अगर कोई टेस्ट TextView को टारगेट कर रहा है, तो क्लास का नाम TextViewTest होना चाहिए.
मॉड्यूल का नाम (सिर्फ़ सीटीएस वर्शन 2 के लिए)
सीटीएस वर्शन 2 में, टेस्ट को मॉड्यूल के हिसाब से व्यवस्थित किया जाता है. मॉड्यूल का नाम, आम तौर पर Java पैकेज के नाम की दूसरी स्ट्रिंग होती है. हमारे उदाहरण में, यह widget है.

डायरेक्ट्री का स्ट्रक्चर और सैंपल कोड, इस बात पर निर्भर करता है कि सीटीएस वर्शन 1 या सीटीएस वर्शन 2 में से किसका इस्तेमाल किया जा रहा है.

सीटीएस वर्शन 1

Android 6.0 या इससे पहले वाले वर्शन के लिए, सीटीएस वर्शन 1 का इस्तेमाल करें. सीटीएस वर्शन 1 के लिए, सैंपल कोड cts/tests/tests/example पर मौजूद है.

सीटीएस वर्शन 1 के टेस्ट में डायरेक्ट्री का स्ट्रक्चर ऐसा दिखता है:

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

सीटीएस वर्शन 2

Android 7.0 या इसके बाद वाले वर्शन के लिए, सीटीएस वर्शन 2 का इस्तेमाल करें. ज़्यादा जानकारी के लिए, Android ओपन सोर्स प्रोजेक्ट (AOSP) में the सैंपल टेस्ट देखें.

सीटीएस वर्शन 2 में डायरेक्ट्री का स्ट्रक्चर ऐसा दिखता है:

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

नए सैंपल पैकेज

नए टेस्ट जोड़ते समय, हो सकता है कि आपके टेस्ट को रखने के लिए कोई मौजूदा डायरेक्ट्री न हो. ऐसे मामलों में, आपको डायरेक्ट्री बनानी होगी और सही सैंपल फ़ाइलें कॉपी करनी होंगी.

सीटीएस वर्शन 1

अगर सीटीएस वर्शन 1 का इस्तेमाल किया जा रहा है, तो cts/tests/tests/example में मौजूद उदाहरण देखें और नई डायरेक्ट्री बनाएं. इसके अलावा, पक्का करें कि CTS_COVERAGE_TEST_CASE_LIST में cts/CtsTestCaseList.mk में, अपने नए पैकेज का मॉड्यूल नाम, इसके Android.mk से जोड़ा गया हो. build/core/tasks/cts.mk सभी टेस्ट को एक साथ लाने और सीटीएस का फ़ाइनल पैकेज बनाने के लिए, इस मेकफ़ाइल का इस्तेमाल करता है.

सीटीएस वर्शन 2

अपने नए टेस्ट मॉड्यूल को तुरंत शुरू करने के लिए, सैंपल टेस्ट /cts/tests/sample/ का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

टेस्ट डायरेक्ट्री बनाने और सैंपल फ़ाइलें कॉपी करने के लिए, यह कमांड चलाएं:
```
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
```
cts/tests/module-name पर जाएं और "[Ss]ample" के सभी इंस्टेंस को ऊपर दिए गए नामकरण के सुझाए गए कन्वेंशन से बदलें.
जिस सुविधा की जांच की जा रही है उसे इस्तेमाल करने के लिए, SampleDeviceActivity को अपडेट करें.
SampleDeviceTest को अपडेट करें, ताकि यह पक्का किया जा सके कि गतिविधि पूरी हो गई है या इसकी गड़बड़ियां लॉग हो गई हैं.

अन्य डायरेक्ट्री

Android की अन्य डायरेक्ट्री भी जोड़ी जा सकती हैं. जैसे, assets, jni, libs, और res. जेएनआई कोड जोड़ने के लिए, प्रोजेक्ट के रूट में src के बगल में एक डायरेक्ट्री बनाएं. इसमें नेटिव कोड और Android.mk मेकफ़ाइल शामिल करें.

मेकफ़ाइल में, आम तौर पर ये सेटिंग शामिल होती हैं:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni

# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)

# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)

Android.mk फ़ाइल

आखिर में, प्रोजेक्ट के रूट में मौजूद Android.mk फ़ाइल में बदलाव करें, ताकि नेटिव कोड बनाया जा सके और इस पर निर्भर रहा जा सके. जैसे, यहां दिखाया गया है:

# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner

# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni

# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)

#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))

टेस्ट ठीक करना या हटाना

नए टेस्ट जोड़ने के अलावा, BrokenTest या KnownFailure एनोटेशन वाले टेस्ट ठीक किए जा सकते हैं या हटाए जा सकते हैं.

अपने बदलाव सबमिट करना

सीटीएस में बदलाव करने के लिए, कोड में बदलाव सबमिट करने का वर्कफ़्लो देखें.

डेवलपमेंट ब्रांच चुनते समय, यह देखें कि पैच किन एपीआई लेवल पर लागू होता है.
कमिट मैसेज में DO NOT MERGE या RESTRICT AUTOMERGE लिखकर, बदलावों को टेस्ट की सही ब्रांच में डेवलप करें या चेरीपिक करें.

आपके बदलाव की समीक्षा करने और इसे इंटरनल Gerrit में चेरीपिक करने के लिए, एक समीक्षक असाइन किया जाता है.

रिलीज़ करने का शेड्यूल और ब्रांच की जानकारी

सीटीएस की रिलीज़ इस शेड्यूल के हिसाब से होती हैं.

वर्शन	एपीआई लेवल	डेवलपमेंट ब्रांच	इस पॉडकास्ट के रिलीज़ होने की फ़्रीक्वेंसी
16+	36+	इंटरनल Gerrit	तीन महीने में एक बार
15	35	android15-tests-dev	तीन महीने में एक बार
14	34	android14-tests-dev	तीन महीने में एक बार
13	33	android13-tests-dev	तीन महीने में एक बार

रिलीज़ के दौरान अहम तारीखें

पहले हफ़्ते के आखिर तक: कोड फ़्रीज़. कोड फ़्रीज़ होने तक, ब्रांच में मर्ज किए गए बदलावों को सीटीएस के आने वाले वर्शन के लिए माना जाता है. कोड फ़्रीज़ होने के बाद या रिलीज़ के लिए उम्मीदवार चुने जाने के बाद, ब्रांच में सबमिट किए गए बदलावों को अगली रिलीज़ के लिए माना जाता है.
दूसरे या तीसरे हफ़्ते: सीटीएस को, Compatibility Test Suite डाउनलोड पेज पर पब्लिश किया जाता है.

ऑटोमर्ज फ़्लो

सीटीएस की डेवलपमेंट ब्रांच इस तरह सेट अप की गई हैं कि हर ब्रांच में सबमिट किए गए बदलाव, अपने-आप उससे ऊंची ब्रांच में मर्ज हो जाएं.

AOSP टेस्ट की डेवलपमेंट ब्रांच में सीधे तौर पर किए गए बदलावों के लिए, ऑटोमर्ज पाथ यह है:
android13-tests-dev > android14-tests-dev > android15-tests-dev

सीटीएस वर्शन 16 या इसके बाद वाले वर्शन के लिए, समीक्षक बदलाव को इंटरनल Gerrit में चेरीपिक करेगा.

अगर कोई चेंजलिस्ट (सीएल) सही तरीके से मर्ज नहीं होती है, तो पैच के लेखक को एक ईमेल भेजा जाता है. इसमें, टकराव को हल करने के तरीके के बारे में निर्देश दिए जाते हैं. ज़्यादातर मामलों में, पैच का लेखक निर्देशों का इस्तेमाल करके, टकराव वाली सीएल के ऑटोमर्ज को छोड़ सकता है.

अगर किसी पुरानी ब्रांच में बदलाव की ज़रूरत है, तो पैच को नई ब्रांच से चेरीपिक करना होगा.

Android के अगले वर्शन पर लागू होने वाले टेस्ट में किए गए बदलावों के लिए, सुझाया गया बदलाव अपलोड करने के बाद, Google इसकी समीक्षा करता है. अगर इसे स्वीकार कर लिया जाता है, तो Google इसे इंटरनल Gerrit में चेरीपिक करेगा.