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

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

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

في ما يلي قائمة بإصدارات التصحيح في 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" في الانتقال إلى الرمز البرمجي وعرض شكله في الإصدار الذي حدثت فيه المشكلة. عند عرض تقرير عطل في إحصاءات جودة التطبيقات، يمكنك اختيار الانتقال إلى سطر الرمز البرمجي في عملية الفحص الحالية في git أو عرض اختلاف بين عملية الفحص الحالية والإصدار من قاعدة بيانات التطبيقات الذي أدّى إلى حدوث العُطل.

ملاحظة: لا تتيح هذه الميزة حاليًا التحكّم في الإصدارات إلا باستخدام git.

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

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

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

Kotlin

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

رائع

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

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

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

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

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

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

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

انقر على زر وضع التحقّق في واجهة مستخدم "الإنشاء" لتفعيل عملية التحقّق.

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

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

تم تفعيل وضع التحقّق من واجهة المستخدم لإنشاء المحتوى مع عرض التفاصيل في لوحة المشاكل.

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

يقدّم الإصدار 3 من الإصدار التجريبي من Iguana في "استوديو 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 في نص برمجي ملف ترجمة ملف APK على مستوى الوحدة:

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