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

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

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

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

مثال

ورودی‌های زیر از این فایل پیکربندی 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 نشان می‌دهد که این یک بسته‌ی ساخت (build package) است.

تنظیمات

تنظیمات زیر توضیح مختصری ارائه می‌دهند:

    name: "HelloWorldTests",

تنظیم name زمانی الزامی است که نوع ماژول android_test (در ابتدای بلوک) مشخص شده باشد. این تنظیم به ماژول شما یک نام می‌دهد و APK حاصل نیز با همان نام و با پسوند .apk نامگذاری می‌شود، مثلاً در این مورد، apk تست حاصل HelloWorldTests.apk نامگذاری شده است. علاوه بر این، این تنظیم یک نام هدف make برای ماژول شما نیز تعریف می‌کند، به طوری که می‌توانید make [options] <HelloWorldTests> برای ساخت ماژول تست خود و تمام وابستگی‌های آن استفاده کنید.

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

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

ماژول androidx.test.runner ماژول از پیش ساخته شده برای کتابخانه AndroidX Test Runner است که شامل اجراکننده تست AndroidJUnitRunner می‌شود. AndroidJUnitRunner از چارچوب تست JUnit4 پشتیبانی می‌کند و در اندروید 10 جایگزین InstrumentationTestRunner شده است. برای اطلاعات بیشتر در مورد تست برنامه‌های اندروید، به Test apps on Android مراجعه کنید.

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

    certificate: "platform",

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

اگر در حال نوشتن ابزاری برای کامپوننت خود هستید که خارج از سرور سیستم قرار دارد، یعنی کم و بیش مانند یک apk برنامه معمولی بسته‌بندی شده است، با این تفاوت که در تصویر سیستم ساخته شده است و ممکن است یک برنامه ممتاز باشد، احتمال دارد که instrumentation شما بسته برنامه (به بخش زیر در مورد مانیفست مراجعه کنید) کامپوننت شما را هدف قرار دهد. در این حالت، ممکن است makefile برنامه شما تنظیمات certificate مخصوص به خود را داشته باشد و ماژول instrumentation شما باید همان تنظیمات را حفظ کند. دلیل این امر این است که برای هدف قرار دادن instrumentation خود در برنامه تحت آزمایش، 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 وجود نداشته باشد، نیازی نیست که این ویژگی به طور صریح روی true تنظیم شود.

    require_root: true

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

    test_min_api_level: 29

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