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

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

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

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

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

مثال

ورودی های زیر از این نمونه فایل پیکربندی Blueprint آمده است: /platform_testing/tests/example/instrumentation/Android.bp

یک عکس فوری برای راحتی در اینجا گنجانده شده است:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    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: ["android-support-test"],

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

در این مثال، مواردی که ممکن است به طور کلی برای تست ها مفید باشند:

android-support-test برای کتابخانه پشتیبانی تست Android از پیش ساخته شده است که شامل اجرای آزمایشی جدید AndroidJUnitRunner : جایگزینی برای InstrumentationTestRunner داخلی منسوخ شده با پشتیبانی از چارچوب آزمایشی JUnit4. در تست برنامه‌ها در Android بیشتر بخوانید.

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

    certificate: "platform",

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

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

    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 باشد، از آزمایش صرف‌نظر می‌شود.