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

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

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

في ما يلي قائمة بإصدارات الإصلاح في 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 التي تحسّن تجربتك مع حزمة Studio IDE. لمعرفة تفاصيل عن التغييرات، يُرجى الاطّلاع على ملاحظات إصدار IntelliJ IDEA 2023.2.

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

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

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

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

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

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

Kotlin

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

رائع

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يمكنك استخدام Espresso Device API لاختبار تطبيقك عندما يخضع الجهاز لتغييرات شائعة في الإعداد، مثل التدوير وفتح الشاشة. تتيح لك واجهة برمجة التطبيقات Espresso Device API محاكاة تغييرات الإعدادات هذه على جهاز افتراضي وتنفيذ اختباراتك بشكل متزامن، بحيث يتم تنفيذ إجراء أو تأكيد واحد فقط على واجهة المستخدم في كل مرة وتكون نتائج الاختبار أكثر موثوقية. اطّلِع على مزيد من المعلومات عن كيفية كتابة اختبارات واجهة المستخدم باستخدام 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() {
  ...
}