সিটিএস উন্নয়ন, সিটিএস উন্নয়ন

আপনার রেপো ক্লায়েন্ট শুরু করুন

অ্যান্ড্রয়েড সোর্স কোড পেতে এবং তৈরি করতে সোর্স ডাউনলোড করার নির্দেশাবলী অনুসরণ করুন। repo init কমান্ড জারি করার সময়, -b ব্যবহার করে একটি নির্দিষ্ট CTS শাখা উল্লেখ করুন। এটি নিশ্চিত করে যে আপনার CTS পরিবর্তনগুলি পরবর্তী CTS রিলিজে অন্তর্ভুক্ত করা হয়েছে।

নিম্নলিখিত উদাহরণ কোড দেখায় কিভাবে repo init ব্যবহার করতে হয়।

CTS তৈরি করুন এবং চালান

CTS তৈরি করতে এবং ইন্টারেক্টিভ CTS কনসোল শুরু করতে নিম্নলিখিত কমান্ডগুলি চালান:

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

CTS কনসোলে, লিখুন:

tf> run cts --plan CTS

CTS পরীক্ষা লিখুন

CTS পরীক্ষা JUnit এবং Android টেস্টিং API ব্যবহার করে। আপনার অ্যাপ টিউটোরিয়াল পরীক্ষা করুন এবং cts/tests ডিরেক্টরির অধীনে বিদ্যমান পরীক্ষাগুলি পর্যালোচনা করুন। CTS পরীক্ষাগুলি বেশিরভাগই অন্যান্য অ্যান্ড্রয়েড পরীক্ষায় ব্যবহৃত একই নিয়ম অনুসরণ করে।

CTS অনেক উত্পাদন ডিভাইস জুড়ে চলে, তাই পরীক্ষাগুলি অবশ্যই এই নিয়মগুলি অনুসরণ করবে:

• বিভিন্ন স্ক্রীনের আকার, অভিযোজন এবং কীবোর্ড লেআউট বিবেচনা করুন।
• শুধুমাত্র পাবলিক API পদ্ধতি ব্যবহার করুন. অন্য কথায়, hide টীকা সহ সমস্ত ক্লাস, পদ্ধতি এবং ক্ষেত্রগুলি এড়িয়ে চলুন।
• ভিউ লেআউট ব্যবহার করা বা সম্পদের মাত্রার উপর নির্ভর করা এড়িয়ে চলুন যা কিছু ডিভাইসে নাও থাকতে পারে।
• রুট সুবিধার উপর নির্ভর করবেন না।

জাভা টীকা যোগ করুন

যদি আপনার পরীক্ষা একটি API আচরণ যাচাই করে, তাহলে @ApiTest এর সাথে আপনার পরীক্ষার কোড টীকা করুন এবং apis ক্ষেত্রে জড়িত সমস্ত API তালিকা করুন। নিম্নলিখিত উদাহরণগুলির মধ্যে উপযুক্ত বিন্যাস ব্যবহার করুন:

আপনার পরীক্ষা যদি একটি CDD প্রয়োজনীয়তা যাচাই করে, তাহলে নিম্নলিখিত উদাহরণে দেখানো CTS পরীক্ষার কোডে @CddTest এর সাথে প্রয়োজনীয় আইডি (CDD সেকশন আইডি এবং প্রয়োজনীয় আইডি সহ) টীকা করুন। আপনার প্রতিশ্রুতি বার্তায়, সিডিডি প্রয়োজনীয়তা আইডি উল্লেখ করে আপনার পরীক্ষার মাধ্যমে কোন সিডিডি প্রয়োজনীয়তা পরীক্ষা করা হয়েছে তা উল্লেখ করুন। CDD রিকোয়ারমেন্ট আইডি হল সেকশন আইডি এবং রিকোয়ারমেন্ট আইডির সংমিশ্রণ, 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()));
    }

CTS যাচাইকারীর জন্য, প্রাসঙ্গিক CDD ID সহ আপনার AndroidManifest.xml এ প্রতিটি অ্যাক্টিভিটি টীকা করুন। মান ক্ষেত্রগুলির বিন্যাসগুলি CTS-এ জাভা টীকাগুলির বিন্যাসের অনুরূপ। প্রতিশ্রুতি বার্তায়, সিডিডি প্রয়োজনীয়তা আইডি উল্লেখ করে কোন সিডিডি প্রয়োজনীয়তা প্রয়োগ করা হয়েছে তা উল্লেখ করুন।

  <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 প্রত্যয় সহ এবং ক্লাসের নাম একটি Test প্রত্যয় সহ। প্রতিটি পরীক্ষার ক্ষেত্রে একাধিক পরীক্ষা থাকে, যেখানে প্রতিটি পরীক্ষা সাধারণত পরীক্ষা করা ক্লাসের একটি নির্দিষ্ট পদ্ধতি অনুশীলন করে। এই পরীক্ষাগুলি একটি ডিরেক্টরি কাঠামোতে সাজানো হয় যেখানে পরীক্ষাগুলিকে "উইজেট" বা "ভিউ" এর মতো বিভিন্ন বিভাগে গোষ্ঠীভুক্ত করা হয়।

উদাহরণস্বরূপ, জাভা প্যাকেজ android.widget.TextView এর জন্য CTS পরীক্ষা হল android.widget.cts.TextViewTest যার জাভা প্যাকেজের নাম android.widget.cts এবং এর ক্লাসের নাম TextViewTest ।

• জাভা প্যাকেজের নাম
  CTS পরীক্ষার জন্য জাভা প্যাকেজের নাম হল সেই ক্লাসের প্যাকেজের নাম যা পরীক্ষাটি পরীক্ষা করছে, তারপরে .cts । আমাদের উদাহরণের জন্য, প্যাকেজের নাম হবে android.widget.cts ।
• শ্রেণির নাম
  CTS পরীক্ষার জন্য ক্লাসের নাম হল "Test" যুক্ত করে পরীক্ষা করা ক্লাসের নাম। উদাহরণস্বরূপ, যদি একটি পরীক্ষা TextView লক্ষ্য করে, ক্লাসের নামটি TextViewTest হওয়া উচিত।
• মডিউল নাম (শুধুমাত্র CTS v2)
  CTS v2 মডিউল দ্বারা পরীক্ষা আয়োজন করে। মডিউল নামটি সাধারণত জাভা প্যাকেজ নামের দ্বিতীয় স্ট্রিং (আমাদের উদাহরণে, widget )।

আপনি CTS v1 বা CTS v2 ব্যবহার করছেন কিনা তার উপর ডিরেক্টরি কাঠামো এবং নমুনা কোড নির্ভর করে।

CTS v1

অ্যান্ড্রয়েড 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 ব্যবহার করুন। বিস্তারিত জানার জন্য, অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টে (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 প্যাকেজ তৈরি করতে।

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 আপডেট করুন৷

অতিরিক্ত ডিরেক্টরি

অন্যান্য Android ডিরেক্টরি যেমন assets , jni , libs , এবং res যোগ করা যেতে পারে। 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 প্যাচ জমা দেওয়ার সময়, প্যাচটি কোন API স্তরে প্রযোজ্য হবে তার উপর ভিত্তি করে আপনার বিকাশ শাখা বেছে নিন।

• একাধিক API স্তরে প্রযোজ্য পরিবর্তনের জন্য, প্রথমে aosp/main এ একটি প্যাচ তৈরি করুন এবং তারপরে সর্বাধিক আপস্ট্রিম পরীক্ষা শাখায় চেরি-পিক করুন। অটোমার্জারকে AOSP পরীক্ষা শাখায় পরিবর্তনগুলিকে একত্রিত করার অনুমতি দিন। শাখার তালিকা এবং অটোমার্জ পাথ তথ্যের জন্য প্রকাশের সময়সূচী এবং শাখা তথ্য দেখুন।
• একটি নির্দিষ্ট API স্তরের জন্য নির্দিষ্ট পরিবর্তনের জন্য, কমিট মেসেজে DO NOT MERGE বা RESTRICT AUTOMERGE দিয়ে সঠিক পরীক্ষা শাখায় পরিবর্তনগুলি বিকাশ করুন বা চেরি-পিক করুন।

CTS-তে পরিবর্তনগুলি অবদান রাখতে জমা দেওয়ার প্যাচ ওয়ার্কফ্লো অনুসরণ করুন। সেই অনুযায়ী আপনার পরিবর্তন পর্যালোচনা করার জন্য একজন পর্যালোচককে নিয়োগ করা হবে।

রিলিজ সময়সূচী এবং শাখা তথ্য

CTS রিলিজ এই সময়সূচী অনুসরণ করে.

রিলিজের সময় গুরুত্বপূর্ণ তারিখ

• প্রথম সপ্তাহের শেষ: কোড ফ্রিজ। CTS-এর আসন্ন সংস্করণের জন্য কোড ফ্রিজ না হওয়া পর্যন্ত পরিবর্তনগুলি শাখায় একত্রিত করা হয়। কোড ফ্রিজ হওয়ার পরে বা রিলিজের জন্য প্রার্থী বাছাই করার পরে শাখায় জমা দেওয়া পরবর্তী প্রকাশের জন্য বিবেচনা করা হয়।
• দ্বিতীয় বা তৃতীয় সপ্তাহ: CTS AOSP- এ প্রকাশিত হয়।

অটোমার্জ প্রবাহ

CTS উন্নয়ন শাখা স্থাপন করা হয়েছে যাতে প্রতিটি শাখায় জমা হওয়া পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে উচ্চতর শাখায় মিলিত হয়।

AOSP টেস্ট ডেভ শাখায় সরাসরি পরিবর্তনের জন্য, অটোমার্জ পাথ হল:
android11-tests-dev > android12-tests-dev dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

শুধুমাত্র পরবর্তী Android সংস্করণে পরিবর্তনের জন্য, অটোমার্জ পাথ হল:
aosp/main > <Internal git/main> ।

যদি একটি চেঞ্জলিস্ট (সিএল) সঠিকভাবে একত্রিত হতে ব্যর্থ হয়, তাহলে প্যাচের লেখককে বিরোধের সমাধান করার নির্দেশাবলী সহ একটি ইমেল পাঠানো হয়। বেশিরভাগ ক্ষেত্রে, প্যাচের লেখক বিরোধপূর্ণ CL-এর অটোমার্জ এড়িয়ে যেতে নির্দেশাবলী ব্যবহার করতে পারেন।

যদি একটি পুরানো শাখার পরিবর্তনের প্রয়োজন হয়, তাহলে প্যাচটিকে নতুন শাখা থেকে চেরি-বাছাই করতে হবে।