Android Studio Iguana | 2023.2.1

Android Studio هو بيئة تطوير البرامج (IDE) الرسمية لتطوير Android، ويتضمن كل ما تحتاجه لإنشاء تطبيقات Android.

تعرض هذه الصفحة الميزات والتحسينات الجديدة في أحدث إصدار في القناة الثابتة، "Android Studio Iguana". يمكنك تنزيله من هنا أو التحديث إليه في "استوديو Android" من خلال النقر على مساعدة > البحث عن تحديثات (استوديو Android > البحث عن تحديثات على نظام التشغيل macOS)

لمعرفة المشاكل التي تم إصلاحها في هذا الإصدار من "استوديو Android"، يمكنك الاطّلاع على المشاكل التي تم إغلاقها.

لعرض ملاحظات الإصدار الخاصة بالإصدارات الأقدم من "استوديو Android"، يمكنك الاطّلاع على قسم الإصدارات السابقة.

لاستخدام الميزات والتحسينات القادمة قبل إطلاقها، يُرجى الاطّلاع على معاينة إصدارات "استوديو Android".

إذا واجهت مشاكل في "استوديو Android"، راجِع صفحة المشاكل المعروفة أو تحديد المشاكل وحلّها.

المكوّن الإضافي لنظام Gradle المتوافق مع Android والتوافق مع "استوديو Android"

يستند نظام تصميم "استوديو Android" إلى Gradle، ويضيف مكوّن Android Gradle الإضافي (AGP) العديد من الميزات الخاصة بتصميم تطبيقات Android. يسرد الجدول التالي إصدار AGP المطلوب لكل إصدار من إصدارات استوديو Android.

إصدار "استوديو Android" إصدار AGP المطلوب
قنديل البحر | 2023.3.1 3.2-8.4
الإغوانا | 1 تشرين الثاني (نوفمبر) 2023 3.2-8.3
القنفذ | 1.1.2023 3.2 إلى 8.2
زرافة | 1 حزيران (يونيو) 2022 8.1-3.2
طائر الفلامينغو | 1 تشرين الثاني (نوفمبر) 2022 3.2-8.0
Electric eel | 2022.1.1 3.2-7.4

إصدارات سابقة

إصدار "استوديو Android" إصدار AGP المطلوب
دولفين | 2021/3.1 3.2-7.3
سنجاب | 2021.2.1 7.2-3.2
Bumblebee | 2021.1.1 3.2-7.1
Arctic Fox | 2020.3.1 من 3.1 إلى 7.0

للاطّلاع على معلومات حول الميزات الجديدة في مكوّن Android Gradle الإضافي، يمكنك الاطّلاع على ملاحظات إصدار المكوّن الإضافي لنظام Gradle المتوافق مع Android.

الحد الأدنى لإصدارات الأدوات لمستوى واجهة برمجة تطبيقات Android

يتوفّر عدد أدنى من إصدارات "استوديو Android" وAGP المتوافقة مع مستوى معيّن من واجهة برمجة التطبيقات. قد يؤدي استخدام إصدارات أقل من "استوديو Android" أو AGP إلى ما هو مطلوب في targetSdk أو compileSdk لمشروعك، قد يؤدي إلى حدوث مشاكل غير متوقَّعة. نقترح استخدام أحدث إصدار لمعاينة "استوديو Android" وAGP للعمل على المشاريع التي تستهدف إصدارات المعاينة من نظام التشغيل Android. يمكنك تثبيت إصدارات المعاينة من "استوديو Android" إلى جانب الإصدار الثابت.

في ما يلي الحد الأدنى لإصدارات "استوديو Android" وAGP:

مستوى واجهة برمجة التطبيقات الحد الأدنى لإصدار "استوديو Android" الحد الأدنى لإصدار AGP
معاينة VanillaIceCream قنديل البحر | 2023.3.1 8.4
34 القنفذ | 1.1.2023 8.1.1
33 طائر الفلامينغو | 1 تشرين الثاني (نوفمبر) 2022 7.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لاستخدام Espresso Device API، ستحتاج إلى ما يلي:

  • Android Studio Iguana أو إصدار أحدث
  • الإصدار 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.5.1")
      }

    رائع

      dependencies {
        androidTestImplementation 'androidx.test.espresso:espresso-device:3.5.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() {
  ...
}