تكوين البناء البسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء ببيانات وصفية للوحدة وتبعيات وقت التجميع وتعليمات الحزم. يستخدم Android الآن نظام بناء 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",

مطلوب إعداد name عند تحديد نوع الوحدة النمطية android_test (في بداية الكتلة). يعطي اسمًا للوحدة النمطية الخاصة بك ، وسيتم تسمية ملف 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 عادي ، باستثناء أنه مضمّن في صورة النظام وقد يكون تطبيقًا مميزًا ، فمن المحتمل أن تكون أجهزتك تستهدف حزمة التطبيق (انظر القسم أدناه حول البيان) لمكونك. في هذه الحالة ، قد يكون لملف التطبيق الخاص بك إعداد 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 بملف config.

    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 إلى تكوين الاختبار التلقائي. عندما يقوم الاتحاد التجاري بتشغيل التكوين التجريبي ، سيتم تخطي الاختبار إذا كانت خاصية الجهاز لـ ro.product.first_api_level < test_min_api_level .

و

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء ببيانات وصفية للوحدة وتبعيات وقت التجميع وتعليمات الحزم. يستخدم Android الآن نظام بناء 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",

مطلوب إعداد name عند تحديد نوع الوحدة النمطية android_test (في بداية الكتلة). يعطي اسمًا للوحدة النمطية الخاصة بك ، وسيتم تسمية ملف 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 عادي ، باستثناء أنه مضمّن في صورة النظام وقد يكون تطبيقًا مميزًا ، فمن المحتمل أن تكون أجهزتك تستهدف حزمة التطبيق (انظر القسم أدناه حول البيان) لمكونك. في هذه الحالة ، قد يكون لملف التطبيق الخاص بك إعداد 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 بملف config.

    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 إلى تكوين الاختبار التلقائي. عندما يقوم الاتحاد التجاري بتشغيل التكوين التجريبي ، سيتم تخطي الاختبار إذا كانت خاصية الجهاز لـ ro.product.first_api_level < test_min_api_level .

و

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء ببيانات وصفية للوحدة وتبعيات وقت التجميع وتعليمات الحزم. يستخدم Android الآن نظام بناء 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",

مطلوب إعداد name عند تحديد نوع الوحدة النمطية android_test (في بداية الكتلة). يعطي اسمًا للوحدة النمطية الخاصة بك ، وسيتم تسمية ملف 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 عادي ، باستثناء أنه مضمّن في صورة النظام وقد يكون تطبيقًا مميزًا ، فمن المحتمل أن تكون أجهزتك تستهدف حزمة التطبيق (انظر القسم أدناه حول البيان) لمكونك. في هذه الحالة ، قد يكون لملف التطبيق الخاص بك إعداد 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 بملف config.

    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 إلى تكوين الاختبار التلقائي. عندما يقوم الاتحاد التجاري بتشغيل التكوين التجريبي ، سيتم تخطي الاختبار إذا كانت خاصية الجهاز لـ ro.product.first_api_level < test_min_api_level .