الميزات الجديدة في معاينة "استوديو Android"

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

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

الإصدارات الحالية من "استوديو Android"

يسرد الجدول التالي الإصدارات الحالية من "استوديو Android" والقنوات المرتبطة بها.

التوافق مع معاينات مكوّنات Gradle الإضافية لنظام التشغيل Android

يتم نشر كل إصدار معاينة من "استوديو Android" جنبًا إلى جنب مع إصدار مقابل من مكوّن Android Gradle الإضافي (AGP). يجب أن تعمل إصدارات المعاينة من "استوديو YouTube" مع أي إصدار ثابت متوافق من AGP. ومع ذلك، إذا كنت تستخدم إصدار معاينة من AGP، يجب استخدام إصدار المعاينة المقابل من Studio (على سبيل المثال، Android Studio Chipmunk Canary 7 مع AGP 7.2.0-alpha07). وستؤدي محاولات استخدام إصدارات مختلفة (على سبيل المثال، Android Studio Chipmunk Beta 1 مع AGP 7.2.0-alpha07) إلى إخفاق المزامنة، ما يؤدي إلى ظهور رسالة مطالبة بالتحديث إلى الإصدار المقابل من AGP.

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

Android Studio Hedgehog | 2023.1.1

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

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

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

ماكرو جديد لتحديد مسار JDK

يقدِّم Android Studio Hedgehog Canary 10 وحدة ماكرو جديدة #GRADLE_LOCAL_JAVA_HOME لتحديد مسار JDK. هذا يجعل من الأكثر أمانًا وأسهل تحديد مسار Java الرئيسي المستخدم لتنفيذ البرنامج الخفي Gradle (العملية الخلفية) لمشروعك. يتم تخزين اختيار المسار في حقل java.home في ملف .gradle/config.properties. اضبط هذا الحقل من خلال إعدادات Gradle JDK في Android Studio (ملف أو استوديو Android > الإعدادات > الإنشاء، والتنفيذ، والنشر > أدوات الإنشاء > Gradle).

ستستخدم المشاريع الجديدة #GRADLE_LOCAL_JAVA_HOME تلقائيًا. سيتم نقل المشاريع الحالية تلقائيًا إلى وحدة الماكرو الجديدة بعد إجراء مزامنة ناجحة، ما لم تكن تستخدم وحدة ماكرو مثل #JAVA_HOME.

في ما يلي المزايا الرئيسية لوحدة الماكرو الجديدة:

• يمكنك تعديل مسار JDK يدويًا لتشغيل المزامنة بدون فتح مشروعك أولاً.
• هناك عدد أقل من الأخطاء المرتبطة بإصدارات Gradle غير المتوافقة ومشروع JDK، نظرًا لوجود مصدر واحد للحقيقة في اختيار Gradle JDK.

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

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

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

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

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

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

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

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

يمكنك الآن النسخ المطابق لجهازك في نافذة الأجهزة قيد التشغيل في استوديو 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) أو بدء النسخ المطابق لجهاز مادي مباشرةً من نافذة قيد الأجهزة من خلال النقر على رمز + واختيار جهاز. لإيقاف "متوسط مدة المشاهدة" أو النسخ المطابق لجهاز مادي، أغلِق علامة تبويب الجهاز.

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

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

تشغيل "استوديو Android" في "الوضع الآمن"

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

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

• إيقاف المكوّنات الإضافية التابعة لجهات خارجية
• تتم استعادة مكوّن Kotlin الإضافي المجمّع إلى الإصدار المضمّن في الأصل في "استوديو YouTube".
• إعادة ضبط الإعدادات مؤقتًا، على سبيل المثال في ملف studio.vmoptions
• تتحقّق هذه السياسة من متغيرات البيئة التي يمكن أن تمنع بدء التشغيل، مثل JRE_HOME وTMP.
• لإعادة JRE إلى إصدار متوافق إذا لزم الأمر

لتشغيل "استوديو Android" في "الوضع الآمن"، يُرجى اتّباع الخطوات التالية:

1. ابحث عن نص "الوضع الآمن".
   • على نظام التشغيل Windows، انتقِل إلى AndroidStudio/bin وابحث عن النص البرمجي studio_safe.bat.
   • على نظام التشغيل macOS، انتقِل إلى Android Studio/Contents/bin وابحث عن نص studio_safe.sh البرمجي.
   • على نظام التشغيل Linux، انتقِل إلى android-studio/bin وابحث عن النص البرمجي studio_safe.sh.
2. شغِّل النص البرمجي: افتح سطر الأوامر واكتب studio_safe.bat (studio_safe.sh لنظام التشغيل macOS أو Linux)، ثم اضغط على Enter.

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

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

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

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

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

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

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

توضح الخطوات التالية كيفية البدء في استخدام أجهزة مركز الاختبار الافتراضي لمنصة Firebase مع 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 كمشروع الحصة. تكون هذه الخطوة مطلوبة فقط إذا تجاوزت الحصة بدون تكلفة لـ Test Lab.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      

4. تفعيل واجهات برمجة التطبيقات المطلوبة

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

5. ضبط مشروع Android

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

      Kotlin

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

      رائع

      plugins {
        ...
        id 'com.google.firebase.testlab' version '0.0.1-alpha03' 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 مُدار من خلال Gradle

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

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

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

لإجراء اختباراتك باستخدام أجهزة مركز الاختبار الافتراضي التي يديرها 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 Test Lab المُدارة من خلال 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-alpha03 من مكوّن Gradle الإضافي لكي تتمكن من استخدام ميزة التقسيم الذكي في Firebase Test Lab.

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

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

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

تحديث DSL لأجهزة Firebase Test Lab التي تديرها 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
    }
  }
}

التوافق مع كتالوجات إصدارات Gradle

يقدّم تطبيق Android Studio Giraffe دعمًا لميزة Gradle Version Catalogs المستندة إلى TOML، وهي ميزة تتيح لك إدارة الاعتمادات في موقع مركزي واحد ومشاركة التبعيات عبر الوحدات أو المشاريع. يسهّل "استوديو Android" الآن ضبط كتالوجات الإصدارات من خلال اقتراحات المحرّر والدمج مع مربّع حوار بنية المشروع. لمعرفة كيفية التحديث إلى كتالوجات إصدارات Gradle، يمكنك الاطّلاع على نقل إصدارك إلى كتالوجات الإصدارات.

إكمال الرمز والتنقل

يتيح "استوديو Android" إكمال الرموز عند تعديل كتالوج إصدار بتنسيق ملف TOML أو إضافة تبعية من كتالوج إصدار إلى ملف إصدار. لاستخدام ميزة إكمال الرمز، اضغط على Ctrl+Space (Command+Space على نظام التشغيل macOS). بالإضافة إلى ذلك، يمكنك الانتقال بسرعة من مرجع التبعية في ملف build.gradle لتطبيقك إلى المكان الذي تم تعريفه فيه في كتالوج الإصدار من خلال الضغط على Ctrl+b (Command+b على نظام التشغيل macOS).

التكامل مع مربع حوار "بنية المشروع"

إذا كان مشروعك يستخدم كتالوج إصدارات محدّدًا بتنسيق ملف TOML، يمكنك تعديل المتغيرات التي حدّدتها هناك من خلال مربّع حوار بنية المشروع لعرض المتغيّرات (ملف > بنية المشروع > المتغيرات) في "استوديو Android". لكل كتالوج إصدار، توجد قائمة منسدلة تسرد المتغيرات من هذا الكتالوج. لتعديل متغيّر، انقر على قيمته واستبدله. عند حفظ هذه التغييرات، يتم تحديث ملف TOML وفقًا لذلك.

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

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

في ما يلي المشاكل أو القيود المعروفة التي تتعلّق بالتوافق مع كتالوجات إصدار Gradle في "استوديو Android".

حدث خطأ أثناء تمييز بيانات الاسم المستعار للمكوّن الإضافي في ملفات نصوص Kotlin البرمجية.

عند إضافة إعلان مكوّن إضافي للنموذج alias(libs.plugins.example)، يضيف المحرر تسطيرًا أحمر أسفل الجزء libs. هذه مشكلة معروفة في إصدار Gradle 8.0 والإصدارات الأقدم وسيتم حلّها في إصدار مستقبلي من Gradle.

توافق "استوديو Android" مع كتالوجات الإصدارات بتنسيق TOML فقط

في الوقت الحالي، لا يتوفر دعم مربع حوار إكمال رمز "استوديو Android" والتنقل و"بنية المشروع" إلا لكتالوجات الإصدارات المحددة بتنسيق ملف TOML. ومع ذلك، لا يزال بإمكانك إضافة كتالوج إصدارات مباشرةً في ملف settings.gradle واستخدام العناصر الاعتمادية الخاصة به في مشروعك.

التنقّل في ملفات إصدار KTS غير متاح

إنّ الانتقال إلى تعريف التبعية في كتالوج الإصدار باستخدام Control+click (Command+click في macOS) غير متاح حتى الآن لملفات الإصدار المكتوبة باستخدام نص Kotlin البرمجي.

يضيف "مساعد Firebase" التبعيات مباشرةً في النصوص البرمجية لإنشاء النصوص

يضيف مساعد Firebase تبعيات مباشرةً إلى النصوص البرمجية للإصدار بدلاً من كتالوجات الإصدارات.

وظيفة "البحث عن الاستخدامات" غير متاحة

لم تتوفّر بعد إمكانية العثور على استخدامات متغيّر كتالوج الإصدار في ملفات إصدار أخرى، سواء كان ملف الإصدار في KTS أو Groovy. وهذا يعني أنّ استخدام Control+النقر (Command+click on macOS) على تعريف متغير في كتالوج الإصدارات لا يؤدي إلى ملفات الإصدار التي يتم فيها استخدام المتغيّر.

لا يعرض مربع حوار "بنية المشروع" كتالوجات من الإصدارات المركبة.

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

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

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

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

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

لم تعد مشاريع أداة تطوير Android الخاصة بـ Eclipse متاحة

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

Android Studio Iguana | 2023.2.1

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

العرض التدريجي لمعاينة الإنشاء

يقدم Android Studio Iguana Canary 3 ميزة العرض التقدمي في معاينة الإنشاء. في إطار جهودنا المستمرة لتحسين أداء المعاينات، والآن بالنسبة إلى أي معاينة خارج إطار العرض، نعمل عن عمد على تقليل جودة العرض لتوفير الذاكرة المستخدَمة.

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

لمحة عن "برنامج إدارة الإعلانات" في "استوديو YouTube"

Studio Bot هو رفيقك في ما يتعلق بالترميز لتطوير Android. إنّها تجربة حوارية مستندة إلى الذكاء الاصطناعي (AI) في "استوديو Android" تساعدك على زيادة إنتاجيتك من خلال الإجابة على الاستفسارات المتعلّقة بتطوير Android. لمزيد من المعلومات، اطّلع على برنامج تتبُّع استوديو Meet.

دمج نظام التحكّم في الإصدارات في أداة "إحصاءات جودة التطبيقات"

تتيح لك إحصاءات جودة التطبيق الآن الانتقال من تتبُّع تسلسل استدعاء الدوال البرمجية إلى Crashlytics إلى الرمز ذي الصلة، في الوقت الذي حدث فيه التعطُّل. ترفق AGP بيانات git Confirm في تقارير الأعطال لمساعدة استوديو Android في الانتقال إلى التعليمات البرمجية وإظهار مدى حدوث المشكلة في الإصدار الذي حدثت فيه المشكلة. عند الاطّلاع على تقرير الأعطال في إحصاءات جودة التطبيق، يمكنك اختيار الانتقال إلى سطر الرمز في عملية الدفع الحالية أو عرض الفرق بين عملية الدفع الحالية وإصدار قاعدة الرموز التي أدت إلى حدوث العطل.

لدمج نظام التحكم في الإصدارات الذي تستخدمه مع إحصاءات جودة التطبيقات، عليك استيفاء المتطلبات التالية كحدّ أدنى:

• أحدث إصدار Canary من Android Studio Iguana
• أحدث إصدار من "الإصدار الأولي" من الإصدار 8.3 من المكوّن الإضافي لنظام Gradle المتوافق مع Android
• Crashlytics SDK v18.3.7 (أو قائمة مواد Android من Firebase الإصدار 32.0.0)

لاستخدام دمج التحكّم في الإصدارات، عليك تفعيل علامة android.enableVcsInfo في ملف gradle.properties:

android.enableVcsInfo=true

والآن، عند إنشاء تطبيقك ونشره على Google Play، تتضمّن تقارير الأعطال البيانات اللازمة لربط بيئة تطوير البرامج (IDE) بالإصدارات السابقة من تطبيقك من تتبع تسلسل استدعاء الدوال البرمجية.

إجراء اختبار للتأكّد من إجراء تغييرات في الإعدادات باستخدام Espresso Device API

يمكنك استخدام Espresso Device API لاختبار تطبيقك عندما يخضع الجهاز لتغييرات شائعة في الضبط، مثل التدوير وفتح الشاشة. تتيح لك واجهة Espresso Device API محاكاة تغييرات الإعدادات هذه على جهاز افتراضي وتنفيذ اختباراتك بشكل متزامن، لذلك لا يتم إجراء سوى إجراء واحد أو تأكيد واحد لواجهة المستخدم في كل مرة وستصبح نتائج الاختبار أكثر موثوقية. إذا كنت مبتدئًا في كتابة اختبارات واجهة المستخدم باستخدام Espresso، يُرجى الاطّلاع على مستنداتها.

لاستخدام Espresso Device API، ستحتاج إلى ما يلي:

• أحدث إصدار Canary من Android Studio Iguana
• أحدث إصدار من "الإصدار الأولي" من الإصدار 8.3 من المكوّن الإضافي لنظام Gradle المتوافق مع Android
• الإصدار 33.1.10 من محاكي Android أو إصدار أحدث
• جهاز Android افتراضي يعمل بالمستوى 24 من واجهة برمجة التطبيقات أو مستوى أعلى

إعداد مشروعك لواجهة برمجة تطبيقات Espresso Device API

لإعداد مشروعك بحيث يتوافق مع Espresso Device API، عليك اتّباع الخطوات التالية:

• للسماح للجهاز الاختباري باجتياز الأوامر المسموح بها، أضِف الإذنَين INTERNET وACCESS_NETWORK_STATE إلى ملف البيان في مجموعة المصادر androidTest:

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />
    

• فعِّل العلامة التجريبية enableEmulatorControl في ملف gradle.properties:

    android.experimental.androidTest.enableEmulatorControl=true
    

• فعِّل الخيار emulatorAccess في النص البرمجي للإصدار على مستوى الوحدة:

  Kotlin

    testOptions {
      emulatorAccess {
        isEnabled = true
      }
    }
    

  رائع

    testOptions {
      emulatorAccess {
        enabled true
      }
    }
    

• في النص البرمجي للإصدار على مستوى الوحدة، يمكنك استيراد مكتبة Espresso Device إلى مشروعك:

  Kotlin

    dependencies {
      androidTestImplementation("androidx.test.espresso:espresso-device:1.0.0-alpha05")
    }
    

  رائع

    dependencies {
      androidTestImplementation 'androidx.test.espresso:espresso-device:1.0.0-alpha05'
    }
    

الاختبار مقابل تغييرات الإعدادات الشائعة

تتضمّن Espresso Device API عدة اتجاهات في الشاشة وحالات قابلة للطي يمكنك استخدامها لمحاكاة تغييرات إعدادات الجهاز.

الاختبار مقابل تدوير الشاشة

إليك مثال على كيفية اختبار ما يحدث لتطبيقك عند تدوير شاشة الجهاز:

1. أولاً، عليك ضبط الجهاز على الوضع العمودي للحصول على حالة بدء متسقة:

     import androidx.test.espresso.device.action.ScreenOrientation
     import androidx.test.espresso.device.rules.ScreenOrientationRule
     ...
     @get:Rule
     val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)
     

2. أنشئ اختبارًا يضبط الجهاز على الاتجاه الأفقي أثناء تنفيذ الاختبار:

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       ...
     }
     

3. بعد تدوير الشاشة، تحقق من أن واجهة المستخدم تتكيّف مع التنسيق الجديد كما هو متوقع.

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
     }
     

الاختبار مع فتح الشاشة

إليك مثال على كيفية اختبار ما يحدث لتطبيقك إذا كان على جهاز قابل للطي وتنفتح الشاشة:

1. أولاً، اختبِر الجهاز في الحالة المطوية من خلال طلب onDevice().setClosedMode(). يُرجى التأكّد من أنّ تنسيق تطبيقك يتكيّف مع عرض الشاشة الصغير.

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
       composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
       ...
     }
     

2. للانتقال إلى وضع "غير مطوي بالكامل"، اتّصِل بـ onDevice().setFlatMode(). تأكّد من أنّ تنسيق التطبيق يتكيّف مع فئة الحجم الموسّع.

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       ...
       onDevice().setFlatMode()
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
     }
     

تحديد الأجهزة التي تحتاج إليها اختباراتك

إذا كنت تجري اختبارًا يؤدي إجراءات الطي على جهاز غير قابل للطي، من المرجح أن يتعذّر الاختبار. ولإجراء الاختبارات ذات الصلة بالجهاز قيد التشغيل فقط، استخدِم التعليق التوضيحي @RequiresDeviceMode. يتخطى عدّاء الاختبار تلقائيًا إجراء الاختبارات على الأجهزة التي لا تتوافق مع الإعدادات التي يتم اختبارها. يمكنك إضافة قاعدة متطلبات الجهاز إلى كل اختبار أو إلى فئة اختبار كاملة.

على سبيل المثال، لتحديد أنّ الاختبار يجب ألا يتم إلا على الأجهزة التي تتوافق مع فتح الجهاز بإعدادات مستوية، أضِف رمز @RequiresDeviceMode التالي إلى الاختبار:

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}

معالج وحدة "الملفات الشخصية الأساسية"

بدءًا من Android Studio Iguana، يمكنك إنشاء ملفات شخصية أساسية لتطبيقك باستخدام نموذج منشئ الملف الشخصي للمرجع في معالج الوحدات الجديد (ملف > جديد > وحدة جديدة).

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

ينشئ النموذج أيضًا تهيئة تشغيل تتيح لك إنشاء ملف شخصي مرجعي بنقرة واحدة من القائمة المنسدلة تحديد تهيئة التشغيل/تصحيح الأخطاء.