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

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

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

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

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

CTS বিল্ড করতে এবং ইন্টারেক্টিভ 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

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

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

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

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

জাভা অ্যানোটেশন যোগ করুন

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

যদি আপনার টেস্ট কোনো CDD রিকোয়ারমেন্ট যাচাই করে, তাহলে নিচের উদাহরণে দেখানো অনুযায়ী CTS টেস্ট কোডে রিকোয়ারমেন্ট আইডি (CDD সেকশন আইডি এবং রিকোয়ারমেন্ট আইডি সহ)-কে @CddTest দিয়ে অ্যানোটেট করুন। আপনার কমিট মেসেজে, CDD রিকোয়ারমেন্ট আইডি উল্লেখ করে বলুন যে আপনার টেস্টটি কোন 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 ভেরিফায়ারের জন্য, আপনার AndroidManifest.xml এর প্রতিটি অ্যাক্টিভিটিতে প্রাসঙ্গিক CDD ID দিয়ে টীকা যুক্ত করুন। ভ্যালু ফিল্ডের ফরম্যাটগুলো CTS-এর জাভা অ্যানোটেশনের ফরম্যাটের মতোই। কমিট মেসেজে, CDD রিকোয়ারমেন্ট ID উল্লেখ করে বলুন কোন CDD রিকোয়ারমেন্টটি প্রয়োগ করা হয়েছে।

  <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 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" />

পরীক্ষার নামকরণ এবং অবস্থান

বেশিরভাগ CTS টেস্ট কেস অ্যান্ড্রয়েড এপিআই-এর একটি নির্দিষ্ট ক্লাসকে টার্গেট করে। এই টেস্টগুলোর জাভা প্যাকেজ নামের শেষে 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

অ্যান্ড্রয়েড ৬.০ বা তার নিচের সংস্করণের জন্য 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

অ্যান্ড্রয়েড ৭.০ বা তার উচ্চতর সংস্করণের জন্য 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 অধীনে থাকা উদাহরণটি দেখুন এবং একটি নতুন ডিরেক্টরি তৈরি করুন। এছাড়াও, আপনার নতুন প্যাকেজের মডিউলের নামটি তার Android.mk থেকে cts/CtsTestCaseList.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 আপডেট করুন।

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

অন্যান্য অ্যান্ড্রয়েড ডিরেক্টরি যেমন 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 দিয়ে চিহ্নিত টেস্টগুলো ঠিক করতে বা মুছে ফেলতে পারেন।

আপনার পরিবর্তনগুলি জমা দিন

CTS-এ পরিবর্তন যোগ করার সময় কোড পরিবর্তন জমা দেওয়ার কর্মপ্রবাহ অনুসরণ করুন।

• প্যাচটি যে API লেভেলগুলিতে প্রযোজ্য হবে, তার উপর ভিত্তি করে ডেভেলপমেন্ট ব্রাঞ্চটি বেছে নিন।
• কমিট মেসেজে DO NOT MERGE অথবা RESTRICT AUTOMERGE উল্লেখ করে পরিবর্তনগুলো সঠিক টেস্ট ব্রাঞ্চে ডেভেলপ বা চেরিপিক করুন।

আপনার পরিবর্তনটি পর্যালোচনা করতে এবং সেই অনুযায়ী অভ্যন্তরীণ Gerrit-এ পরিবর্তনটি অন্তর্ভুক্ত করার জন্য একজন পর্যালোচককে নিযুক্ত করা হয়।

প্রকাশের সময়সূচী এবং শাখা তথ্য

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

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

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

স্বয়ংক্রিয় একত্রীকরণ প্রবাহ

CTS ডেভেলপমেন্ট ব্রাঞ্চগুলো এমনভাবে সেট আপ করা হয়েছে, যাতে প্রতিটি ব্রাঞ্চে জমা দেওয়া পরিবর্তনগুলো স্বয়ংক্রিয়ভাবে উপরের ব্রাঞ্চগুলোতে মার্জ হয়ে যায়।

সরাসরি AOSP টেস্ট ডেভ ব্রাঞ্চে পরিবর্তনের জন্য, অটোমার্জ পাথটি হলো:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• CTS 16+ সংস্করণগুলোর জন্য, একজন পর্যালোচক সেই অনুযায়ী অভ্যন্তরীণ Gerrit-এ পরিবর্তনটি বেছে বেছে অন্তর্ভুক্ত করবেন।

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

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

পরবর্তী অ্যান্ড্রয়েড সংস্করণে প্রযোজ্য পরীক্ষামূলক পরিবর্তনের জন্য, আপনি প্রস্তাবিত পরিবর্তনটি আপলোড করার পর, গুগল তা পর্যালোচনা করে এবং গৃহীত হলে, সেটিকে অভ্যন্তরীণ গ্যারিটে অন্তর্ভুক্ত করে নেয়।