টেস্ট স্যুট
কোনও টেস্টকে VTS-এর অংশ হতে হলে, Android.bp-এ নিম্নলিখিত সেটিংস থাকতে হবে।
test_suites: ["vts"],
এছাড়াও, টেস্টটি general-tests স্যুটে যোগ করলে, এটি প্রিসাবমিট চেকের জন্য ব্যবহৃত টেস্ট ম্যাপিং স্যুটের অংশ হতে পারে।
টেস্ট কনফিগারেশন
বেশিরভাগ ক্ষেত্রে, টেস্ট কনফিগারেশন, যা VTS টেস্ট চালানোর জন্য Trade Federation ব্যবহার করে এমন একটি XML ফাইল, তা বিল্ডের সময় অটোমেটিক জেনারেট হয়। তবে, আপনি টেস্ট কনফিগারেশন কাস্টমাইজ করতে পারবেন।
কাস্টমাইজ করা টেস্ট কনফিগারেশন ফাইল তৈরি করা
একেবারে শুরু থেকে নতুন টেস্ট XML ফাইল তৈরি করা জটিল হতে পারে, কারণ এর জন্য টেস্ট হারনেস কীভাবে কাজ করে তা বোঝার পাশাপাশি প্রতিটি টেস্ট রানারের মধ্যে পার্থক্য বুঝতে হয়। অটোমেটিক তৈরি হওয়া টেস্ট কনফিগারেশন ফাইলটি এই প্রসেসকে আরও সহজ করে তোলার জন্য ডিজাইন করা হয়েছে।
আপনাকে যদি টেস্ট XML ফাইল কাস্টমাইজ করতেই হয়, তাহলে আপনি অটোমেটিক তৈরি হওয়া ফাইলটি শুরুর স্থান হিসেবে ব্যবহার করতে পারেন।
অটোমেটিক তৈরি হওয়া টেস্ট কনফিগারেশন ফাইলটি খুঁজে পেতে, প্রথমে
নিচে দেখানো make কমান্ডটি রান করে কনফিগারেশনটি তৈরি করুন।
$ m VtsHalUsbV1_1TargetTest
আপনার বিল্ড-আউট ডিরেক্টরিতে, আপনি মডিউলের নামের উপর ভিত্তি করে config ফাইল সার্চ করতে পারবেন, যেমনটি নিচে দেখানো হয়েছে।
$ find out/ -name VtsHalUsbV1_1TargetTest.config
ফাইলের একাধিক কপি থাকতে পারে এবং আপনি যেকোনও একটি ব্যবহার করতে পারেন।
Android.bp ফাইলটি যে ডিরেক্টরিতে আছে
সেখানে .config ফাইলটি কপি করুন।
Android.bp ফাইলে শুধুমাত্র একটি টেস্ট মডিউল থাকলে, আপনি
XML ফাইলের নাম পরিবর্তন করে AndroidTest.xml করতে পারেন এবং বিল্ড সিস্টেম অটোমেটিক
সেটিকে টেস্ট মডিউলের কনফিগারেশন ফাইল হিসেবে ব্যবহার করে। অন্যথায়,
নিচের উদাহরণে দেখানো
মতো মডিউলে একটি test_config অ্যাট্রিবিউট যোগ করুন।
test_config: "VtsHalUsbV1_1TargetTest.xml",
এখন আপনার কাছে কাজ করার জন্য এবং কাস্টমাইজেশন প্রয়োগ করার জন্য একটি টেস্ট কনফিগারেশন ফাইল রয়েছে।
adb রুট সহ টেস্ট চালানোর জন্য বাধ্য করুন
অধিকাংশ VTS টেস্ট চালানোর জন্য রুট প্রিভিলেজ প্রয়োজন। টেস্ট কনফিগারেশন ফাইল
অটোমেটিক তৈরি হলে, আপনি Android.bp-এ নিম্নলিখিত অ্যাট্রিবিউট যোগ করতে পারবেন।
require_root: true,
টেস্ট কনফিগারেশন ফাইল কাস্টমাইজ করা হলে, টেস্ট XML ফাইলে নিচে উল্লেখ করা তথ্য যোগ করুন।
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
পরীক্ষা চলাকালীন ফ্রেমওয়ার্ক বন্ধ করুন
অনেক VTS টেস্ট চালানোর জন্য Android ফ্রেমওয়ার্কের প্রয়োজন হয় না এবং ফ্রেমওয়ার্ক বন্ধ করে টেস্ট চালালে, ডিভাইস ফ্লেক দ্বারা প্রভাবিত না হয়ে টেস্টটি স্থিতিশীলভাবে চালানো যায়। টেস্ট কনফিগারেশন ফাইল
অটোমেটিক তৈরি হলে, আপনি Android.bp-এ নিম্নলিখিত অ্যাট্রিবিউট যোগ করতে পারবেন।
disable_framework: true,
টেস্ট কনফিগারেশন ফাইল কাস্টমাইজ করা হলে, টেস্ট XML ফাইলে নিচে দেওয়া তথ্য যোগ করুন।
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
অতিরিক্ত টেস্ট আর্গুমেন্ট যোগ করুন
কিছু gtest টেস্ট চালানোর জন্য আরও বেশি সময় লাগতে পারে। এই ধরনের ক্ষেত্রে, আপনি XML ফাইলে টেস্ট রানার বিকল্প যোগ করতে পারেন।
যেমন, নিম্নলিখিত এন্ট্রিতে native-test-timeout সেটিং ডিফল্ট ১ মিনিটের পরিবর্তে ৩ মিনিটের টাইমআউট সহ টেস্ট চালানোর অনুমতি দেয়।
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
ন্যূনতম API লেভেল প্রয়োজন
কিছু VTS পরীক্ষা শুধুমাত্র ন্যূনতম API লেভেল সহ ডিভাইসে চালানো যেতে পারে। টেস্ট কনফিগারেশন ফাইল অটোমেটিক তৈরি হলে, আপনি Android.bp-এ নিম্নলিখিত
অ্যাট্রিবিউট যোগ করতে পারবেন।
min_shipping_api_level: 29,
অথবা
vsr_min_shipping_api_level: 202404,
টেস্ট কনফিগারেশন ফাইল কাস্টমাইজ করা হলে, টেস্ট XML ফাইলে নিম্নলিখিত কমান্ড যোগ করুন।
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
অথবা
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
API লেভেল প্রপার্টি
Android 12-এ ro.board.first_api_level এবং
ro.board.api_level প্রপার্টি সংজ্ঞায়িত করা আছে যাতে এই ডিভাইসগুলিতে ভেন্ডর ইমেজের API লেভেল দেখানো যায়। ro.product.first_api_level-এর সাথে এইসব প্রপার্টি মিলিয়ে,
ডিভাইসের জন্য সঠিক টেস্ট কেস বেছে নেয় টেস্ট স্যুট।
Android 13, ro.vendor.api_level-কে সংজ্ঞায়িত করে যা
ro.product.first_api_level, ro.board.first_api_level এবং
ro.board.api_level প্রপার্টি ব্যবহার করে প্রয়োজনীয় ভেন্ডর API লেভেল গণনা করে
অটোমেটিক সেট করা হয়।
আরও বিবরণের জন্য, Vendor API লেভেল দেখুন।
ro.board.first_api_level
ro.board.first_api_level প্রপার্টি হল API লেভেল যখন SoC-এর জন্য ভেন্ডর ছবি
যা ভেন্ডর ফ্রিজের জন্য উপযুক্ত
সেগুলি এই প্রপার্টির সাথে প্রথম
রিলিজ করা হয়। এটি ডিভাইসের লঞ্চিং API লেভেলের উপর নির্ভর করে না,
বরং SoC-এর প্রথম API লেভেলের উপর নির্ভর করে যা এই ভ্যালু নির্ধারণ করে। SoC-এর লাইফটাইমের জন্য
ভ্যালু স্থায়ী হয়।
ro.board.first_api_level সেট করতে, ডিভাইস প্রস্তুতকারক তাদের device.mk ফাইলে
BOARD_SHIPPING_API_LEVEL সংজ্ঞায়িত করতে পারেন, যেমনটি নিম্নলিখিত
উদাহরণে দেখানো হয়েছে:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
এটি ডিভাইসে ro.board.first_api_level প্রপার্টিকে অটোমেটিক
vendor/build.prop হিসেবে সংজ্ঞায়িত করবে। ভেন্ডর init
প্রসেস দ্বারা প্রপার্টি সেট করা হয়।
ro.board.api_level
ro.board.api_level প্রপার্টি হল ভেন্ডর API-এর বর্তমান ভেন্ডর API লেভেল
ইমেজ, যেটির YYYYMM ফর্ম্যাটে ভেন্ডর API ফ্রিজ করা হয়েছে। এটি
বিল্ড সিস্টেমের মাধ্যমে অটোমেটিক সেট করা হয়।
ro.vendor.api_level
ভেন্ডর ইমেজকে
কোন API লেভেলে কাজ করতে হবে তা দেখানোর জন্য
Android 13-এ ro.vendor.api_level প্রপার্টি চালু করা হয়েছে। এটি অটোমেটিক
ro.product.first_api_level-এ সেট করা হয়, অথবা ro.board.api_level-এ সেট করা হয় যদি
ro.board.first_api_level থাকে এবং ro.board.api_level-কে ro.product.first_api_level-এর থেকে
আগের API লেভেলে সেট করা হয়। ro.product.first_api_level থেকে ভার্সন
সেট করা থাকলে, ভার্সনটি
সংশ্লিষ্ট ভেন্ডর API লেভেল দিয়ে পরিবর্তন করা হবে, যা 35-এর সমান বা তার চেয়ে বেশি। এই প্রপার্টি উল্লেখ করে, SoC-এর জন্য ভেন্ডর সংক্রান্ত প্রয়োজনীয়তা থেকে ভেন্ডর ইমেজ আপগ্রেড
প্রয়োজনীয় ভেন্ডর ইমপ্লিমেন্টেশনের
টেস্ট বাদ দেওয়া হতে পারে।
VTS ব্যবহার করে শার্ডিং প্রসেস
Android ভার্সন 10 বা তার পরবর্তী ভার্সনের জন্য, আপনি নিচের নির্দেশাবলী অনুসরণ করে VTS এবং CTS-on-GSI প্ল্যান দুটির মাধ্যমে পরীক্ষা করার সময় একাধিক ডিভাইসে শার্ডিং প্রক্রিয়া সম্পাদন করতে পারেন।
run vts --shard-count <number of devices> -s <device serial> ...
এই কমান্ড VTS প্ল্যানকে শার্ডে বিভক্ত করে এবং একাধিক ডিভাইসে সেগুলি রান করে।
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
এই কমান্ড CTS-on-GSI প্ল্যানকে শার্ডে ভাগ করে এবং একাধিক ডিভাইসে সেগুলি রান করে।