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

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

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

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

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

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

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

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

CTS (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 वैल्यू चुनने के लिए, कृपया नीचे दी गई टेबल देखें:

CTS कंसोल में, यह जानकारी डालें:

tf> run cts --plan CTS

सीटीएस टेस्ट

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

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

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

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

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

अगर आपका टेस्ट सीडीडी की ज़रूरी शर्त की पुष्टि करता है, तो ज़रूरी शर्त के आईडी (इसमें सीडीडी सेक्शन आईडी और ज़रूरी शर्त का आईडी शामिल है) को एनोटेट करें. इसके लिए, सीटीएस टेस्ट कोड में @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 में मौजूद हर गतिविधि के लिए, काम के सीडीडी आईडी के साथ एनोटेट करें. वैल्यू फ़ील्ड के फ़ॉर्मैट, CTS में 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>

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

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

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

उदाहरण के लिए, 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" />

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

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

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

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

डायरेक्ट्री का स्ट्रक्चर और सैंपल कोड इस बात पर निर्भर करता है कि CTS v1 का इस्तेमाल किया जा रहा है या CTS v2 का.

CTS v1

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

CTS v1 टेस्ट में डायरेक्ट्री का स्ट्रक्चर इस तरह दिखता है:

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

CTS v2

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

CTS v2 डायरेक्ट्री का स्ट्रक्चर इस तरह दिखता है:

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

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

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

CTS v1

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

CTS v2

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

1. टेस्ट डायरेक्ट्री बनाने और सैंपल फ़ाइलों को कॉपी करने के लिए, यह चलाएं:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. cts/tests/module-name पर जाएं और ऊपर दिए गए नाम रखने के सुझाए गए नियम के हिसाब से, "[Ss]ample" के सभी इंस्टेंस बदलें.
3. जिस सुविधा की जांच की जा रही है उसे इस्तेमाल करने के लिए, SampleDeviceActivity को अपडेट करें.
4. SampleDeviceTest को अपडेट करें, ताकि यह पक्का किया जा सके कि गतिविधि पूरी हो गई है या उसकी गड़बड़ियां लॉग की गई हैं.

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

assets, jni, libs, और res जैसी अन्य Android डायरेक्ट्री भी जोड़ी जा सकती हैं. JNI कोड जोड़ने के लिए, प्रोजेक्ट के रूट में 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 के साथ एनोटेट किए गए टेस्ट को ठीक किया जा सकता है या हटाया जा सकता है.

किए गए बदलाव सबमिट करना

AOSP में CTS या VTS पैच सबमिट करते समय, अपनी डेवलपमेंट शाखा चुनें. ऐसा, इस आधार पर करें कि पैच किन एपीआई लेवल पर लागू होता है.

• एक से ज़्यादा एपीआई लेवल पर लागू होने वाले बदलावों के लिए, aosp/main में सबसे पहले पैच बनाएं. इसके बाद, सबसे ऊपर वाली टेस्ट शाखा में जाकर, अपने हिसाब से पैच चुनें. ऑटोमर्जर को, AOSP टेस्ट की शाखाओं में बदलावों को डाउनस्ट्रीम में मर्ज करने की अनुमति दें. शाखाओं की सूची और अपने-आप मर्ज होने वाले पाथ की जानकारी के लिए, रिलीज़ शेड्यूल और शाखा की जानकारी देखें.
• किसी खास एपीआई लेवल के लिए किए गए बदलावों के लिए, सही टेस्ट शाखा में बदलाव करें या चुनिंदा बदलाव करें. इसके लिए, कमिट मैसेज में मर्ज न करें या अपने-आप मर्ज होने पर पाबंदी लगाएं का इस्तेमाल करें.

CTS में बदलाव करने के लिए, पैच सबमिट करने के वर्कफ़्लो का पालन करें. इसके बाद, आपके बदलाव की समीक्षा करने के लिए किसी व्यक्ति को असाइन किया जाएगा.

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

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

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

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

अपने-आप मर्ज होने की प्रोसेस

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

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

सिर्फ़ अगले Android वर्शन में किए गए बदलावों के लिए, अपने-आप मर्ज होने का पाथ यह है:
aosp-main > <Internal git_main>.

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

अगर किसी पुरानी शाखा में बदलाव करना है, तो नए वर्शन से पैच को चुनना होगा.