Phát triển CTS

Khởi tạo ứng dụng khách Repo của bạn

Làm theo hướng dẫn từ Tải xuống nguồn để lấy và xây dựng mã nguồn Android. Khi ban hành lệnh repo init , hãy chỉ định một nhánh CTS cụ thể bằng cách sử dụng -b . Điều này đảm bảo rằng những thay đổi CTS của bạn được bao gồm trong các bản phát hành CTS tiếp theo.

Mã ví dụ sau đây cho thấy cách sử dụng repo init .

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

Xây dựng và vận hành CTS

Thực hiện các lệnh sau để xây dựng CTS và khởi động bảng điều khiển CTS tương tác:

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

Trong bảng điều khiển CTS, nhập:

tf> run cts --plan CTS

Viết bài kiểm tra CTS

Các thử nghiệm CTS sử dụng JUnit và API thử nghiệm Android. Xem lại hướng dẫn Kiểm tra ứng dụng của bạn và các thử nghiệm hiện có trong thư mục cts/tests . Các thử nghiệm CTS chủ yếu tuân theo các quy ước tương tự được sử dụng trong các thử nghiệm Android khác.

CTS chạy trên nhiều thiết bị sản xuất, vì vậy các thử nghiệm phải tuân theo các quy tắc sau:

  • Hãy tính đến các kích thước màn hình, hướng và bố cục bàn phím khác nhau.
  • Chỉ sử dụng các phương thức API công khai. Nói cách khác, tránh tất cả các lớp, phương thức và trường có chú thích hide .
  • Tránh sử dụng bố cục chế độ xem hoặc dựa vào kích thước của nội dung có thể không có trên một số thiết bị.
  • Đừng dựa vào quyền root.

Thêm chú thích Java

Nếu thử nghiệm của bạn xác minh hành vi API, hãy chú thích mã thử nghiệm của bạn bằng @ApiTest và liệt kê tất cả các API liên quan đến trường apis . Sử dụng định dạng thích hợp trong số các ví dụ sau:

loại API Định dạng chú thích Ghi chú
Phương pháp android.example.ClassA#methodA Trường hợp sử dụng phổ biến nhất.
Phương thức có giá trị khóa android.example.ClassB#methodB(KeyA) Chỉ sử dụng khi thử nghiệm của bạn sử dụng phương thức API để xác thực một trường, như trong ví dụ này.
Cánh đồng android.example.ClassC#FieldA Chỉ sử dụng khi thử nghiệm của bạn xác thực trực tiếp trường API, như trong ví dụ này.

Nếu bài kiểm tra của bạn xác minh yêu cầu CDD, hãy chú thích ID yêu cầu (bao gồm ID phần CDD và ID yêu cầu) bằng @CddTest trong mã kiểm tra CTS như trong ví dụ sau. Trong thông báo cam kết của bạn, hãy đề cập đến yêu cầu CDD nào được kiểm tra bằng thử nghiệm của bạn bằng cách tham khảo ID yêu cầu CDD. ID yêu cầu CDD là sự kết hợp giữa ID phần và ID yêu cầu, được kết nối bằng dấu gạch chéo (/) như trong 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()));
    }

Đối với Trình xác minh CTS, hãy chú thích từng Hoạt động trong AndroidManifest.xml của bạn bằng ID CDD có liên quan. Định dạng cho các trường giá trị tương tự như định dạng của chú thích Java trong CTS. Trong thông báo cam kết, hãy đề cập đến yêu cầu CDD nào được thực thi bằng cách tham chiếu ID yêu cầu 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>

Trong tin nhắn cam kết

Đề cập rõ ràng lý do tại sao bài kiểm tra của bạn cần được thêm vào và thêm các liên kết có liên quan để được hỗ trợ. Đối với các thử nghiệm CTS-D, hãy bao gồm liên kết tới đề xuất thử nghiệm mà bạn đã tạo trong Trình theo dõi vấn đề của Google như một phần của quy trình gửi CTS-D .

Tạo một kế hoạch phụ

Ví dụ: bạn có thể thêm tệp SubPlan.xml trong android-cts/subplans như sau:

<?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>

Để chạy kế hoạch phụ:

run cts --subplan aSubPlan

Định dạng mục nhập kế hoạch phụ là:

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

Kiểm tra việc đặt tên và vị trí

Hầu hết các trường hợp thử nghiệm CTS đều nhắm đến một lớp cụ thể trong API Android. Các thử nghiệm này có tên gói Java có hậu tố cts và tên lớp có hậu tố Test . Mỗi trường hợp thử nghiệm bao gồm nhiều bài kiểm tra, trong đó mỗi bài kiểm tra thường thực hiện một phương pháp cụ thể của lớp đang được kiểm tra. Các bài kiểm tra này được sắp xếp theo cấu trúc thư mục trong đó các bài kiểm tra được nhóm thành các danh mục khác nhau như "widget" hoặc "view".

Ví dụ: kiểm tra CTS cho gói Java android.widget.TextView là android.widget.cts.TextViewTest với tên gói Java là android.widget.cts và tên lớp là TextViewTest .

  • Tên gói Java
    Tên gói Java cho các bài kiểm tra CTS là tên gói của lớp mà bài kiểm tra đang kiểm tra, theo sau là .cts . Trong ví dụ của chúng tôi, tên gói sẽ là android.widget.cts .
  • Tên lớp
    Tên lớp cho các bài kiểm tra CTS là tên của lớp đang được kiểm tra có thêm "Kiểm tra". Ví dụ: nếu thử nghiệm đang nhắm mục tiêu TextView thì tên lớp phải là TextViewTest .
  • Tên mô-đun (chỉ CTS v2)
    CTS v2 tổ chức kiểm tra theo module. Tên mô-đun thường là chuỗi thứ hai của tên gói Java (trong ví dụ của chúng tôi là widget ).

Cấu trúc thư mục và mã mẫu phụ thuộc vào việc bạn đang sử dụng CTS v1 hay CTS v2.

CTS v1

Đối với Android 6.0 trở xuống, hãy sử dụng CTS v1. Đối với CTS v1, mã mẫu ở cts/tests/tests/example .

Cấu trúc thư mục trong các bài kiểm tra CTS v1 trông như thế này:

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

CTS v2

Đối với Android 7.0 trở lên, hãy sử dụng CTS v2. Để biết chi tiết, hãy xem thử nghiệm mẫu trong Dự án mã nguồn mở Android (AOSP) .

Cấu trúc thư mục CTS v2 trông như thế này:

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

Gói mẫu mới

Khi thêm bài kiểm tra mới, có thể không có thư mục hiện có để đặt bài kiểm tra của bạn. Trong những trường hợp đó, bạn cần tạo thư mục và sao chép các tệp mẫu thích hợp.

CTS v1

Nếu bạn đang sử dụng CTS v1, hãy tham khảo ví dụ trong cts/tests/tests/example và tạo một thư mục mới. Ngoài ra, hãy đảm bảo thêm tên mô-đun gói mới của bạn từ Android.mk vào CTS_COVERAGE_TEST_CASE_LIST trong cts/CtsTestCaseList.mk . build/core/tasks/cts.mk sử dụng tệp thực hiện này để kết hợp tất cả các thử nghiệm và tạo gói CTS cuối cùng.

CTS v2

Sử dụng bài kiểm tra mẫu /cts/tests/sample/ để bắt đầu nhanh mô-đun kiểm tra mới của bạn bằng các bước sau:

  1. Để tạo thư mục kiểm tra và sao chép các tệp mẫu, hãy chạy: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Điều hướng đến cts/tests/ module-name và thay thế tất cả các phiên bản của "[Ss]ample" bằng quy ước đặt tên được đề xuất ở trên.
  3. Cập nhật SampleDeviceActivity để thực hiện tính năng bạn đang thử nghiệm.
  4. Cập nhật SampleDeviceTest để đảm bảo rằng hoạt động thành công hoặc ghi lại lỗi của hoạt động đó.

Thư mục bổ sung

Các thư mục Android khác như assets , jni , libs và res cũng có thể được thêm vào. Để thêm mã JNI, hãy tạo một thư mục trong thư mục gốc của dự án bên cạnh src với mã gốc và tệp tạo tệp Android.mk trong đó.

Tệp makefile thường chứa các cài đặt sau:

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)

Tệp Android.mk

Cuối cùng, sửa đổi tệp Android.mk trong thư mục gốc của dự án để xây dựng mã gốc và phụ thuộc vào nó, như hiển thị bên dưới:

# 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))

Sửa hoặc xóa bài kiểm tra

Ngoài việc thêm các bài kiểm tra mới, bạn có thể sửa hoặc xóa các bài kiểm tra được chú thích bằng BrokenTest hoặc KnownFailure .

Gửi thay đổi của bạn

Khi gửi bản vá CTS hoặc VTS trong AOSP, hãy chọn nhánh phát triển của bạn dựa trên cấp độ API mà bản vá áp dụng.

  • Đối với những thay đổi áp dụng cho nhiều cấp độ API, trước tiên hãy phát triển một bản vá trong aosp/main , sau đó chuyển sang nhánh thử nghiệm ngược dòng nhất . Cho phép trình tự động hợp nhất hợp nhất các thay đổi ở phía dưới trong các nhánh thử nghiệm AOSP. Xem Lịch phát hành và thông tin chi nhánh để biết danh sách các chi nhánh và thông tin đường dẫn tự động hợp nhất.
  • Đối với các thay đổi dành riêng cho một cấp độ API cụ thể, hãy phát triển hoặc chọn lọc các thay đổi đối với nhánh thử nghiệm chính xác với KHÔNG HỢP NHẤT hoặc HẠN CHẾ TỰ ĐỘNG TRONG thông báo cam kết.

Thực hiện theo quy trình gửi bản vá để đóng góp các thay đổi cho CTS. Một người đánh giá sẽ được chỉ định để xem xét thay đổi của bạn cho phù hợp.

Lịch phát hành và thông tin chi nhánh

Các bản phát hành CTS tuân theo lịch trình này.

Phiên bản Cấp độ API Chi nhánh Tính thường xuyên
14 34 android14-tests-dev hàng quý
13 33 android13-tests-dev hàng quý
12L 32 android12L-tests-dev hàng quý
12 31 android12-tests-dev hàng quý
11 30 android11-tests-dev hàng quý
Không có kế hoạch phát hành thêm cho các phiên bản 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 và 4.2.

Những ngày quan trọng trong thời gian phát hành

  • Cuối tuần đầu tiên: Code bị treo. Những thay đổi được hợp nhất trong nhánh cho đến khi mã bị đóng băng sẽ được xem xét cho phiên bản sắp tới của CTS. Các đệ trình tới chi nhánh sau khi mã bị đóng băng hoặc sau khi một ứng cử viên để phát hành được chọn sẽ được xem xét cho lần phát hành tiếp theo.
  • Tuần thứ hai hoặc thứ ba: CTS được xuất bản trên AOSP .

Luồng tự động hợp nhất

Các nhánh phát triển CTS đã được thiết lập để những thay đổi được gửi tới từng nhánh sẽ tự động hợp nhất với các nhánh cao hơn.

Đối với các thay đổi trực tiếp đối với nhánh nhà phát triển thử nghiệm AOSP, đường dẫn tự động hợp nhất là:
android11-tests-dev > android12-tests-dev dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

Chỉ dành cho những thay đổi đối với phiên bản Android tiếp theo, đường dẫn tự động hợp nhất là:
aosp/main > <Internal git/main> .

Nếu danh sách thay đổi (CL) không hợp nhất chính xác, tác giả của bản vá sẽ nhận được email kèm theo hướng dẫn về cách giải quyết xung đột. Trong hầu hết các trường hợp, tác giả của bản vá có thể sử dụng hướng dẫn để bỏ qua quá trình tự động hợp nhất CL xung đột.

Nếu một nhánh cũ hơn yêu cầu thay đổi thì bản vá cần phải được chọn từ nhánh mới hơn.