Android Studio Hedgehog | 2023.1.1 (تشرين الثاني/نوفمبر 2023)

في ما يلي الميزات الجديدة في Android Studio Hedgehog.

تحديث النظام الأساسي IntelliJ IDEA 2023.1

يتضمّن Android Studio Hedgehog تحديثات IntelliJ IDEA 2023.1 لتحسين تجربة Studio IDE. لمزيد من التفاصيل حول التغييرات، يمكنك الاطّلاع على ملاحظات إصدار IntelliJ IDEA 2023.1.

تحليل "مؤشرات Android الحيوية" في "إحصاءات جودة التطبيقات"

تتضمّن إحصاءات جودة التطبيقات الآن بيانات مؤشرات Android الحيوية، ما يتيح لك الوصول بسهولة أكبر إلى المقاييس الأساسية التي يجمعها Google Play وتحسين تجربة المستخدم. يمكنك استخدام "مؤشرات Android الحيوية" لمعالجة المشاكل المتعلقة بثبات التطبيق للمساعدة في تحسين جودة تطبيقك على Google Play.

يمكنك الاطّلاع على مشاكل "مؤشرات Android الحيوية" وفلترتها والانتقال من رمز تتبُّع تسلسل استدعاء الدوال البرمجية إلى ترميز كل ذلك من نافذة أداة إحصاءات جودة التطبيقات. للبدء، اتبع الخطوات التالية:

  1. سجِّل الدخول إلى حساب المطوّر في "استوديو Android" باستخدام رمز الملف الشخصي في نهاية شريط الأدوات.
  2. افتح إحصاءات جودة التطبيقات بالنقر على نافذة الأداة في "استوديو Android" أو النقر على عرض > نوافذ الأدوات > إحصاءات جودة التطبيقات.
  3. انقر على علامة التبويب مؤشرات Android الحيوية ضمن إحصاءات جودة التطبيقات.

اختلاف الأرقام بين "مؤشرات Android الحيوية" وCrashlytics

تجدر الإشارة إلى أنّ "مؤشرات Android الحيوية" وCrashlytics قد تُبلِغ عن قيم مختلفة لأعداد المستخدمين والأحداث المرتبطة بالعُطل نفسه. ويحدث هذا التناقض لأنّ Play وCrashlytics يمكنهما رصد الأعطال في أوقات مختلفة ولمختلف المستخدمين. في ما يلي سببان لاختلاف عدد حسابات Play وCrashlytics:

  • يرصد Play الأعطال بدءًا من وقت التشغيل، في حين أنّ Crashlytics يرصد الأعطال التي تحدث بعد إعداد حزمة تطوير البرامج Crashlytics SDK.
  • فإذا أوقف المستخدم ميزة إعداد تقارير الأعطال عند استخدام هاتف جديد، لا يتم إبلاغ Play بهذه الأعطال، إلا أنّ Crashlytics ترصد الأعطال بناءً على سياسة الخصوصية الخاصة بالتطبيق.

محلّل قوي جديد

بدءًا من Android Studio Hedgehog، يعرض تحليل Power Profiler استهلاك الطاقة على الأجهزة. يمكنك عرض هذه البيانات الجديدة في أداة مراقبة قضبان الطاقة على الجهاز (ODPM). يُقسِّم ODPM البيانات حسب أنظمة فرعية تسمى Power Rails. راجع قضبان القوة القابلة للإضافة للوضع الشخصي للحصول على قائمة بالأنظمة الفرعية المتوافقة.

يسجِّل System Trace بيانات استهلاك الطاقة وتعرضها. وهو جزء من محلل وحدة المعالجة المركزية. تساعدك هذه البيانات في الربط بصريًا بين استهلاك طاقة الجهاز والإجراءات التي تحدث في تطبيقك. ويمكّنك محلّل الطاقة من عرض هذه البيانات.

محلّل الطاقة الجديد

لعرض البيانات من أداة Power Profiler الجديدة، يمكنك تتبع النظام على جهاز Pixel 6 والإصدارات الأحدث:

  1. اختَر عرض > Windows الأداة > المحلل.
  2. انقر في أي مكان في المخطط الزمني لوحدة المعالجة المركزية لفتح محلّل وحدة المعالجة المركزية (CPU) وبدء عملية تتبُّع النظام.

يوفّر "مساعد روابط التطبيقات" الجديد نظرة عامة شاملة على الروابط المؤدية إلى صفحات في تطبيقك التي تم إعدادها في تطبيقك. يعرض "مساعد Google" جميع الروابط الحالية المؤدية إلى صفحات في التطبيق في ملف AndroidManifest.xml الخاص بالتطبيق، ويتحقق من صحة إعدادات هذه الروابط المؤدية إلى صفحات في التطبيق، ويوفر طريقة سريعة لإصلاح عمليات الضبط الخاطئة تلقائيًا.

لفتح مساعد روابط التطبيقات، انتقِل إلى الأدوات > مساعد روابط التطبيقات في "استوديو Android". لمزيد من المعلومات عن روابط التطبيقات، يُرجى الاطّلاع على مقالة إضافة روابط تطبيقات Android.

اختصار الوضع اليدوي المعدّل والمعدَّل للتعديل المباشر

يتضمّن خيار التعديل المباشر في Android studio Hedgehog اختصارًا جديدًا للوضع اليدوي (Push يدويًّا): Control+\ (Command+\ لنظام التشغيل macOS). يُعد الوضع اليدوي مفيدًا في المواقف التي تريد فيها التحكم بدقة في وقت نشر التحديثات في التطبيق قيد التشغيل. على سبيل المثال، إذا كنت تجري تغييرًا على نطاق واسع في ملف ولا تريد أن تنعكس أي حالة متوسطة على الجهاز. يمكنك الاختيار بين الدفع اليدوي والدفع يدويًا عند الحفظ في إعدادات التعديل المباشر أو باستخدام مؤشر واجهة المستخدم للتعديل المباشر. لمزيد من المعلومات، يمكنك الاطّلاع على مقطع الفيديو في التعديل المباشر لخدمة Jetpack Compose.

إنشاء نماذج معاينة متعددة

يقدّم الإصدار androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01 والإصدارات الأحدث نماذج جديدة من Multipreview API: "@PreviewScreenSizes" و"@PreviewFontScales" و"@PreviewLightDark" و"@PreviewDynamicColors"، بحيث يمكنك باستخدام تعليق توضيحي واحد معاينة واجهة مستخدم Compose في السيناريوهات الشائعة.

تم طرح وضع "معرض الصور" الجديد في Android Studio Hedgehog، وهو يتيح لك التركيز على معاينة واحدة في كل مرة وتوفير الموارد بشأن العرض. ننصحك باستخدام "وضع المعرض" عندما تحتاج إلى التكرار على واجهة مستخدم التطبيق والتبديل إلى أوضاع أخرى، على سبيل المثال، الشبكة أو القائمة، عندما تحتاج إلى رؤية متغيرات واجهة المستخدم.

إنشاء معلومات الحالة في برنامج تصحيح الأخطاء

عندما تتم إعادة إنشاء أجزاء من واجهة مستخدم Compose بشكل غير متوقّع، قد يصعب أحيانًا فهم السبب. عند ضبط نقطة إيقاف على دالة قابلة للإنشاء، يسرد برنامج تصحيح الأخطاء معلَمات العنصر القابل للإنشاء وحالته، حتى تتمكن بسهولة أكبر من تحديد التغييرات التي قد تكون أدّت إلى إعادة الإنشاء. على سبيل المثال، عند التوقّف مؤقتًا على عنصر قابل للإنشاء، يمكن لبرنامج تصحيح الأخطاء أن يخبرك بدقة بالمعلَمات التي "تم تغييرها" أو التي ظلت "لم يتم تغييرها"، كي تتمكّن من التحقيق بشكل أكثر فعالية في سبب إعادة التركيب.

النسخ المطابق للجهاز

يمكنك الآن إجراء نسخ مطابق لجهازك في نافذة الأجهزة قيد التشغيل في "استوديو Android". من خلال بث شاشة جهازك مباشرةً إلى "استوديو Android"، يمكنك تنفيذ الإجراءات الشائعة مثل بدء تشغيل التطبيقات والتفاعل معها، وتدوير الشاشة، وطي الهاتف وفتحه، وتغيير مستوى الصوت، وتنفيذ إجراءات أخرى من Studio IDE نفسه.

تتوفّر ميزة النسخ المطابق للجهاز دائمًا عندما تكون هناك أجهزة متصلة بالكمبيوتر وتم فيها تفعيل USB أو ميزة "تصحيح الأخطاء اللاسلكي". يمكنك بدء النسخ المطابق وإيقافه باستخدام نافذة الأجهزة قيد التشغيل أو مدير الجهاز (عرض > نظام التشغيل Windows > مدير الجهاز). ويمكنك أيضًا تخصيص وقت تفعيل النسخ المطابق للجهاز من خلال إعدادات الجهاز (الإعدادات > الأدوات > النسخ المطابق للجهاز).

واجهة مستخدم الأجهزة قيد التشغيل

المشاكل المعروفة

قد لا يكون بالإمكان ترميز بعض الأجهزة بمعدل نقل بيانات يكفي لإتاحة النسخ المطابق للجهاز. في هذه الحالات، قد تظهر لك رسالة خطأ في نافذة الأجهزة قيد التشغيل بالإضافة إلى السجلات المماثلة لما هو معروض أدناه.

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

إشعار الخصوصية

استنادًا إلى إعدادات النسخ المطابق للجهاز، يمكن لـ "استوديو Android" بدء النسخ المطابق للجهاز تلقائيًا على أي جهاز متصل أو مقترِن. قد يؤدي ذلك إلى الإفصاح عن المعلومات للأجهزة المرتبطة بالأمر adb tcpip لأنّ معلومات وأوامر النسخ المطابق يتم تمريرها عبر قناة غير مشفَّرة. بالإضافة إلى ذلك، يستخدم "استوديو Android" قناة غير مشفرة للتواصل مع خادم Adb، وبالتالي يمكن للمستخدمين الآخرين اعتراض المعلومات المتطابقة على جهازك المضيف.

إعادة توجيه إدخال الجهاز

يمكنك الآن تفعيل ميزة إعادة التوجيه الشفافة لمدخلات أجهزة محطة العمل، مثل الماوس ولوحة المفاتيح، إلى جهاز فعلي وافتراضي متصل. لتفعيل إعادة التوجيه الشفافة، انقر على إدخال الأجهزة للجهاز المستهدف في نافذة الأجهزة قيد التشغيل.

إدارة الأجهزة مباشرةً من نافذة الأجهزة قيد التشغيل

يمكنك الآن تشغيل جهاز Android افتراضي (AVD)، أو بدء النسخ المطابق لجهاز فعلي، وذلك مباشرةً من نافذة الأجهزة قيد التشغيل من خلال النقر على الرمز + واختيار جهاز. لإيقاف تشغيل AVD أو النسخ المطابق لجهاز فعلي، أغلِق علامة تبويب الجهاز.

القائمة المنسدلة "الجهاز" من قسم "الأجهزة قيد التشغيل"

أداة فحص التنسيق المضمَّن

بدءًا من Android Studio Hedgehog Canary 2، يمكنك تشغيل أداة فحص التنسيق مباشرةً في نافذة أداة تشغيل الأجهزة. تحافظ هذه الميزة التجريبية على مساحة الشاشة الفعلية وتساعد في تنظيم سير عمل تصحيح أخطاء واجهة المستخدم في نافذة أداة واحدة. في الوضع المضمّن، يمكنك إظهار تسلسل هرمي لطريقة العرض وفحص خصائص كل طريقة عرض والوصول إلى الميزات الشائعة الأخرى في "أداة فحص التصميم". وللوصول إلى المجموعة الكاملة من الخيارات، لا تزال بحاجة إلى تشغيل "أداة فحص التنسيق" في نافذة مستقلة (ملف > إعدادات > تجريبية > أداة فحص التنسيق على Windows أو استوديو Android > الإعدادات > تجريبية > أداة فحص التنسيق على نظام التشغيل macOS).

وهناك قيود على أداة فحص التنسيق المضمّنة، وهي أنّ الوضع الثلاثي الأبعاد لا يتوفّر إلا في اللقطات.

لمساعدتنا في تحسين "أداة فحص التنسيق" المضمّنة، يُرجى إرسال ملاحظاتك إلينا.

تحسينات جديدة على واجهة المستخدم

تمنح واجهة المستخدم الجديدة في "استوديو Android" مظهرًا ومضمونًا أكثر حداثة وأنظف إلى بيئة تطوير البرامج "استوديو". لقد استمعنا إلى ملاحظاتك حتى الآن وأصلحنا المشاكل المتعلّقة بالميزات التالية في Android Studio Hedgehog:

  • الوضع المكثّف
  • دعم التقسيم عموديًا أو أفقيًا
  • علامات تبويب المشاريع على نظام التشغيل macOS
  • إصلاحات في وضع عدم تشتيت الانتباه
  • الإعدادات المتقدمة لعرض إجراءات نافذة الأداة دائمًا

تحديثات "مساعد ترقية حزم تطوير البرامج"

يوفّر مساعد ترقية حزمة تطوير البرامج (SDK) خطوات مفصّلة للمعالج لمساعدتك في عمليات الترقية التي تخصّ targetSdkVersion. في ما يلي التحديثات التي أُجريت على "مساعد ترقية حزم تطوير البرامج" في Android Studio Hedgehog:

  • الاطّلاع على تغييرات قد تؤدي إلى الترقية إلى Android 14
  • تمت إضافة فلاتر لمدى الصلة بالموضوع، وبالتالي تمت إزالة بعض الخطوات غير الضرورية.
  • لإجراء تغييرات معيّنة، يجب تحديد موضع إجراء التغييرات بالضبط في الرمز البرمجي

إيقاف تحسين الإصدار لمستوى واجهة برمجة التطبيقات المستهدَف فقط

يمكنك الآن إيقاف تحسين IDE لمستوى واجهة برمجة التطبيقات للجهاز المستهدَف. يقلل "استوديو Android" تلقائيًا من وقت التصميم الإجمالي من خلال تخصيص عملية الفهرسة على مستوى واجهة برمجة التطبيقات للجهاز المستهدف الذي يتم النشر عليه. لإيقاف هذه الميزة، انتقِل إلى ملف > الإعدادات > تجريبية (استوديو Android > الإعدادات > تجريبية على نظام التشغيل macOS) وألغِ اختيار تحسين الإصدار لمستوى واجهة برمجة تطبيقات الجهاز المستهدف فقط. يُرجى العِلم أنّ إيقاف تحسين هذا الإصدار قد يؤدي إلى زيادة وقت الإصدار.

[نظام التشغيل Windows فقط] تقليل تأثير برامج مكافحة الفيروسات على سرعة الإصدار

تخبرك "أداة تحليل الإصدار" بما إذا كان برنامج مكافحة الفيروسات قد يؤثر في أداء الإصدار الخاص بك. قد يحدث هذا إذا كانت برامج مكافحة الفيروسات، مثل Windows Defender، تُجري فحصًا في الوقت الفعلي للأدلة التي يستخدمها Gradle. تقترح أداة تحليل الإصدارات قائمة بالأدلة المطلوب استبعادها من الفحص النشط، وتقدّم رابطًا لإضافتها إلى قائمة استبعاد مجلد Windows Defender إن أمكن.

لم تعُد مشاريع أداة تطوير Android Eclipse متاحة

لا يتيح Android Studio Hedgehog والإصدارات الأحدث استيراد مشاريع Eclipse ADT. لا يزال بإمكانك فتح هذه المشروعات، لكن لم تعد معترف بها كمشروعات Android. إذا كنت بحاجة إلى استيراد هذا النوع من المشاريع، يمكنك استخدام إصدار سابق من "استوديو Android". في حال تعذَّر على إصدار معيّن من "استوديو Android" استيراد مشروعك، يمكنك تجربة إصدار سابق. بعد تحويل المشروع إلى مشروع Android باستخدام إصدار سابق من "استوديو Android"، يمكنك استخدام "مساعد ترقية AGP" للعمل على هذا المشروع باستخدام أحدث إصدار من "استوديو Android".

استخدام أجهزة Firebase Test Lab مع الأجهزة المُدارة من خلال Gradle

وعند استخدام الإصدار AGP 8.2.0-alpha03 أو الإصدارات الأحدث، يمكنك إجراء اختبارات المعدات التلقائية على نطاق واسع على أجهزة مركز الاختبار الافتراضي لمنصة Firebase عند استخدام الأجهزة التي يديرها Gradle. يتيح لك مركز الاختبار الافتراضي إجراء الاختبارات في الوقت نفسه على مجموعة كبيرة من أجهزة Android، سواء المادية أو الافتراضية. ويتم إجراء هذه الاختبارات في مراكز بيانات Google البعيدة. وبفضل الدعم المقدَّم من أجهزة Gradle التي تديرها (GMD)، يمكن لنظام التصميم الآن إدارة الاختبارات بالكامل على أجهزة Test Lab هذه بناءً على الإعدادات في ملفات Gradle الخاصة بالمشروع.

بدء استخدام أجهزة Firebase Test Lab التي يديرها Gradle

توضِّح الخطوات التالية كيفية بدء استخدام أجهزة Firebase Test Lab مع GMD. تجدر الإشارة إلى أنّ هذه الخطوات تستخدم gcloud CLI لتوفير بيانات اعتماد المستخدم، والتي قد لا تنطبق على جميع بيئات التطوير. لمزيد من المعلومات حول عملية المصادقة التي يجب استخدامها لتلبية احتياجاتك، يمكنك الاطّلاع على آلية عمل بيانات الاعتماد التلقائية للتطبيق.

  1. لإنشاء مشروع في Firebase، انتقِل إلى وحدة تحكُّم Firebase. انقر على إضافة مشروع واتّبِع التعليمات التي تظهر على الشاشة لإنشاء مشروع. تذكر معرّف مشروعك.

  2. لتثبيت Google Cloud CLI، اتّبِع الخطوات الواردة في المقالة تثبيت gcloud CLI.
  3. اضبط البيئة المحلية.
    1. الربط بمشروعك على Firebase في gcloud:
        gcloud config set project FIREBASE_PROJECT_ID
        
    2. يمكنك السماح باستخدام بيانات اعتماد المستخدم للوصول إلى واجهة برمجة التطبيقات. ننصح بمنح الإذن من خلال تمرير ملف JSON لحساب الخدمة إلى Gradle باستخدام DSL في النص البرمجي للإصدار على مستوى الوحدة:

      Kotlin

        firebaseTestLab {
          ...
          serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
        }
        

      رائع

        firebaseTestLab {
          ...
          serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
        }
        

      يمكنك أيضًا منح الإذن يدويًا باستخدام الأمر الطرفي التالي:

        gcloud auth application-default login
        
    3. اختياري: أضِف مشروعك على Firebase كمشروع الحصة. لا تكون هذه الخطوة مطلوبة إلا إذا تجاوزت الحصة بدون تكلفة في مركز الاختبار الافتراضي.

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
        
  4. فعِّل واجهات برمجة التطبيقات المطلوبة.

    في صفحة واجهة برمجة التطبيقات Google Developers Console API، فعِّل Cloud Testing API وCloud Tool Results API من خلال كتابة أسماء واجهة برمجة التطبيقات هذه في مربّع البحث أعلى وحدة التحكُّم، ثم انقر على تفعيل واجهة برمجة التطبيقات في صفحة النظرة العامة لكل واجهة برمجة تطبيقات.

  5. اضبط مشروع Android.

    1. أضِف المكوّن الإضافي Firebase Test Lab إلى النص البرمجي للإصدار ذي المستوى الأعلى:

      Kotlin

        plugins {
          ...
          id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
        }
        

      رائع

        plugins {
          ...
          id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
        }
        
    2. تفعيل أنواع الأجهزة المخصّصة في ملف gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true
        
    3. أضِف المكوّن الإضافي Firebase Test Lab إلى النص البرمجي للإصدار على مستوى الوحدة:

      Kotlin

        plugins {
          ...
          id "com.google.firebase.testlab"
        }
        

      رائع

        plugins {
          ...
          id 'com.google.firebase.testlab'
        }
        

    إنشاء الاختبارات وتنفيذها على جهاز Firebase Test Lab الذي يديره Gradle

    يمكنك تحديد جهاز Firebase Test Lab لمنصة Gradle لاستخدامه في اختبار تطبيقك في النص البرمجي للإصدار على مستوى الوحدة. يؤدي نموذج الرمز البرمجي التالي إلى إنشاء هاتف Pixel 3 يعمل بالمستوى 30 من واجهة برمجة التطبيقات كجهاز اختباري يديره Gradle ويُطلق عليه اسم ftlDevice. تتوفر كتلة firebaseTestLab {} عند تطبيق المكوِّن الإضافي com.google.firebase.testlab على الوحدة. الحد الأدنى المتوافق لإصدار "المكوّن الإضافي لنظام Gradle المتوافق مع Android" هو الإصدار 8.2.0-alpha01.

    Kotlin

    firebaseTestLab {
      managedDevices {
        create("ftlDevice") {
          device = "Pixel3"
          apiLevel = 30
        }
      }
      ...
    }
    

    رائع

    firebaseTestLab {
      managedDevices {
        ftlDevice {
          device = "Pixel3"
          apiLevel = 30
        }
      }
      ...
    }
    

    لإجراء الاختبارات باستخدام أجهزة Test Lab التي يديرها Gradle، استخدم الأمر التالي. device-name هو اسم الجهاز الذي ضبطته في نص Gradle البرمجي، مثل ftlDevice، وBuildVariant هو صيغة الإصدار لتطبيقك الذي تريد اختباره. تجدر الإشارة إلى أنّ Gradle لا يُجري اختبارات على التوازي ولا يتوافق مع إعدادات أخرى في Google Cloud CLI لأجهزة Test Lab.

    في نظام التشغيل Windows:

    gradlew device-nameBuildVariantAndroidTest
    

    على نظام التشغيل Linux أو macOS:

    ./gradlew device-nameBuildVariantAndroidTest
    

    يتضمن ناتج الاختبار مسارًا إلى ملف HTML يحتوي على تقرير الاختبار. يمكنك أيضًا استيراد نتائج الاختبار إلى "استوديو Android" لإجراء المزيد من التحليل من خلال النقر على تشغيل > سجلّ الاختبار في بيئة التطوير المتكاملة (IDE).

    إنشاء اختبارات وتنفيذها على مجموعة أجهزة

    ولتوسيع نطاق الاختبار، يمكنك إضافة عدّة أجهزة معمل اختبار Firebase يديرها Gradle إلى مجموعة أجهزة، ثم إجراء الاختبارات على جميع هذه الأجهزة باستخدام أمر واحد. لنفترض أن لديك أجهزة متعددة تم إعدادها على النحو التالي:

    firebaseTestLab {
      managedDevices {
        create("GalaxyS23Ultra") { ... }
        create("GalaxyZFlip3") { ... }
        create("GalaxyZFold3") { ... }
        create("GalaxyTabS2") { ... }
      }
    }
    

    لإضافتها إلى مجموعة أجهزة باسم "samsungGalaxy"، يمكنك استخدام مجموعة "groups {}":

    firebaseTestLab {
      managedDevices {...}
    }
    
    android {
      ...
      testOptions {
        managedDevices {
          groups {
            create("samsungGalaxy") {
              targetDevices.add(devices["GalaxyS23Ultra"])
              targetDevices.add(devices["GalaxyZFlip3"])
              targetDevices.add(devices["GalaxyZFold3"])
              targetDevices.add(devices["GalaxyTabS3"])
            }
          }
        }
      }
    }
    

    لإجراء اختبارات على جميع الأجهزة في مجموعة الأجهزة، استخدِم الأمر التالي:

    في نظام التشغيل Windows:

    gradlew group-nameGroupBuildVariantAndroidTest
    

    على نظام التشغيل Linux أو macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest
    

    تحسين تنفيذ الاختبارات باستخدام ميزة "التقسيم الذكي إلى أجزاء

    يتوافق الاختبار على أجهزة Test Lab التي يديرها Gradle الآن مع عملية التقسيم الذكي إلى أجزاء. تعمل ميزة "التقسيم الذكي" على توزيع اختباراتك تلقائيًا على الأجزاء المختلفة بحيث يتم تشغيل كل جزء في الوقت نفسه تقريبًا، ما يقلّل من جهود التخصيص اليدوي والمدة الإجمالية لإجراء الاختبار. تستخدم ميزة "التقسيم الذكي" سجلّ الاختبار أو المعلومات عن المدة التي استغرقتها الاختبارات في السابق لتوزيع الاختبارات بالطريقة المثلى. تجدر الإشارة إلى أنّك تحتاج إلى الإصدار 0.0.1-alpha05 من مكوّن Gradle الإضافي لكي يتمكن مركز الاختبار الافتراضي لمنصة Firebase من استخدام التقسيم الذكي إلى أجزاء.

    لتمكين التقسيم الذكي إلى أجزاء، حدد مقدار الوقت الذي يجب أن تستغرقه الاختبارات داخل كل جزء. يجب ضبط مدّة الجزء المستهدَف على أقلّ من timeoutMinutes لمدة خمس دقائق على الأقل لتجنُّب إلغاء الأجزاء قبل اكتمال الاختبارات.

    firebaseTestLab {
      ...
      testOptions {
        targetedShardDurationMinutes = 2
      }
    }
    

    للمزيد من المعلومات، يمكنك الاطّلاع على خيارات DSL الجديدة.

    تعديل DSL لأجهزة مركز الاختبار الافتراضي لمنصة Firebase التي يديرها Gradle

    هناك المزيد من خيارات DSL التي يمكنك ضبطها للمساعدة في تخصيص عمليات الاختبار أو النقل من الحلول الأخرى التي قد تستخدمها حاليًا. اطّلع على بعض من هذه الخيارات كما هو موضّح في مقتطف الرمز التالي

    firebaseTestLab {
      ...
    
      /**
       * A path to a JSON file that contains service account credentials to access to
       * a Firebase Test Lab project.
       */
      serviceAccountCredentials.set(file("your_service_account_credentials.json"))
    
    
      testOptions {
        fixture {
          /**
           * Whether to grant permissions on the device before tests begin.
           * Available options are "all" or "none".
           *
           * Default value is "all".
           */
          grantedPermissions = "all"
    
          /**
           * Map of files to push to the device before starting the test.
           *
           * The key is the location on the device.
           * The value is the location of the file, either local or in Google Cloud.
           */
          extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
          extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"
    
          /**
           * The name of the network traffic profile.
           *
           * Specifies network conditions to emulate when running tests.
           *
           * Default value is empty.
           */
          networkProfile = "LTE"
        }
    
        execution {
          /**
           * The maximum time to run the test execution before cancellation,
           * measured in minutes. Does not include the setup or teardown of device,
           * and is handled server-side.
           *
           * The maximum possible testing time is 45 minutes on physical devices
           * and 60 minutes on virtual devices.
           *
           * Defaults to 15 minutes.
           */
           timeoutMinutes = 30
    
          /**
           * Number of times the test should be rerun if tests fail.
           * The number of times a test execution should be retried if one
           * or more of its test cases fail.
           *
           * The max number of times is 10.
           *
           * The default number of times is 0.
           */
          maxTestReruns = 2
    
          /**
           * Ensures only a single attempt is made for each execution if
           * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
           * Normally, two or more attempts are made by Firebase Test Lab if a
           * potential infrastructure issue is detected. This is best enabled for
           * latency sensitive workloads. The number of execution failures might be
           * significantly greater with `failFast` enabled.
           *
           * Defaults to false.
           */
          failFast = false
    
          /**
           * The number of shards to split the tests across.
           * 
           * Default to 0 for no sharding.
           */
          numUniformShards = 20
    
          /**
          * For smart sharding, the target length of time each shard should takes in
          * minutes. Maxes out at 50 shards for physical devices and 100 shards for
          * virtual devices.
          *
          * Only one of numUniformShards or targetedShardDurationMinutes can be set.
          *
          * Defaults to 0 for no smart sharding.
          */
          targetedShardDurationMinutes = 15
        }
    
        results {
          /**
           * The name of the Google storage bucket to store the test results in.
           *
           * If left unspecified, the default bucket is used.
           *
           * Please refer to Firebase Test Lab permissions for required permissions
           * for using the bucket.
           */
          cloudStorageBucket = "bucketLocationName"
    
          /**
           * Name of test results for the Firebase console history list.
           * All tests results with the same history name are grouped
           * together in the Firebase console in a time-ordered test history list.
           *
           * Defaults to the application label in the APK manifest in Flank/Fladle.
           */
          resultsHistoryName = "application-history"
    
          /**
           * List of paths to copy from the test device's storage to the test
           * results folder. These must be absolute paths under /sdcard or
           * /data/local/tmp.
           */
          directoriesToPull.addAll(
            "/sdcard/path/to/something"
          )
    
          /**
           * Whether to enable video recording during the test.
           *
           * Disabled by default.
           */
          recordVideo = false
    
          /**
           * Whether to enable performance metrics. If enabled, monitors and records
           * performance metrics such as CPU, memory, and network usage.
           *
           * Defaults to false.
           */
          performanceMetrics = true
        }
      }
    }