تطوير CTS

إعداد برنامج Repo

اتّبِع التعليمات الواردة في مقالة تنزيل المصدر للحصول على وإنشاء رمز المصدر لنظام Android عند إصدار الأمر repo init، حدِّد فرع CTS المحدد باستخدام -b. يضمن ذلك تضمين تغييرات CTS الخاصة بك. في إصدارات CTS اللاحقة.

يعرض الرمز في المثال التالي طريقة استخدام "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

إنشاء 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. مراجعة الاختبار تطبيقك البرنامج التعليمي والاختبارات الحالية ضمن دليل cts/tests. تتبع اختبارات CTS في الغالب الاصطلاحات نفسها المستخدمة في اختبارات Android الأخرى.

تعمل CTS على العديد من أجهزة الإنتاج، لذلك يجب أن تتبع الاختبارات القواعد التالية:

• يجب مراعاة الأحجام المختلفة للشاشة والاتجاهات وتخطيطات لوحة المفاتيح.
• استخدام طرق واجهة برمجة التطبيقات العامة فقط. بمعنى آخر، تجنب جميع الفئات والطرق والحقول مع التعليق التوضيحي hide.
• تجنُّب استخدام تنسيقات العرض أو الاعتماد على أبعاد مواد العرض التي قد لا تكون متوفرة على بعض الأجهزة.
• لا تعتمد على امتيازات الجذر.

إضافة تعليق توضيحي لـ Java

إذا كان الاختبار يتأكد من صحة سلوك واجهة برمجة التطبيقات، يُرجى إضافة تعليقات توضيحية إلى رمز الاختبار باستخدام @ApiTest وإدراج. جميع واجهات برمجة التطبيقات المضمنة في الحقل apis. استخدم التنسيق المناسب من بين في ما يلي الأمثلة:

نوع واجهة برمجة التطبيقات	تنسيق التعليق التوضيحي	ملاحظات
الطريقة	android.example.ClassA#methodA	تمثّل هذه السمة حالة الاستخدام الأكثر شيوعًا.
الطريقة باستخدام القيم الرئيسية	android.example.ClassB#methodB(KeyA)	لا تُستخدم إلا عندما يستخدم الاختبار طريقة واجهة برمجة التطبيقات للتحقق من صحة حقل، كما في هذا المثال
الحقل	android.example.ClassC#FieldA	لا تُستخدم إلا عندما يتحقّق الاختبار من صحة أحد حقول واجهة برمجة التطبيقات مباشرةً، كما في هذا المثال

إذا أثبت الاختبار صحة متطلبات 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). في رسالة الإتمام، اذكر متطلبات 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 كجزء من عملية إرسال 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. هذه الاختبارات لها أسماء حزم 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
• اسم الوحدة (الإصدار 2 من CTS فقط)
  ينظّم الإصدار CTS v2 الاختبارات حسب الوحدة. يكون اسم الوحدة عادةً هو السلسلة الثانية من اسم حزمة Java (في مثل widget).

تعتمد بنية الدليل ونموذج الرمز على ما إذا كنت تستخدم الإصدار 1 من CTS. أو الإصدار 2 من CTS.

الإصدار 1 من CTS

بالنسبة إلى Android 6.0 أو الإصدارات الأقدم، استخدِم الإصدار CTS v1. بالنسبة إلى CTS الإصدار 1، يكون نموذج الرمز في cts/tests/tests/example

تبدو بنية الدليل في اختبارات الإصدار 1 من CTS على النحو التالي:

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

الإصدار 2 من CTS

إذا كنت تستخدم الإصدار 7.0 من نظام Android أو إصدارًا أحدث، استخدِم الإصدار 2 من CTS. للحصول على التفاصيل، يمكنك مراجعة اختبار نموذجي في "المشروع المفتوح المصدر لنظام Android" (AOSP)

تبدو بنية دليل CTS v2 على النحو التالي:

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

نماذج حِزم جديدة

عند إضافة اختبارات جديدة، قد لا يكون هناك دليل حالي لوضع الاختبار. في هذه الحالات، يجب إنشاء الدليل ونسخ نماذج الملفات المناسبة.

الإصدار 1 من CTS

إذا كنت تستخدم الإصدار 1 من CTS، فراجع المثال أدناه cts/tests/tests/example وأنشِئ دليلاً جديدًا. كذلك، احرص على إضافة اسم وحدة الحزمة الجديدة من Android.mk الخاصة بها. إلى CTS_COVERAGE_TEST_CASE_LIST بوصة cts/CtsTestCaseList.mk يستخدم build/core/tasks/cts.mk ملف التصميم هذا. لدمج جميع الاختبارات وإنشاء حزمة CTS النهائية.

الإصدار 2 من CTS

استخدام الاختبار النموذجي /cts/tests/sample/ للبدء السريع لوحدة الاختبار الجديدة بالخطوات التالية:

1. لإنشاء دليل الاختبار ونسخ نماذج الملفات، شغِّل:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. الانتقال إلى cts/tests/module-name واستبدال جميع مثيلات "[Ss]واسع" مع اصطلاح تسمية موصى به من أعلاه.
3. يُرجى تحديث "SampleDeviceActivity" لاستخدام الميزة التي تختبرها.
4. يجب تعديل SampleDeviceTest لضمان نجاح النشاط أو تسجيله. وأخطائها.

أدلة إضافية

أدلة Android الأخرى مثل 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، اختر فرع التطوير بناءً على مستويات واجهة برمجة التطبيقات التي ينطبق عليها رمز التصحيح.

• بالنسبة إلى التغييرات التي تنطبق على مستويات متعددة لواجهة برمجة التطبيقات، أولاً تطوير رمز في aosp/main ثم اختيار الأكثر فرع الاختبار. السماح للدمج التلقائي بدمج التغييرات في المراحل اللاحقة في فروع اختبار AOSP. عرض جدول الإصدار ومعلومات الفرع لقائمة فروع المسارات ودمجها تلقائيًا.
• بالنسبة إلى التغييرات الخاصة بمستوى معين من واجهة برمجة التطبيقات، يمكنك تطوير إجراء التغييرات على فرع الاختبار الصحيح باستخدام عدم الدمج أو تقييد تلقائيًا في رسالة التنفيذ

اتّبِع الخطوات الموضّحة في مقالة سير عمل إرسال رموز التصحيح. للمساهمة في التغييرات في CTS. سيتم تكليف أحد المراجعين لمراجعتها بناءً على ذلك.

الجدول الزمني لإصدار الفيديوهات ومعلومات الفرع

تتوافق إصدارات CTS مع هذا الجدول الزمني.

الإصدار	مستوى واجهة برمجة التطبيقات	Branch	التردد
15	35	تطوير اختبار android15	ربع سنوي
14	34	تطوير اختبار android14	ربع سنوي
13	33	تطوير اختبار android13	ربع سنوي
‫12L	32	android12L-tests-dev	ربع سنوي
12	31	تطوير اختبار android12	ربع سنوي

التواريخ المهمة خلال الإصدار

• نهاية الأسبوع الأول: تجميد الرموز. تم دمج التغييرات في الفرع حتى يتم النظر في تجميد الرمز للإصدار القادم من CTS. عمليات الإرسال إلى الفرع بعد تجميد الرمز أو بعد المرشح إصداره الذي تم اختياره، فلا يزال في الاعتبار للإصدار اللاحق.
• الأسبوع الثاني أو الثالث: يتم نشر 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) بشكل صحيح، فسيتم إرسال مؤلف التصحيح رسالة بريد إلكتروني تتضمن إرشادات حول كيفية حل التعارض. في معظم يمكن لمؤلف التصحيح استخدام التعليمات لتخطي عملية دمج قائمة التصنيف المتضاربة.

إذا كان الفرع الأقدم يتطلب التغيير، فيجب إزالة اللاصقة التي يتم انتقاؤها من الفرع الأحدث.