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

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

إصدارات رموز التصحيح

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

الإصدار Iguana من "استوديو Android" | الإصدار 2 من حزمة تصحيح ‎2023.2.1 والإصدار 8.3.2 من المكوّن الإضافي لنظام Gradle المتوافق مع Android (أبريل 2024)

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

الإصدار Iguana من "استوديو Android" | الإصدار 1 من حزمة تصحيح ‎2023.2.1 والإصدار 8.3.1 من المكوّن الإضافي لنظام Gradle المتوافق مع Android (مارس 2024)

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

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

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

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

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

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

• أحدث إصدار Canary من استوديو Android Iguana
• أحدث إصدار أولي من المكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3
• الإصدار 18.3.7 من حزمة تطوير البرامج (SDK) في Crashlytics (أو الإصدار 32.0.0 من قائمة مواد منصة Firebase لأجهزة Android)

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

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

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

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

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

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

فحص واجهة Compose

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

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

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

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

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

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

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

معالج وحدة "ملفات Baseline Profile"

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

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

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

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

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

لاستخدام Espresso Device API، يجب استيفاء الشروط التالية:

• الإصدار Iguana من "استوديو Android" أو إصدار أحدث
• الإصدار 8.3 من المكوّن الإضافي لنظام Gradle المتوافق مع Android أو إصدار أحدث
• الإصدار 33.1.10 من Android Emulator أو إصدار أحدث
• جهاز 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()
     }

الاختبار عند فتح الشاشة

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

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