रेपो क्लाइंट का इस्तेमाल शुरू करें
रिपोर्ट पाने के लिए सोर्स डाउनलोड करने से जुड़े निर्देशों का पालन करें
Android सोर्स कोड बनाना होगा. repo init
निर्देश देते समय,
सीटीएस ब्रांच का इस्तेमाल करके, -b
का इस्तेमाल किया जा सकता है. इससे यह पक्का होता है कि आपके सीटीएस बदलावों को शामिल किया गया है
सीटीएस रिलीज़ में इन्हें शामिल किया गया है.
उदाहरण के तौर पर दिया गया यह कोड, 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
सीटीएस बनाएं और चलाएं
सीटीएस बनाने और इंटरैक्टिव सेशन शुरू करने के लिए, इन निर्देशों का पालन करें सीटीएस कंसोल:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
CTS कंसोल में, यह डालें:
tf> run cts --plan CTS
सीटीएस टेस्ट का डेटा सेव करने की अनुमति दें
में दिए गए निर्देशों के मुताबिक बनाया गया है.सीटीएस टेस्ट में, JUnit और Android टेस्टिंग एपीआई का इस्तेमाल किया जाता है. समीक्षा करें
जांच करें
आपका ऐप्लिकेशन
ट्यूटोरियल और मौजूदा परीक्षणों को cts/tests
डायरेक्ट्री में एक्सपोर्ट किया जाता है.
सीटीएस टेस्ट, ज़्यादातर Android टेस्ट में इस्तेमाल किए जाने वाले तौर-तरीकों का पालन करते हैं.
सीटीएस कई प्रोडक्शन डिवाइसों पर काम करता है, इसलिए टेस्ट सही समय पर होने चाहिए ये नियम:
- अलग-अलग स्क्रीन साइज़, ओरिएंटेशन, और कीबोर्ड लेआउट का ध्यान रखें.
- सिर्फ़ सार्वजनिक एपीआई तरीकों का इस्तेमाल करें. दूसरे शब्दों में, सभी क्लास, तरीकों, और फ़ील्ड से बचें
hide
एनोटेशन के साथ. - व्यू लेआउट का इस्तेमाल करने या उन ऐसेट के डाइमेंशन पर भरोसा करने से बचें जो शायद कुछ ऐसेट पर डिवाइस.
- रूट करने के खास अधिकारों पर भरोसा न करें.
Java के बारे में जानकारी जोड़ना
अगर आपकी जांच से किसी एपीआई के काम करने के तरीके की पुष्टि होती है, तो अपने टेस्ट कोड में @ApiTest
और सूची जोड़ें
apis
फ़ील्ड में शामिल सभी एपीआई. इनमें से उचित फ़ॉर्मैट का इस्तेमाल करें
ये उदाहरण देखें:
एपीआई टाइप | एनोटेशन फ़ॉर्मैट | नोट |
---|---|---|
Method | android.example.ClassA#methodA |
इस्तेमाल का सबसे सामान्य उदाहरण. |
मुख्य वैल्यू वाला तरीका | android.example.ClassB#methodB(KeyA) |
इसका इस्तेमाल सिर्फ़ तब करें, जब आपका टेस्ट किसी फ़ील्ड की पुष्टि करने के लिए, एपीआई तरीके का इस्तेमाल करता हो, जैसे कि यह उदाहरण देखें. |
फ़ील्ड | android.example.ClassC#FieldA | इसका इस्तेमाल तब ही करें, जब आपका टेस्ट किसी एपीआई फ़ील्ड की सीधे तौर पर पुष्टि करता हो, जैसे कि यह उदाहरण देखें. |
अगर आपकी जांच में सीडीडी की ज़रूरी शर्तों की पुष्टि की गई है, तो ज़रूरी शर्तों के आईडी के बारे में जानकारी दें. इसमें सीडीडी सेक्शन भी शामिल है
आईडी और ज़रूरी आईडी) के साथ सीटीएस टेस्ट कोड में @CddTest
शामिल होना चाहिए, जैसा कि
नीचे दिया गया उदाहरण देखें. तय किए गए मैसेज में बताएं कि आपके संगठन ने 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
में हर गतिविधि के साथ व्याख्या करें
ज़रूरी सीडीडी आईडी. मान फ़ील्ड के फ़ॉर्मैट, इसके Java एनोटेशन के फ़ॉर्मैट जैसे ही होते हैं
सीटीएस. तय किए गए मैसेज में, बताएं कि सीडीडी का रेफ़रंस देते हुए, सीडीडी की कौनसी ज़रूरी शर्त लागू की गई है
आवश्यकता आईडी.
<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 सबमिट करने की प्रोसेस का इस्तेमाल करना होगा.
सबप्लान बनाएं
उदाहरण के लिए, 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" />
नाम और जगह की जानकारी की जांच करें
ज़्यादातर सीटीएस टेस्ट केस, Android एपीआई में किसी खास क्लास को टारगेट करते हैं. ये टेस्ट
आपके Java पैकेज के नाम में cts
सफ़िक्स और क्लास के नाम शामिल हों
Test
सफ़िक्स. हर टेस्ट केस में कई टेस्ट होते हैं, जिनमें हर
आम तौर पर, टेस्ट में क्लास की जांच के लिए खास तरीके का इस्तेमाल किया जाता है.
इन जांचों को डायरेक्ट्री स्ट्रक्चर में व्यवस्थित किया जाता है, जहां टेस्ट को
विभिन्न श्रेणियां जैसे "विजेट" या "व्यू" शामिल हों.
उदाहरण के लिए, Java पैकेज के लिए CTS परीक्षण
android.widget.TextView
है
android.widget.cts.TextViewTest
अपने Java पैकेज नाम के साथ
android.widget.cts
और इसकी क्लास का नाम
TextViewTest
.
- Java पैकेज का नाम
सीटीएस टेस्ट के लिए Java पैकेज का नाम उस क्लास का पैकेज नाम है जिसकी जांच की जा रही है. इसके बाद,.cts
. हमारे उदाहरण के लिए, पैकेज का नामandroid.widget.cts
. - क्लास का नाम
सीटीएस टेस्ट के लिए क्लास का नाम "टेस्ट" की मदद से टेस्ट की जा रही क्लास का नाम जुड़ा होना चाहिए. इसके लिए उदाहरण के लिए, अगर कोई टेस्टTextView
को टारगेट कर रहा है, तो क्लास का नाम यह होना चाहिएTextViewTest
. - मॉड्यूल का नाम (सिर्फ़ CTS v2)
CTS v2, मॉड्यूल के हिसाब से टेस्ट को व्यवस्थित करता है. मॉड्यूल का नाम आम तौर पर Java पैकेज नाम की दूसरी स्ट्रिंग होता है (हमारे उदाहरण के लिए,widget
).
डायरेक्ट्री स्ट्रक्चर और सैंपल कोड इस बात पर निर्भर करता है कि CTS v1 का इस्तेमाल किया जा रहा है या नहीं या सीटीएस v2.
सीटीएस वर्शन 1
Android 6.0 या इससे पहले के वर्शन के लिए, CTS v1 का इस्तेमाल करें. CTS v1 के लिए सैंपल कोड
cts/tests/tests/example
.
सीटीएस v1 टेस्ट में डायरेक्ट्री का स्ट्रक्चर इस तरह दिखता है:
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
सीटीएस वर्शन 2
Android 7.0 या इसके बाद के वर्शन के लिए, CTS v2 का इस्तेमाल करें. जानकारी के लिए, यह देखें Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में सैंपल टेस्ट.
CTS v2 डायरेक्ट्री स्ट्रक्चर इस तरह दिखता है:
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
पैकेज के नए सैंपल
नए परीक्षण जोड़ते समय, हो सकता है कि आपके स्टोर में परीक्षण. ऐसे मामलों में, आपको डायरेक्ट्री बनानी होगी और उचित नमूना फ़ाइलें.
सीटीएस वर्शन 1
अगर आपने CTS v1 का इस्तेमाल किया है, तो
cts/tests/tests/example
पर जाएं और नई डायरेक्ट्री बनाएं. साथ ही,
अपने नए पैकेज के मॉड्यूल का नाम, Android.mk
से जोड़ना न भूलें
से लेकर CTS_COVERAGE_TEST_CASE_LIST
इंच
cts/CtsTestCaseList.mk
. build/core/tasks/cts.mk
इस मेकफ़ाइल का इस्तेमाल करता है
सभी टेस्ट को मिलाकर फ़ाइनल सीटीएस पैकेज बनाने के लिए किया जा सकता है.
सीटीएस वर्शन 2
सैंपल टेस्ट का इस्तेमाल करना
/cts/tests/sample/
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
नीचे दिए गए निर्देशों का पालन करके, नए टेस्ट मॉड्यूल को तुरंत शुरू किया जा सकता है:
- टेस्ट डायरेक्ट्री बनाने और सैंपल फ़ाइलों को कॉपी करने के लिए, इसे चलाएं:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
cts/tests/module-name
पर जाएं और सभी इंस्टेंस बदलें "[Ss]बहुत ज़्यादा" के साथ ऊपर दिए गए विकल्पों में से, नाम रखने का सुझाया गया तरीका.- आपको जिस सुविधा की जांच करनी है उसका इस्तेमाल करने के लिए,
SampleDeviceActivity
को अपडेट करें. - यह पक्का करने के लिए कि गतिविधि लॉग हो जाए या लॉग बना लें,
SampleDeviceTest
अपडेट करें गड़बड़ियां ठीक करें.
अतिरिक्त डायरेक्ट्री
अन्य Android डायरेक्ट्री, जैसे कि 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
के साथ एनोटेट किए गए टेस्ट हटाएं.
बदलावों को सबमिट करना
एओएसपी में सीटीएस या वीटीएस पैच सबमिट करते समय, अपनी डेवलपमेंट ब्रांच चुनें यह इस आधार पर तय किया जाता है कि पैच किस एपीआई लेवल पर लागू होता है.
-
एक से ज़्यादा एपीआई लेवल पर लागू होने वाले बदलावों के लिए, पहले
aosp/main
में एक पैच बनाएं और फिर सबसे ज़्यादा अपस्ट्रीम टेस्ट ब्रांच. ऑटोमर्जर को डाउनस्ट्रीम में बदलावों को मर्ज करने की अनुमति दें एओएसपी टेस्ट ब्रांच. यहां जाएं: यहां दी गई सूची के लिए, रिलीज़ का शेड्यूल और ब्रांच की जानकारी और इसकी जानकारी अपने-आप मर्ज होगी. - किसी खास एपीआई लेवल में खास तौर पर होने वाले बदलावों के लिए, अपनी पसंद के मुताबिक रणनीति बनाएं 'शामिल न करें' विकल्प का इस्तेमाल करके, सही टेस्ट ब्रांच में किए गए बदलाव या तय किए गए मैसेज में पाबंदी के साथ अपने-आप मर्ज होने की सुविधा.
पैच वर्कफ़्लो सबमिट करने का तरीका अपनाएं का इस्तेमाल, सीटीएस में बदलाव के लिए किया जा सकता है. इसके हिसाब से, आपके किए गए बदलाव की समीक्षा करने के लिए समीक्षक असाइन किया जाएगा.
रिलीज़ का शेड्यूल और ब्रांच की जानकारी
सीटीएस रिलीज़ इसी शेड्यूल के हिसाब से होती हैं.
वर्शन | API स्तर | शाखा | फ़्रीक्वेंसी |
---|---|---|---|
14 | 34 | android14-टेस्ट-डेव | तीन महीने में एक बार |
13 | 33 | android13-टेस्ट-डेव | तीन महीने में एक बार |
12 ली॰ | 32 | android12L-टेस्ट-डेव | तीन महीने में एक बार |
12 | 31 | android12-टेस्ट-डेव | तीन महीने में एक बार |
11 | 30 | android11-टेस्ट-डेव | तीन महीने में एक बार |
वर्शन 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3, और 4.2 के लिए, आगे कोई रिलीज़ की योजना नहीं है. |
रिलीज़ के दौरान अहम तारीखें
- पहले हफ़्ते के आखिर में: कोड को फ़्रीज़ करना. शाखा में बदलावों को मर्ज कर दिया गया जब तक कि सीटीएस के आने वाले वर्शन के लिए कोड को फ़्रीज़ नहीं किया जाता. कोड फ़्रीज़ होने के बाद या रिलीज़ को चुना जाता है और उसे बाद की रिलीज़ के लिए इस्तेमाल किया जाता है.
- दूसरा या तीसरा हफ़्ता: सीटीएस एओएसपी.
अपने-आप मर्ज होने का फ़्लो
सीटीएस डेवलपमेंट ब्रांच सेट अप की गई हैं, ताकि हर ब्रांच अपने-आप बड़ी ब्रांच में मर्ज हो जाती है.
सीधे एओएसपी टेस्ट डेवलपर ब्रांच में किए जाने वाले बदलावों के लिए, ऑटोमर्ज पाथ यह होता है:
android11-tests-dev
android12-tests-dev
>
android12L-tests-dev
android13-tests-dev
android14-tests-dev
aosp/main
सिर्फ़ अगले Android वर्शन में किए जाने वाले बदलावों के लिए, अपने-आप मर्ज होने का पाथ यह है:
aosp/main
<Internal git/main>
.
अगर कोई चेंजलिस्ट (CL) सही तरीके से मर्ज नहीं हो पाता है, तो पैच के लेखक को भेज दिया जाता है एक ईमेल मिलेगा, जिसमें विवाद सुलझाने के निर्देश होंगे. दुनिया में ज़्यादातर मामलों में, पैच का लेखक दस्तावेज़ों के CL.
अगर पुरानी ब्रांच में बदलाव करने की ज़रूरत है, तो पैच को यह नई ब्रांच से चुनी गई चेरी.