پیکربندی ساخت ساده

هر واحد آزمایشی جدید باید فایل پیکربندی داشته باشد تا سیستم ساخت را با فراداده واحد، وابستگی‌های زمان ترجمه، و دستورالعمل‌های بسته‌بندی هدایت کند. ‫Android اکنون از سیستم ساخت Soong برای پیکربندی ساده‌تر آزمایش استفاده می‌کند.

‫Soong از فایل‌های Blueprint یا .bp استفاده می‌کند که شرح‌های ساده بیانی شبیه به JSON از واحدهایی هستند که باید ساخته شوند. این قالب جایگزین سیستم مبتنی بر Make استفاده‌شده در نسخه‌های قبلی می‌شود. برای جزئیات کامل، فایل‌های مرجع Soong را در داشبورد یکپارچه‌سازی مداوم ببینید.

برای انجام آزمایش سفارشی یا استفاده از مجموعه آزمایش سازگاری (CTS) در Android، پیکربندی آزمایش پیچیده را دنبال کنید.

مثال

ورودی‌های زیر از این نمونه فایل پیکربندی Blueprint می‌آیند: /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 را برای ماژول شما تعریف می‌کند تا بتوانید از make [options] <HelloWorldTests> برای ساختن ماژول آزمایشی و همه وابستگی‌های آن استفاده کنید.

    static_libs: ["androidx.test.runner"],

تنظیم static_libs به سیستم ساخت دستور می‌دهد تا محتوای مدول‌های نام‌گذاری‌شده را در apk حاصل از مدول فعلی ادغام کند. این یعنی هر واحد نام‌گذاری‌شده باید فایل .jar تولید کند و از محتوای آن برای حل کردن ارجاع‌های مسیر کلاس در زمان ترجمه و همچنین برای ادغام در apk حاصل استفاده شود.

واحد androidx.test.runner ازپیش ساخته‌شده برای کتابخانه AndroidX Test Runner است که شامل آزمونگر AndroidJUnitRunner می‌شود. ‫AndroidJUnitRunner از چارچوب آزمایش JUnit4 پشتیبانی می‌کند و در Android 10 جایگزین InstrumentationTestRunner شد. درباره آزمایش کردن برنامه‌های Android در آزمایش کردن برنامه‌ها در Android بیشتر بخوانید.

اگر درحال ساختن واحد ابزار دقیق جدیدی هستید، همیشه باید با کتابخانه androidx.test.runner به‌عنوان اجراکننده آزمایشی شروع کنید. درخت منبع پلاتفرم همچنین شامل چارچوب‌های آزمایش مفید دیگری مثل ub-uiautomator، mockito-target،‏ easymock، و غیره می‌شود.

    certificate: "platform",

تنظیم certificate به سیستم ساخت دستور می‌دهد که apk را با همان گواهی پلاتفرم اصلی امضا کند. اگر آزمایش شما از اجازه یا API محافظت‌شده با امضا استفاده می‌کند، این کار لازم است. توجه داشته باشید که این روش برای آزمایش مداوم پلاتفرم مناسب است، اما نباید در ماژول‌های آزمایش CTS استفاده شود. توجه داشته باشید که این مثال از این تنظیم گواهینامه فقط برای هدف توضیح استفاده می‌کند: کد آزمایش مثال درواقع نیازی ندارد که apk آزمایش با گواهینامه پلاتفرم ویژه امضا شود.

اگر درحال نوشتن ابزار دقیق برای مؤلفه‌تان هستید که خارج از سرور سیستم قرار دارد، یعنی کم‌وبیش مانند یک APK برنامه معمولی بسته‌بندی شده است، به‌جز اینکه در تصویر سیستم ساخته شده است و ممکن است یک برنامه ممتاز باشد، احتمالاً ابزار دقیق شما بسته برنامه (بخش زیر درباره مانیفست را ببینید) مؤلفه‌تان را هدف قرار خواهد داد. در این مورد، فایل makefile برنامه شما ممکن است تنظیم certificate خاص خود را داشته باشد، و واحد ابزار دقیق شما باید همان تنظیم را حفظ کند. دلیل این است که برای هدف‌یابی ابزارهای برنامه تحت آزمایش، فایل apk آزمایشی و فایل 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 به سیستم ساخت دستور می‌دهد که هدف آزمایشی شما به پیکربندی خاصی نیاز دارد. به‌طور پیش‌فرض، AndroidTest.xml در کنار Android.bp با پیکربندی مرتبط است.

    auto_gen_config: true

تنظیم auto_gen_config نشان می‌دهد که پیکربندی آزمایش به‌طور خودکار ایجاد شود یا نه. اگر AndroidTest.xml در کنار Android.bp وجود ندارد، این ویژگی نیازی ندارد که به‌طور صریح روی درست تنظیم شود.

    require_root: true

تنظیم require_root به سیستم ساخت دستور می‌دهد که RootTargetPreparer را به پیکربندی آزمایش تولیدشده خودکار اضافه کند. این کار تضمین می‌کند که آزمایش با اجازه‌های ریشه اجرا شود.

    test_min_api_level: 29

تنظیم test_min_api_level به سیستم ساخت دستور می‌دهد MinApiLevelModuleController را به پیکربندی آزمایشی تولیدشده خودکار اضافه کند. وقتی Trade Federation پیکربندی آزمایش را اجرا می‌کند، اگر دارایی دستگاه ro.product.first_api_level < test_min_api_level باشد، آزمایش رد خواهد شد.