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

هر ماژول آزمایشی جدید باید یک فایل پیکربندی برای هدایت سیستم ساخت با فراداده های ماژول، وابستگی های زمان کامپایل و دستورالعمل های بسته بندی داشته باشد. اندروید اکنون از سیستم ساخت 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: ["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 Test Runner Library است که شامل اجرای آزمایشی AndroidJUnitRunner است. AndroidJUnitRunner از چارچوب تست JUnit4 پشتیبانی می‌کند و جایگزین InstrumentationTestRunner در Android 10 شده است. درباره آزمایش برنامه‌های Android در Test apps در Android بیشتر بخوانید.

اگر در حال ساخت یک ماژول ابزار دقیق هستید، همیشه باید با کتابخانه androidx.test.runner به عنوان تست کننده شروع کنید. درخت منبع پلت فرم همچنین شامل سایر چارچوب‌های آزمایشی مفید مانند 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 باشد، از آزمایش صرف‌نظر می‌شود.

،

هر ماژول آزمایشی جدید باید یک فایل پیکربندی برای هدایت سیستم ساخت با فراداده های ماژول، وابستگی های زمان کامپایل و دستورالعمل های بسته بندی داشته باشد. اندروید اکنون از سیستم ساخت 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: ["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 Test Runner Library است که شامل اجرای آزمایشی AndroidJUnitRunner است. AndroidJUnitRunner از چارچوب تست JUnit4 پشتیبانی می‌کند و جایگزین InstrumentationTestRunner در Android 10 شده است. درباره آزمایش برنامه‌های Android در Test apps در Android بیشتر بخوانید.

اگر در حال ساخت یک ماژول ابزار دقیق هستید، همیشه باید با کتابخانه androidx.test.runner به عنوان تست کننده شروع کنید. درخت منبع پلت فرم همچنین شامل سایر چارچوب‌های آزمایشی مفید مانند 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 باشد، از آزمایش صرف‌نظر می‌شود.

،

هر ماژول آزمایشی جدید باید یک فایل پیکربندی برای هدایت سیستم ساخت با فراداده های ماژول، وابستگی های زمان کامپایل و دستورالعمل های بسته بندی داشته باشد. اندروید اکنون از سیستم ساخت 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: ["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 Test Runner Library است که شامل اجرای آزمایشی AndroidJUnitRunner است. AndroidJUnitRunner از چارچوب تست JUnit4 پشتیبانی می‌کند و جایگزین InstrumentationTestRunner در Android 10 شده است. درباره آزمایش برنامه‌های Android در Test apps در Android بیشتر بخوانید.

اگر در حال ساخت یک ماژول ابزار دقیق هستید، همیشه باید با کتابخانه androidx.test.runner به عنوان تست کننده شروع کنید. درخت منبع پلت فرم همچنین شامل سایر چارچوب‌های آزمایشی مفید مانند 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 باشد، از آزمایش صرف‌نظر می‌شود.