การพัฒนา CTS

เริ่มต้นไคลเอ็นต์ Repo

ทำตามวิธีการจากการดาวน์โหลดซอร์สโค้ดเพื่อรับและสร้างซอร์สโค้ด Android เมื่อออกคําสั่ง repo init ให้ระบุสาขา CTS ที่เฉพาะเจาะจงโดยใช้ -b วิธีนี้ช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลง 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 การทดสอบของ Android ตรวจสอบบทแนะนำทดสอบแอปและการทดสอบที่มีอยู่ในส่วนไดเรกทอรี cts/tests การทดสอบ CTS ส่วนใหญ่เป็นไปตามรูปแบบเดียวกับที่ใช้กับการทดสอบอื่นๆ ของ Android

CTS ทำงานในอุปกรณ์เวอร์ชันที่ใช้งานจริงหลายรุ่น ดังนั้นการทดสอบจึงต้องเป็นไปตามกฎต่อไปนี้

• พิจารณาขนาด การวางแนว และเลย์เอาต์แป้นพิมพ์ของหน้าจอที่หลากหลาย
• ใช้เฉพาะเมธอด API สาธารณะ กล่าวคือ หลีกเลี่ยงคลาส วิธีการ และฟิลด์ทั้งหมดที่มีคำอธิบายประกอบ hide
• หลีกเลี่ยงการใช้เลย์เอาต์มุมมองหรือใช้ขนาดของชิ้นงานที่อาจไม่แสดงในอุปกรณ์บางรุ่น
• อย่าพึ่งพาสิทธิ์รูท

เพิ่มคำอธิบายประกอบ Java

หากการทดสอบยืนยันลักษณะการทํางานของ API ให้ใส่คำอธิบายประกอบโค้ดทดสอบด้วย @ApiTest และแสดงรายการ API ทั้งหมดที่เกี่ยวข้องในช่อง apis ใช้รูปแบบที่เหมาะสมจากตัวอย่างต่อไปนี้

หากการทดสอบยืนยันข้อกําหนด CDD ให้ใส่หมายเหตุประกอบรหัสข้อกําหนด (รวมถึงรหัสส่วน CDD และรหัสข้อกําหนด) ด้วย @CddTest ในโค้ดทดสอบ CTS ดังที่แสดงในตัวอย่างต่อไปนี้ ในข้อความคอมมิต ให้พูดถึงข้อกำหนด 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 ที่เกี่ยวข้อง รูปแบบของช่องค่าจะคล้ายกับรูปแบบของคำอธิบายประกอบ Java ใน CTS ในข้อความคอมมิต ให้ระบุข้อกำหนด CDD ที่จะบังคับใช้โดยอ้างอิงรหัสข้อกำหนด 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 ให้ใส่ลิงก์ไปยังข้อเสนอการทดสอบที่คุณสร้างใน Google Issue Tracker เป็นส่วนหนึ่งของกระบวนการส่ง CTS-D

สร้างแผนย่อย

ตัวอย่างเช่น คุณสามารถเพิ่มไฟล์ SubPlan.xml ใน android-cts/subplans ดังนี้

<?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 การทดสอบเหล่านี้มีชื่อแพ็กเกจ Java ที่มีคำต่อท้าย cts และชื่อคลาสที่มีคำต่อท้าย Test แต่ละชุดทดสอบประกอบด้วยการทดสอบหลายรายการ ซึ่งโดยทั่วไปการทดสอบแต่ละรายการจะใช้เมธอดที่เฉพาะเจาะจงของคลาสที่ทดสอบ การทดสอบเหล่านี้จะจัดเรียงในโครงสร้างไดเรกทอรีที่แบ่งการทดสอบออกเป็นหมวดหมู่ต่างๆ เช่น "วิดเจ็ต" หรือ "มุมมอง"

เช่น การทดสอบ CTS สําหรับแพ็กเกจ Java android.widget.TextView คือ android.widget.cts.TextViewTest ที่มีชื่อแพ็กเกจ Java ว่า android.widget.cts และชื่อคลาสว่า TextViewTest

• ชื่อแพ็กเกจ Java
  ชื่อแพ็กเกจ Java สำหรับการทดสอบ CTS คือชื่อแพ็กเกจของคลาสที่การทดสอบกำลังทดสอบ ตามด้วย .cts ในตัวอย่างนี้ ชื่อแพ็กเกจจะเป็น android.widget.cts
• ชื่อคลาส
  ชื่อคลาสสําหรับการทดสอบ CTS คือชื่อคลาสที่ทดสอบโดยต่อท้ายด้วย "Test" เช่น หากการทดสอบกําหนดเป้าหมายเป็น TextView ชื่อชั้นเรียนควรเป็น TextViewTest
• ชื่อโมดูล (CTS v2 เท่านั้น)
  CTS v2 จัดระเบียบการทดสอบตามโมดูล โดยปกติแล้วชื่อโมดูลจะเป็นสตริงที่ 2 ของชื่อแพ็กเกจ 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 แล้วสร้างไดเรกทอรีใหม่ นอกจากนี้ ให้ตรวจสอบว่าได้เพิ่มชื่อโมดูลของแพ็กเกจใหม่จาก Android.mk ไปจนจบที่ CTS_COVERAGE_TEST_CASE_LIST ใน cts/CtsTestCaseList.mk build/core/tasks/cts.mk ใช้ไฟล์ makefile นี้เพื่อรวมการทดสอบทั้งหมดและสร้างแพ็กเกจ 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 makefile อยู่

โดยปกติแล้วไฟล์ดังกล่าวจะมีการตั้งค่าต่อไปนี้

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 หรือ VTS ใน AOSP ให้เลือกสาขาการพัฒนาตามระดับ API ที่แพตช์มีผล

• สำหรับการเปลี่ยนแปลงที่มีผลกับ API หลายระดับ ให้พัฒนาแพตช์ใน aosp/main ก่อน แล้วเลือกเฉพาะรายการที่ต้องการไปยังสาขาการทดสอบที่อัปสตรีมมากที่สุด อนุญาตให้เครื่องมือผสานอัตโนมัติผสานการเปลี่ยนแปลงในสาขาทดสอบ AOSP ดูรายการสาขาและข้อมูลเส้นทางการผสานอัตโนมัติได้ที่กำหนดการเผยแพร่และข้อมูลสาขา
• สำหรับการเปลี่ยนแปลงที่มีผลกับ API ระดับหนึ่งๆ โดยเฉพาะ ให้พัฒนาหรือเลือกการเปลี่ยนแปลงที่ต้องการไปยังสาขาทดสอบที่ถูกต้องโดยใส่อย่าผสานหรือจำกัดการผสานอัตโนมัติในข้อความคอมมิต

ทำตามเวิร์กโฟลว์การส่งแพตช์เพื่อมีส่วนร่วมในการเปลี่ยนแปลง CTS ระบบจะมอบหมายผู้ตรวจสอบให้ตรวจสอบการเปลี่ยนแปลงของคุณตามความเหมาะสม

กำหนดการเผยแพร่และข้อมูลสาขา

การเผยแพร่ CTS จะเป็นไปตามกำหนดการนี้

วันที่สำคัญระหว่างการเผยแพร่

• สิ้นสุดสัปดาห์แรก: ไม่มีการแก้ไขโค้ด การเปลี่ยนแปลงที่ผสานในสาขาจะได้รับการพิจารณาสำหรับ CTS เวอร์ชันที่กำลังจะเปิดตัวจนกว่าจะมีการหยุดโค้ด การส่งไปยังสาขาหลังจากหยุดแก้ไขโค้ดแล้ว หรือหลังจากเลือกผู้สมัครสำหรับรุ่นแล้ว ระบบจะพิจารณาการส่งดังกล่าวสำหรับรุ่นถัดไป
• สัปดาห์ที่ 2 หรือ 3: CTS เผยแพร่ใน AOSP

ขั้นตอนการผสานอัตโนมัติ

เราได้ตั้งค่าสาขาการพัฒนา CTS เพื่อให้การเปลี่ยนแปลงที่ส่งไปยังแต่ละสาขาผสานรวมกับสาขาที่สูงกว่าโดยอัตโนมัติ

สำหรับการเปลี่ยนแปลงในสาขานักพัฒนาซอฟต์แวร์การทดสอบ 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>

หากผสานรายการการเปลี่ยนแปลง (CL) ไม่สำเร็จ ระบบจะส่งอีเมลพร้อมวิธีการแก้ไขข้อขัดแย้งไปยังผู้เขียนแพตช์ ในกรณีส่วนใหญ่ ผู้เขียนแพตช์สามารถใช้วิธีการเพื่อข้ามการผสาน CL ที่ขัดแย้งกันโดยอัตโนมัติ

หากสาขาเก่าจำเป็นต้องมีการเปลี่ยนแปลง ก็จะต้องเลือกแพตช์จากสาขาที่ใหม่กว่า