सीटीएस विकास

अपने रेपो क्लाइंट को इनिशियलाइज़ करें

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

निम्नलिखित उदाहरण कोड दिखाता है कि repo init उपयोग कैसे करें।

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

सीटीएस बनाने और इंटरैक्टिव सीटीएस कंसोल शुरू करने के लिए निम्नलिखित कमांड निष्पादित करें:

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

सीटीएस कंसोल में, दर्ज करें:

tf> run cts --plan CTS

सीटीएस परीक्षण लिखें

CTS परीक्षण JUnit और Android परीक्षण API का उपयोग करते हैं। cts/tests निर्देशिका के अंतर्गत अपने ऐप का परीक्षण करें ट्यूटोरियल और मौजूदा परीक्षणों की समीक्षा करें। सीटीएस परीक्षण ज्यादातर अन्य एंड्रॉइड परीक्षणों में उपयोग की जाने वाली समान परंपराओं का पालन करते हैं।

सीटीएस कई उत्पादन उपकरणों पर चलता है, इसलिए परीक्षणों को इन नियमों का पालन करना होगा:

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

जावा एनोटेशन जोड़ें

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

यदि आपका परीक्षण सीडीडी आवश्यकता को सत्यापित करता है, तो सीटीएस परीक्षण कोड में @CddTest के साथ आवश्यकता आईडी (सीडीडी अनुभाग आईडी और आवश्यकता आईडी सहित) को एनोटेट करें जैसा कि निम्नलिखित उदाहरण में दिखाया गया है। अपने प्रतिबद्ध संदेश में, सीडीडी आवश्यकता आईडी का संदर्भ देकर उल्लेख करें कि आपके परीक्षण द्वारा किस सीडीडी आवश्यकता का परीक्षण किया गया है। सीडीडी आवश्यकता आईडी अनुभाग आईडी और आवश्यकता आईडी का एक संयोजन है, जो 7.3.1/सी-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 में प्रत्येक गतिविधि को संबंधित सीडीडी आईडी के साथ एनोटेट करें। मान फ़ील्ड के प्रारूप सीटीएस में जावा एनोटेशन के प्रारूप के समान हैं। प्रतिबद्ध संदेश में, सीडीडी आवश्यकता आईडी का संदर्भ देकर उल्लेख करें कि कौन सी सीडीडी आवश्यकता लागू की गई है।

  <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 इश्यू ट्रैकर में बनाया था।

एक उपयोजना बनाएं

उदाहरण के तौर पर, आप 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 प्रत्यय के साथ जावा पैकेज नाम और Test प्रत्यय के साथ वर्ग नाम होते हैं। प्रत्येक परीक्षण मामले में कई परीक्षण होते हैं, जहां प्रत्येक परीक्षण आम तौर पर परीक्षण किए जा रहे वर्ग की एक विशिष्ट विधि का प्रयोग करता है। इन परीक्षणों को एक निर्देशिका संरचना में व्यवस्थित किया जाता है जहां परीक्षणों को "विजेट्स" या "व्यूज़" जैसी विभिन्न श्रेणियों में समूहीकृत किया जाता है।

उदाहरण के लिए, जावा पैकेज android.widget.TextView के लिए CTS परीक्षण android.widget.cts.TextViewTest है, इसके जावा पैकेज का नाम android.widget.cts है और इसके वर्ग का नाम TextViewTest है।

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

निर्देशिका संरचना और नमूना कोड इस पर निर्भर करता है कि आप CTS v1 या CTS v2 का उपयोग कर रहे हैं या नहीं।

सीटीएस v1

Android 6.0 या उससे पहले के संस्करण के लिए, CTS v1 का उपयोग करें। सीटीएस 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

सीटीएस v2

Android 7.0 या उच्चतर के लिए, CTS v2 का उपयोग करें। विवरण के लिए, एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) में नमूना परीक्षण देखें।

CTS v2 निर्देशिका संरचना इस प्रकार दिखती है:

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

नए नमूना पैकेज

नए परीक्षण जोड़ते समय, हो सकता है कि आपके परीक्षण को रखने के लिए कोई मौजूदा निर्देशिका न हो। उन मामलों में, आपको निर्देशिका बनाने और उचित नमूना फ़ाइलों की प्रतिलिपि बनाने की आवश्यकता है।

सीटीएस v1

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

सीटीएस 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 अपडेट करें।

अतिरिक्त निर्देशिकाएँ

अन्य 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 के साथ एनोटेट किए गए परीक्षणों को ठीक कर सकते हैं या हटा सकते हैं।

अपने परिवर्तन सबमिट करें

एओएसपी में सीटीएस या वीटीएस पैच सबमिट करते समय, पैच किस एपीआई स्तर पर लागू होता है, उसके आधार पर अपनी विकास शाखा चुनें।

• एकाधिक एपीआई स्तरों पर लागू होने वाले परिवर्तनों के लिए, पहले aosp/main में एक पैच विकसित करें और फिर सबसे अपस्ट्रीम परीक्षण शाखा में चेरी-पिक करें। ऑटोमर्जर को AOSP परीक्षण शाखाओं में डाउनस्ट्रीम परिवर्तनों को मर्ज करने की अनुमति दें। शाखाओं की सूची और ऑटोमर्ज पथ जानकारी के लिए रिलीज़ शेड्यूल और शाखा जानकारी देखें।
• उन परिवर्तनों के लिए जो विशिष्ट एपीआई स्तर के लिए विशिष्ट हैं, प्रतिबद्ध संदेश में DO NOT MERGE या RESTRICT AUTOMERGE के साथ सही परीक्षण शाखा में परिवर्तनों को विकसित या चेरी-चयन करें।

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

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

सीटीएस रिलीज़ इस शेड्यूल का पालन करती हैं।

रिलीज के दौरान महत्वपूर्ण तारीखें

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

स्वचालित प्रवाह

सीटीएस विकास शाखाएं स्थापित की गई हैं ताकि प्रत्येक शाखा में सबमिट किए गए परिवर्तन स्वचालित रूप से उच्च शाखाओं में विलय हो जाएं।

AOSP परीक्षण देव शाखा में सीधे परिवर्तन के लिए, ऑटोमर्ज पथ है:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

केवल अगले Android संस्करण में परिवर्तन के लिए, ऑटोमर्ज पथ है:
aosp/main > <Internal git/main> ।

यदि कोई चेंजलिस्ट (सीएल) सही ढंग से विलय करने में विफल रहता है, तो पैच के लेखक को संघर्ष को हल करने के निर्देशों के साथ एक ईमेल भेजा जाता है। अधिकांश मामलों में, पैच के लेखक परस्पर विरोधी सीएल के ऑटोमर्ज को छोड़ने के लिए निर्देशों का उपयोग कर सकते हैं।

यदि किसी पुरानी शाखा को परिवर्तन की आवश्यकता है, तो पैच को नई शाखा से चेरी-पिक करने की आवश्यकता है।