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

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

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

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

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

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

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

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

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

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

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

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

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

يُعدّ هذا النموذج مشروعك كي يكون متوافقًا مع الملفات الشخصية الأساسية. ويستخدم الإصدار الجديد من Baseline Profiles Gradle plugin، الذي يعمل على أتمتة عملية إعداد مشروعك بالطريقة المطلوبة باستخدام مهمة 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() {
  ...
}