প্রতিটি নতুন টেস্ট মডিউলের অবশ্যই একটি কনফিগারেশন ফাইল থাকতে হবে যাতে মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে নির্দেশিত করা যায়। Android এখন সহজ পরীক্ষা কনফিগারেশনের জন্য Soong বিল্ড সিস্টেম ব্যবহার করে।
Soong ব্লুপ্রিন্ট বা .bp ফাইলগুলি ব্যবহার করে, যেগুলি তৈরি করতে মডিউলগুলির JSON-এর মতো সহজ ঘোষণামূলক বিবরণ৷ এই বিন্যাসটি পূর্ববর্তী রিলিজে ব্যবহৃত মেক-ভিত্তিক সিস্টেমকে প্রতিস্থাপন করে। সম্পূর্ণ বিশদ বিবরণের জন্য কন্টিনিউয়াস ইন্টিগ্রেশন ড্যাশবোর্ডে সুং রেফারেন্স ফাইলগুলি দেখুন।
কাস্টম টেস্টিং সামঞ্জস্য করতে বা Android সামঞ্জস্য পরীক্ষা স্যুট (CTS) ব্যবহার করতে, পরিবর্তে জটিল পরীক্ষা কনফিগারেশন অনুসরণ করুন।
উদাহরণ
নীচের এন্ট্রিগুলি এই উদাহরণ ব্লুপ্রিন্ট কনফিগারেশন ফাইল থেকে এসেছে: /platform_testing/tests/example/instrumentation/Android.bp
সুবিধার জন্য এখানে একটি স্ন্যাপশট অন্তর্ভুক্ত করা হয়েছে:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
লক্ষ্য করুন শুরুতে android_test ঘোষণাটি নির্দেশ করে যে এটি একটি পরীক্ষা। android_app সহ এটি বিপরীতভাবে নির্দেশ করবে এটি একটি বিল্ড প্যাকেজ।
সেটিংস
নিম্নলিখিত সেটিংস গারনার ব্যাখ্যা:
name: "HelloWorldTests",
android_test মডিউল টাইপ নির্দিষ্ট করা হলে name সেটিং প্রয়োজন হয় (ব্লকের শুরুতে)। এটি আপনার মডিউলের একটি নাম দেয়, এবং ফলস্বরূপ APK-এর নাম একই এবং একটি .apk প্রত্যয় সহ হবে, যেমন এই ক্ষেত্রে, ফলাফলের পরীক্ষার apk-এর নাম দেওয়া হয়েছে HelloWorldTests.apk । উপরন্তু, এটি আপনার মডিউলের জন্য একটি মেক টার্গেট নামও সংজ্ঞায়িত করে, যাতে আপনি আপনার পরীক্ষার মডিউল এবং এর সমস্ত নির্ভরতা তৈরি করতে make [options] <HelloWorldTests> ব্যবহার করতে পারেন।
static_libs: ["androidx.test.runner"],
static_libs সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় যে নামকৃত মডিউলের বিষয়বস্তু বর্তমান মডিউলের apk-এ অন্তর্ভুক্ত করতে। এর মানে হল যে প্রতিটি নামযুক্ত মডিউল একটি .jar ফাইল তৈরি করবে বলে আশা করা হচ্ছে, এবং এর বিষয়বস্তু কম্পাইলের সময় ক্লাসপাথ রেফারেন্সগুলি সমাধান করার জন্য ব্যবহার করা হবে, সেইসাথে ফলাফল apk-এ অন্তর্ভুক্ত করা হবে।
androidx.test.runner মডিউলটি AndroidX টেস্ট রানার লাইব্রেরির জন্য প্রি-বিল্ট, যার মধ্যে রয়েছে টেস্ট রানার AndroidJUnitRunner । AndroidJUnitRunner JUnit4 টেস্টিং ফ্রেমওয়ার্ককে সমর্থন করে এবং Android 10-এ InstrumentationTestRunner প্রতিস্থাপিত করেছে । Android-এ টেস্ট অ্যাপে Android অ্যাপ পরীক্ষা করার বিষয়ে আরও পড়ুন।
আপনি যদি একটি নতুন ইন্সট্রুমেন্টেশন মডিউল তৈরি করেন, তাহলে আপনার টেস্ট রানার হিসেবে সবসময় androidx.test.runner লাইব্রেরি দিয়ে শুরু করা উচিত। প্ল্যাটফর্ম সোর্স ট্রিতে অন্যান্য দরকারী টেস্টিং ফ্রেমওয়ার্ক যেমন ub-uiautomator , mockito-target , easymock এবং আরও অনেক কিছু অন্তর্ভুক্ত রয়েছে।
certificate: "platform",
certificate সেটিং বিল্ড সিস্টেমকে মূল প্ল্যাটফর্মের মতো একই শংসাপত্রের সাথে apk-এ স্বাক্ষর করার নির্দেশ দেয়৷ আপনার পরীক্ষা যদি একটি স্বাক্ষর সুরক্ষিত অনুমতি বা API ব্যবহার করে তাহলে এটি প্রয়োজন। মনে রাখবেন যে এটি প্ল্যাটফর্ম ক্রমাগত পরীক্ষার জন্য উপযুক্ত, কিন্তু CTS পরীক্ষা মডিউলগুলিতে ব্যবহার করা উচিত নয় । মনে রাখবেন যে এই উদাহরণটি শুধুমাত্র চিত্রের উদ্দেশ্যে এই শংসাপত্র সেটিং ব্যবহার করে: উদাহরণের পরীক্ষার কোডটি আসলে বিশেষ প্ল্যাটফর্ম শংসাপত্রের সাথে পরীক্ষার apk স্বাক্ষর করার প্রয়োজন নেই৷
আপনি যদি সিস্টেম সার্ভারের বাইরে থাকা আপনার উপাদানের জন্য একটি ইন্সট্রুমেন্টেশন লিখছেন, অর্থাৎ, এটি একটি নিয়মিত অ্যাপ apk-এর মতো কমবেশি প্যাকেজ করা হয়, তবে এটি সিস্টেম ইমেজে অন্তর্নির্মিত এবং একটি বিশেষ সুবিধাপ্রাপ্ত অ্যাপ হতে পারে, সম্ভাবনা রয়েছে যে আপনার ইনস্ট্রুমেন্টেশন আপনার উপাদানের অ্যাপ প্যাকেজ (মেনিফেস্ট সম্পর্কে নীচের বিভাগটি দেখুন) লক্ষ্য করা হচ্ছে। এই ক্ষেত্রে, আপনার অ্যাপ্লিকেশন মেকফাইলের নিজস্ব certificate সেটিং থাকতে পারে এবং আপনার ইন্সট্রুমেন্টেশন মডিউলের একই সেটিং বজায় রাখা উচিত। এর কারণ হল পরীক্ষার অধীনে অ্যাপে আপনার ইন্সট্রুমেন্টেশন টার্গেট করতে, আপনার টেস্ট apk এবং app apk একই শংসাপত্রের সাথে স্বাক্ষরিত হতে হবে।
অন্যান্য ক্ষেত্রে, আপনার এই সেটিংটি থাকা দরকার নেই: বিল্ড সিস্টেমটি কেবল বিল্ড বৈকল্পিকের উপর ভিত্তি করে একটি ডিফল্ট অন্তর্নির্মিত শংসাপত্র দিয়ে স্বাক্ষর করবে এবং এটিকে সাধারণত dev-keys বলা হয়।
test_suites: ["device-tests"],
test_suites সেটিং ট্রেড ফেডারেশন পরীক্ষার জোতা দ্বারা পরীক্ষাটিকে সহজেই আবিষ্কারযোগ্য করে তোলে। অন্যান্য স্যুটগুলি এখানে যোগ করা যেতে পারে যেমন CTS যাতে এই পরীক্ষাটি ভাগ করা যায়।
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
ঐচ্ছিক সেটিংস
নিম্নলিখিত ঐচ্ছিক সেটিংস গারনার ব্যাখ্যা:
test_config: "path/to/hello_world_test.xml"
test_config সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় আপনার টেস্ট টার্গেটের জন্য একটি নির্দিষ্ট কনফিগারেশন প্রয়োজন। ডিফল্টরূপে, Android.bp পাশে একটি AndroidTest.xml কনফিগারেশনের সাথে যুক্ত।
auto_gen_config: true
auto_gen_config সেটিং স্বয়ংক্রিয়ভাবে পরীক্ষা কনফিগার তৈরি করবে কি না তা নির্দেশ করে। Android.bp এর পাশে AndroidTest.xml না থাকলে, এই অ্যাট্রিবিউটটিকে স্পষ্টভাবে সত্যে সেট করার প্রয়োজন নেই।
require_root: true
require_root সেটিং বিল্ড সিস্টেমকে স্বয়ংক্রিয় উৎপন্ন পরীক্ষা কনফিগারে RootTargetPreparer যোগ করার নির্দেশ দেয়। এটি রুট অনুমতির সাথে পরীক্ষা চালানোর নিশ্চয়তা দেয়।
test_min_api_level: 29
test_min_api_level সেটিং স্বয়ংক্রিয়ভাবে তৈরি পরীক্ষা কনফিগারে MinApiLevelModuleController যোগ করার জন্য বিল্ড সিস্টেমকে নির্দেশ দেয়। যখন ট্রেড ফেডারেশন পরীক্ষা কনফিগার চালায়, তখন ro.product.first_api_level < test_min_api_level এর ডিভাইসের বৈশিষ্ট্য থাকলে পরীক্ষাটি এড়িয়ে যাবে।
প্রতিটি নতুন টেস্ট মডিউলের অবশ্যই একটি কনফিগারেশন ফাইল থাকতে হবে যাতে মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে নির্দেশিত করা যায়। Android এখন সহজ পরীক্ষা কনফিগারেশনের জন্য Soong বিল্ড সিস্টেম ব্যবহার করে।
Soong ব্লুপ্রিন্ট বা .bp ফাইলগুলি ব্যবহার করে, যেগুলি তৈরি করতে মডিউলগুলির JSON-এর মতো সহজ ঘোষণামূলক বিবরণ৷ এই বিন্যাসটি পূর্ববর্তী রিলিজে ব্যবহৃত মেক-ভিত্তিক সিস্টেমকে প্রতিস্থাপন করে। সম্পূর্ণ বিশদ বিবরণের জন্য কন্টিনিউয়াস ইন্টিগ্রেশন ড্যাশবোর্ডে সুং রেফারেন্স ফাইলগুলি দেখুন।
কাস্টম টেস্টিং সামঞ্জস্য করতে বা Android সামঞ্জস্য পরীক্ষা স্যুট (CTS) ব্যবহার করতে, পরিবর্তে জটিল পরীক্ষা কনফিগারেশন অনুসরণ করুন।
উদাহরণ
নীচের এন্ট্রিগুলি এই উদাহরণ ব্লুপ্রিন্ট কনফিগারেশন ফাইল থেকে এসেছে: /platform_testing/tests/example/instrumentation/Android.bp
সুবিধার জন্য এখানে একটি স্ন্যাপশট অন্তর্ভুক্ত করা হয়েছে:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
লক্ষ্য করুন শুরুতে android_test ঘোষণাটি নির্দেশ করে যে এটি একটি পরীক্ষা। android_app সহ এটি বিপরীতভাবে নির্দেশ করবে এটি একটি বিল্ড প্যাকেজ।
সেটিংস
নিম্নলিখিত সেটিংস গারনার ব্যাখ্যা:
name: "HelloWorldTests",
android_test মডিউল টাইপ নির্দিষ্ট করা হলে name সেটিং প্রয়োজন হয় (ব্লকের শুরুতে)। এটি আপনার মডিউলের একটি নাম দেয়, এবং ফলস্বরূপ APK-এর নাম একই এবং একটি .apk প্রত্যয় সহ হবে, যেমন এই ক্ষেত্রে, ফলাফলের পরীক্ষার apk-এর নাম দেওয়া হয়েছে HelloWorldTests.apk । উপরন্তু, এটি আপনার মডিউলের জন্য একটি মেক টার্গেট নামও সংজ্ঞায়িত করে, যাতে আপনি আপনার পরীক্ষার মডিউল এবং এর সমস্ত নির্ভরতা তৈরি করতে make [options] <HelloWorldTests> ব্যবহার করতে পারেন।
static_libs: ["androidx.test.runner"],
static_libs সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় যে নামকৃত মডিউলের বিষয়বস্তু বর্তমান মডিউলের apk-এ অন্তর্ভুক্ত করতে। এর মানে হল যে প্রতিটি নামযুক্ত মডিউল একটি .jar ফাইল তৈরি করবে বলে আশা করা হচ্ছে, এবং এর বিষয়বস্তু কম্পাইলের সময় ক্লাসপাথ রেফারেন্সগুলি সমাধান করার জন্য ব্যবহার করা হবে, সেইসাথে ফলাফল apk-এ অন্তর্ভুক্ত করা হবে।
androidx.test.runner মডিউলটি AndroidX টেস্ট রানার লাইব্রেরির জন্য প্রি-বিল্ট, যার মধ্যে রয়েছে টেস্ট রানার AndroidJUnitRunner । AndroidJUnitRunner JUnit4 টেস্টিং ফ্রেমওয়ার্ককে সমর্থন করে এবং Android 10-এ InstrumentationTestRunner প্রতিস্থাপিত করেছে । Android-এ টেস্ট অ্যাপে Android অ্যাপ পরীক্ষা করার বিষয়ে আরও পড়ুন।
আপনি যদি একটি নতুন ইন্সট্রুমেন্টেশন মডিউল তৈরি করেন, তাহলে আপনার টেস্ট রানার হিসেবে সবসময় androidx.test.runner লাইব্রেরি দিয়ে শুরু করা উচিত। প্ল্যাটফর্ম সোর্স ট্রিতে অন্যান্য দরকারী টেস্টিং ফ্রেমওয়ার্ক যেমন ub-uiautomator , mockito-target , easymock এবং আরও অনেক কিছু অন্তর্ভুক্ত রয়েছে।
certificate: "platform",
certificate সেটিং বিল্ড সিস্টেমকে মূল প্ল্যাটফর্মের মতো একই শংসাপত্রের সাথে apk-এ স্বাক্ষর করার নির্দেশ দেয়৷ আপনার পরীক্ষা যদি একটি স্বাক্ষর সুরক্ষিত অনুমতি বা API ব্যবহার করে তাহলে এটি প্রয়োজন। মনে রাখবেন যে এটি প্ল্যাটফর্ম ক্রমাগত পরীক্ষার জন্য উপযুক্ত, কিন্তু CTS পরীক্ষা মডিউলগুলিতে ব্যবহার করা উচিত নয় । মনে রাখবেন যে এই উদাহরণটি শুধুমাত্র চিত্রের উদ্দেশ্যে এই শংসাপত্র সেটিং ব্যবহার করে: উদাহরণের পরীক্ষার কোডটি আসলে বিশেষ প্ল্যাটফর্ম শংসাপত্রের সাথে পরীক্ষার apk স্বাক্ষর করার প্রয়োজন নেই৷
আপনি যদি সিস্টেম সার্ভারের বাইরে থাকা আপনার উপাদানের জন্য একটি ইন্সট্রুমেন্টেশন লিখছেন, অর্থাৎ, এটি একটি নিয়মিত অ্যাপ apk-এর মতো কমবেশি প্যাকেজ করা হয়, তবে এটি সিস্টেম ইমেজে অন্তর্নির্মিত এবং একটি বিশেষ সুবিধাপ্রাপ্ত অ্যাপ হতে পারে, সম্ভাবনা রয়েছে যে আপনার ইনস্ট্রুমেন্টেশন আপনার উপাদানের অ্যাপ প্যাকেজ (মেনিফেস্ট সম্পর্কে নীচের বিভাগটি দেখুন) লক্ষ্য করা হচ্ছে। এই ক্ষেত্রে, আপনার অ্যাপ্লিকেশন মেকফাইলের নিজস্ব certificate সেটিং থাকতে পারে এবং আপনার ইন্সট্রুমেন্টেশন মডিউলের একই সেটিং বজায় রাখা উচিত। এর কারণ হল পরীক্ষার অধীনে অ্যাপে আপনার ইন্সট্রুমেন্টেশন টার্গেট করতে, আপনার টেস্ট apk এবং app apk একই শংসাপত্রের সাথে স্বাক্ষরিত হতে হবে।
অন্যান্য ক্ষেত্রে, আপনার এই সেটিংটি থাকা দরকার নেই: বিল্ড সিস্টেমটি কেবল বিল্ড বৈকল্পিকের উপর ভিত্তি করে একটি ডিফল্ট অন্তর্নির্মিত শংসাপত্র দিয়ে স্বাক্ষর করবে এবং এটিকে সাধারণত dev-keys বলা হয়।
test_suites: ["device-tests"],
test_suites সেটিং ট্রেড ফেডারেশন পরীক্ষার জোতা দ্বারা পরীক্ষাটিকে সহজেই আবিষ্কারযোগ্য করে তোলে। অন্যান্য স্যুটগুলি এখানে যোগ করা যেতে পারে যেমন CTS যাতে এই পরীক্ষাটি ভাগ করা যায়।
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
ঐচ্ছিক সেটিংস
নিম্নলিখিত ঐচ্ছিক সেটিংস গারনার ব্যাখ্যা:
test_config: "path/to/hello_world_test.xml"
test_config সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় আপনার টেস্ট টার্গেটের জন্য একটি নির্দিষ্ট কনফিগারেশন প্রয়োজন। ডিফল্টরূপে, Android.bp পাশে একটি AndroidTest.xml কনফিগারেশনের সাথে যুক্ত।
auto_gen_config: true
auto_gen_config সেটিং স্বয়ংক্রিয়ভাবে পরীক্ষা কনফিগার তৈরি করবে কি না তা নির্দেশ করে। Android.bp এর পাশে AndroidTest.xml না থাকলে, এই অ্যাট্রিবিউটটিকে স্পষ্টভাবে সত্যে সেট করার প্রয়োজন নেই।
require_root: true
require_root সেটিং বিল্ড সিস্টেমকে স্বয়ংক্রিয় উৎপন্ন পরীক্ষা কনফিগারে RootTargetPreparer যোগ করার নির্দেশ দেয়। এটি রুট অনুমতির সাথে পরীক্ষা চালানোর নিশ্চয়তা দেয়।
test_min_api_level: 29
test_min_api_level সেটিং স্বয়ংক্রিয়ভাবে তৈরি পরীক্ষা কনফিগারে MinApiLevelModuleController যোগ করার জন্য বিল্ড সিস্টেমকে নির্দেশ দেয়। যখন ট্রেড ফেডারেশন পরীক্ষা কনফিগার চালায়, তখন ro.product.first_api_level < test_min_api_level এর ডিভাইসের বৈশিষ্ট্য থাকলে পরীক্ষাটি এড়িয়ে যাবে।
প্রতিটি নতুন টেস্ট মডিউলের অবশ্যই একটি কনফিগারেশন ফাইল থাকতে হবে যাতে মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে নির্দেশিত করা যায়। Android এখন সহজ পরীক্ষা কনফিগারেশনের জন্য Soong বিল্ড সিস্টেম ব্যবহার করে।
Soong ব্লুপ্রিন্ট বা .bp ফাইলগুলি ব্যবহার করে, যেগুলি তৈরি করতে মডিউলগুলির JSON-এর মতো সহজ ঘোষণামূলক বিবরণ৷ এই বিন্যাসটি পূর্ববর্তী রিলিজে ব্যবহৃত মেক-ভিত্তিক সিস্টেমকে প্রতিস্থাপন করে। সম্পূর্ণ বিশদ বিবরণের জন্য কন্টিনিউয়াস ইন্টিগ্রেশন ড্যাশবোর্ডে সুং রেফারেন্স ফাইলগুলি দেখুন।
কাস্টম টেস্টিং সামঞ্জস্য করতে বা Android সামঞ্জস্য পরীক্ষা স্যুট (CTS) ব্যবহার করতে, পরিবর্তে জটিল পরীক্ষা কনফিগারেশন অনুসরণ করুন।
উদাহরণ
নীচের এন্ট্রিগুলি এই উদাহরণ ব্লুপ্রিন্ট কনফিগারেশন ফাইল থেকে এসেছে: /platform_testing/tests/example/instrumentation/Android.bp
সুবিধার জন্য এখানে একটি স্ন্যাপশট অন্তর্ভুক্ত করা হয়েছে:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
লক্ষ্য করুন শুরুতে android_test ঘোষণাটি নির্দেশ করে যে এটি একটি পরীক্ষা। android_app সহ এটি বিপরীতভাবে নির্দেশ করবে এটি একটি বিল্ড প্যাকেজ।
সেটিংস
নিম্নলিখিত সেটিংস গারনার ব্যাখ্যা:
name: "HelloWorldTests",
android_test মডিউল টাইপ নির্দিষ্ট করা হলে name সেটিং প্রয়োজন হয় (ব্লকের শুরুতে)। এটি আপনার মডিউলের একটি নাম দেয়, এবং ফলস্বরূপ APK-এর নাম একই এবং একটি .apk প্রত্যয় সহ হবে, যেমন এই ক্ষেত্রে, ফলাফলের পরীক্ষার apk-এর নাম দেওয়া হয়েছে HelloWorldTests.apk । উপরন্তু, এটি আপনার মডিউলের জন্য একটি মেক টার্গেট নামও সংজ্ঞায়িত করে, যাতে আপনি আপনার পরীক্ষার মডিউল এবং এর সমস্ত নির্ভরতা তৈরি করতে make [options] <HelloWorldTests> ব্যবহার করতে পারেন।
static_libs: ["androidx.test.runner"],
static_libs সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় যে নামকৃত মডিউলের বিষয়বস্তু বর্তমান মডিউলের apk-এ অন্তর্ভুক্ত করতে। এর মানে হল যে প্রতিটি নামযুক্ত মডিউল একটি .jar ফাইল তৈরি করবে বলে আশা করা হচ্ছে, এবং এর বিষয়বস্তু কম্পাইলের সময় ক্লাসপাথ রেফারেন্সগুলি সমাধান করার জন্য ব্যবহার করা হবে, সেইসাথে ফলাফল apk-এ অন্তর্ভুক্ত করা হবে।
androidx.test.runner মডিউলটি AndroidX টেস্ট রানার লাইব্রেরির জন্য প্রি-বিল্ট, যার মধ্যে রয়েছে টেস্ট রানার AndroidJUnitRunner । AndroidJUnitRunner JUnit4 টেস্টিং ফ্রেমওয়ার্ককে সমর্থন করে এবং Android 10-এ InstrumentationTestRunner প্রতিস্থাপিত করেছে । Android-এ টেস্ট অ্যাপে Android অ্যাপ পরীক্ষা করার বিষয়ে আরও পড়ুন।
আপনি যদি একটি নতুন ইন্সট্রুমেন্টেশন মডিউল তৈরি করেন, তাহলে আপনার টেস্ট রানার হিসেবে সবসময় androidx.test.runner লাইব্রেরি দিয়ে শুরু করা উচিত। প্ল্যাটফর্ম সোর্স ট্রিতে অন্যান্য দরকারী টেস্টিং ফ্রেমওয়ার্ক যেমন ub-uiautomator , mockito-target , easymock এবং আরও অনেক কিছু অন্তর্ভুক্ত রয়েছে।
certificate: "platform",
certificate সেটিং বিল্ড সিস্টেমকে মূল প্ল্যাটফর্মের মতো একই শংসাপত্রের সাথে apk-এ স্বাক্ষর করার নির্দেশ দেয়৷ আপনার পরীক্ষা যদি একটি স্বাক্ষর সুরক্ষিত অনুমতি বা API ব্যবহার করে তাহলে এটি প্রয়োজন। মনে রাখবেন যে এটি প্ল্যাটফর্ম ক্রমাগত পরীক্ষার জন্য উপযুক্ত, কিন্তু CTS পরীক্ষা মডিউলগুলিতে ব্যবহার করা উচিত নয় । মনে রাখবেন যে এই উদাহরণটি শুধুমাত্র চিত্রের উদ্দেশ্যে এই শংসাপত্র সেটিং ব্যবহার করে: উদাহরণের পরীক্ষার কোডটি আসলে বিশেষ প্ল্যাটফর্ম শংসাপত্রের সাথে পরীক্ষার apk স্বাক্ষর করার প্রয়োজন নেই৷
আপনি যদি সিস্টেম সার্ভারের বাইরে থাকা আপনার উপাদানের জন্য একটি ইন্সট্রুমেন্টেশন লিখছেন, অর্থাৎ, এটি একটি নিয়মিত অ্যাপ apk-এর মতো কমবেশি প্যাকেজ করা হয়, তবে এটি সিস্টেম ইমেজে অন্তর্নির্মিত এবং একটি বিশেষ সুবিধাপ্রাপ্ত অ্যাপ হতে পারে, সম্ভাবনা রয়েছে যে আপনার ইনস্ট্রুমেন্টেশন আপনার উপাদানের অ্যাপ প্যাকেজ (মেনিফেস্ট সম্পর্কে নীচের বিভাগটি দেখুন) লক্ষ্য করা হচ্ছে। এই ক্ষেত্রে, আপনার অ্যাপ্লিকেশন মেকফাইলের নিজস্ব certificate সেটিং থাকতে পারে এবং আপনার ইন্সট্রুমেন্টেশন মডিউলের একই সেটিং বজায় রাখা উচিত। এর কারণ হল পরীক্ষার অধীনে অ্যাপে আপনার ইন্সট্রুমেন্টেশন টার্গেট করতে, আপনার টেস্ট apk এবং app apk একই শংসাপত্রের সাথে স্বাক্ষরিত হতে হবে।
অন্যান্য ক্ষেত্রে, আপনার এই সেটিংটি থাকা দরকার নেই: বিল্ড সিস্টেমটি কেবল বিল্ড বৈকল্পিকের উপর ভিত্তি করে একটি ডিফল্ট অন্তর্নির্মিত শংসাপত্র দিয়ে স্বাক্ষর করবে এবং এটিকে সাধারণত dev-keys বলা হয়।
test_suites: ["device-tests"],
test_suites সেটিং ট্রেড ফেডারেশন পরীক্ষার জোতা দ্বারা পরীক্ষাটিকে সহজেই আবিষ্কারযোগ্য করে তোলে। অন্যান্য স্যুটগুলি এখানে যোগ করা যেতে পারে যেমন CTS যাতে এই পরীক্ষাটি ভাগ করা যায়।
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
ঐচ্ছিক সেটিংস
নিম্নলিখিত ঐচ্ছিক সেটিংস গারনার ব্যাখ্যা:
test_config: "path/to/hello_world_test.xml"
test_config সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় আপনার টেস্ট টার্গেটের জন্য একটি নির্দিষ্ট কনফিগারেশন প্রয়োজন। ডিফল্টরূপে, Android.bp পাশে একটি AndroidTest.xml কনফিগারেশনের সাথে যুক্ত।
auto_gen_config: true
auto_gen_config সেটিং স্বয়ংক্রিয়ভাবে পরীক্ষা কনফিগার তৈরি করবে কি না তা নির্দেশ করে। Android.bp এর পাশে AndroidTest.xml না থাকলে, এই অ্যাট্রিবিউটটিকে স্পষ্টভাবে সত্যে সেট করার প্রয়োজন নেই।
require_root: true
require_root সেটিং বিল্ড সিস্টেমকে স্বয়ংক্রিয় উৎপন্ন পরীক্ষা কনফিগারে RootTargetPreparer যোগ করার নির্দেশ দেয়। এটি রুট অনুমতির সাথে পরীক্ষা চালানোর নিশ্চয়তা দেয়।
test_min_api_level: 29
test_min_api_level সেটিং স্বয়ংক্রিয়ভাবে তৈরি পরীক্ষা কনফিগারে MinApiLevelModuleController যোগ করার জন্য বিল্ড সিস্টেমকে নির্দেশ দেয়। যখন ট্রেড ফেডারেশন পরীক্ষা কনফিগার চালায়, তখন ro.product.first_api_level < test_min_api_level এর ডিভাইসের বৈশিষ্ট্য থাকলে পরীক্ষাটি এড়িয়ে যাবে।