פיתוח CTS

אתחל את לקוח ה-Repo שלך

עקוב אחר ההוראות מהורדת המקור כדי לקבל ולבנות את קוד המקור של אנדרואיד. בעת הוצאת הפקודה repo init , ציין ענף CTS ספציפי באמצעות -b . זה מבטיח ששינויי ה-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 ובממשקי API לבדיקות אנדרואיד. עיין במדריך לבדיקת האפליקציה שלך ובבדיקות הקיימות תחת ספריית cts/tests . בדיקות CTS עוקבות לרוב אחר אותן מוסכמות המשמשות במבחני אנדרואיד אחרים.

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 Verifier, סמן כל פעילות ב- AndroidManifest.xml שלך עם מזהה CDD הרלוונטי. הפורמטים של שדות ערך דומים לפורמטים של הערות Java ב-CTS. בהודעת ה-commit, ציין איזו דרישת 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 הוא שם המחלקה הנבדקת עם "מבחן" המצורף. לדוגמה, אם מבחן מכוון TextView , שם המחלקה צריך להיות TextViewTest .
• שם מודול (CTS v2 בלבד)
  CTS v2 מארגן בדיקות לפי מודול. שם המודול הוא בדרך כלל המחרוזת השנייה של שם חבילת Java (בדוגמה שלנו, 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

עבור אנדרואיד 7.0 ומעלה, השתמש ב-CTS v2. לפרטים, עיין במבחן לדוגמה ב-Android Open Source Project (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 כדי לוודא שהפעילות מצליחה או רושם את השגיאות שלה.

ספריות נוספות

ניתן להוסיף גם ספריות אנדרואיד אחרות כגון assets , jni , libs ו- res . כדי להוסיף קוד JNI, צור ספרייה בשורש הפרויקט ליד src עם הקוד המקורי וקובץ makefile של 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 ספציפית, פתח או בחר את השינויים לענף הבדיקה הנכון עם DO NOT MERGE או RESTRICT AUTOMERGE בהודעת ה-commit.

עקוב אחר זרימת העבודה של שליחת תיקונים כדי לתרום שינויים ל-CTS. סוקר יוקצה שיבדוק את השינוי שלך בהתאם.

לוח זמנים לשחרור ומידע על הסניף

מהדורות CTS עוקבות אחר לוח זמנים זה.

תאריכים חשובים במהלך ההוצאה

• סוף השבוע הראשון: הקפאת קוד. שינויים שמוזגו בסניף עד להקפאת הקוד נחשבים עבור הגרסה הקרובה של CTS. הגשות לסניף לאחר הקפאת הקוד, או לאחר בחירת מועמד לשחרור, נחשבות לשחרור הבא.
• שבוע שני או שלישי: CTS מתפרסם ב- AOSP .

זרימת מיזוג אוטומטי

סניפי פיתוח של CTS הוקמו כך ששינויים המוגשים לכל סניף מתמזגים אוטומטית לסניפים גבוהים יותר.

עבור שינויים ישירות בענף של מפתחי בדיקה של AOSP, נתיב המיזוג האוטומטי הוא:
android11-tests-dev > android12-tests-dev android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

עבור שינויים רק בגרסת האנדרואיד הבאה, נתיב המיזוג האוטומטי הוא:
aosp/main > <Internal git/main> .

אם רשימת שינויים (CL) לא מצליחה להתמזג כראוי, למחבר התיקון נשלח אימייל עם הוראות כיצד לפתור את ההתנגשות. ברוב המקרים, מחבר התיקון יכול להשתמש בהוראות כדי לדלג על המיזוג האוטומטי של ה-CL המתנגש.

אם ענף ישן יותר דורש את השינוי, יש לבחור את התיקון מהענף החדש יותר.