Android Studio Iguana | 2023.2.1 (شباط/فبراير 2024)

في ما يلي الميزات الجديدة في الإصدار Iguana من Android Studio.

إصدارات التصحيح

في ما يلي قائمة بإصدارات الإصلاح في Android Studio Iguana والمكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3.

Android Studio Iguana | تصحيح 2 للإصدار 2023.2.1 وAGP 8.3.2 (أبريل 2024)

يتضمّن هذا التحديث البسيط إصلاحات الأخطاء التالية.

Android Studio Iguana | تصحيح 1 للإصدار 2023.2.1 وAGP 8.3.1 (مارس 2024)

يتضمّن هذا التحديث البسيط إصلاحات الأخطاء التالية.

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

يتضمّن الإصدار Iguana من "استوديو Android" تحديثات IntelliJ IDEA 2023.2 التي تحسّن تجربة حزمة تطوير البرامج (IDE) في Studio. لمعرفة تفاصيل عن التغييرات، يُرجى الاطّلاع على ملاحظات إصدار IntelliJ IDEA 2023.2.

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

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

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

• أحدث إصدار من Canary من Android Studio Iguana
• أحدث إصدار أوّلي من المكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3
• الإصدار 18.3.7 من حزمة تطوير البرامج (SDK) لخدمة Crashlytics (أو قائمة مواد Firebase لنظام التشغيل Android‏ (v32.0.0))

لاستخدام عملية دمج التحكّم في الإصدارات لنوع الإصدار القابل لتصحيح الأخطاء، فعِّل العلامة vcsInfo في ملف الإنشاء على مستوى الوحدة. بالنسبة إلى عمليات الإصدار (التي لا يمكن تصحيح أخطاءها)، يتم تفعيل العلامة تلقائيًا.

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

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

عرض أنواع الأعطال في Crashlytics في "إحصاءات جودة التطبيقات"

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

إنشاء عملية التحقّق من واجهة المستخدم

لمساعدة المطوّرين على إنشاء واجهات مستخدم أكثر سهولة وملاءمة في Jetpack Compose، طرحت أداة IDE IDE Android Studio Iguana Canary 5 وضع "فحص واجهة المستخدم" الجديد في ميزة Compose preview. تعمل هذه الميزة بالطريقة نفسها التي تعمل بها ميزة التدقيق المرئي وعمليات دمج عمليات التحقّق من تسهيل الاستخدام للوحات البيانات. عند تفعيل وضع التحقّق من واجهة مستخدم Compose، يُجري Android Studio تفتيشًا تلقائيًا على واجهة مستخدم Compose للتحقّق من المشاكل المتعلّقة بقابلية التكيف وإمكانية الاستخدام على أحجام شاشات مختلفة، مثل النص الممتد على الشاشات الكبيرة أو التباين المنخفض للألوان. ويُبرز هذا الوضع المشاكل التي يتم رصدها في إعدادات المعاينة المختلفة ويُدرجها في لوحة المشاكل.

يمكنك تجربة هذه الميزة اليوم من خلال النقر على زر التحقّق من واجهة المستخدم في ميزة "معاينة الإنشاء" وإرسال ملاحظاتك:

المشاكل المعروفة في "وضع التحقّق من واجهة المستخدم":

• قد يتم فقدان التركيز على المشكلة المحدّدة في لوحة المشاكل
• عدم عمل ميزة "الإيقاف المؤقت للقاعدة"

العرض التدريجي لمعاينة Compose

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

تم تطوير هذه الميزة بهدف تحسين سهولة استخدام ميزة "المعاينات" من خلال إمكانية عرض المزيد من المعاينات في الوقت نفسه في ملف. ننصحك بتجربة هذه الميزة اليوم وإرسال ملاحظاتك.

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

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

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

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

اختبار التغييرات في الإعدادات باستخدام Espresso Device API

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

لاستخدام Espresso Device API، يجب أن يكون لديك ما يلي:

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

إعداد مشروعك لاستخدام Espresso Device API

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

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

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

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

     android.experimental.androidTest.enableEmulatorControl=true

3. فعِّل الخيار emulatorControl في نص برمجي ملف بدء الإنشاء على مستوى الوحدة:

   Kotlin

     testOptions {
       emulatorControl {
         enable = true
       }
     }

   رائع

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. في نصّ إنشاء مستوى الوحدة، استورِد مكتبة Espresso Device إلى مشروعك:

   Kotlin

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

   رائع

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

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

تتضمّن 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()
     }

اختبار الشاشة أثناء فتحها

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

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() {
  ...
}