Android Studio Hedgehog | 2023.1.1 (نوامبر 2023)

موارد زیر ویژگی های جدید Android Studio Hedgehog هستند.

به روز رسانی پلتفرم IntelliJ IDEA 2023.1

Android Studio Hedgehog شامل به‌روزرسانی‌های IntelliJ IDEA 2023.1 است که تجربه Studio IDE را بهبود می‌بخشد. برای جزئیات تغییرات، به یادداشت‌های انتشار IntelliJ IDEA 2023.1 مراجعه کنید.

موارد حیاتی Android را در App Quality Insights تجزیه و تحلیل کنید

App Quality Insights اکنون شامل داده‌های حیاتی Android است، بنابراین می‌توانید راحت‌تر به معیارهای اصلی جمع‌آوری‌شده توسط Google Play دسترسی داشته باشید و تجربه کاربری خود را بهبود بخشید. برای کمک به بهبود کیفیت برنامه خود در Google Play، از برنامه حیاتی Android برای رفع مشکلات مربوط به پایداری برنامه استفاده کنید.

از پنجره ابزار App Quality Insights می‌توانید مسائل حیاتی Android را مشاهده کنید، آن‌ها را فیلتر کنید، و از Stack Trace به همه کدها بروید. برای شروع، مراحل زیر را دنبال کنید:

  1. با استفاده از نماد نمایه به حساب توسعه دهنده خود در Android Studio وارد شوید در انتهای نوار ابزار
  2. App Quality Insights را با کلیک کردن روی پنجره ابزار در Android Studio یا روی View > Tool Windows > App Quality Insights باز کنید.
  3. روی برگه Android vitals در App Quality Insights کلیک کنید.

اعداد مختلف بین Android vitals و Crashlytics

توجه داشته باشید که Android vitals و Crashlytics ممکن است مقادیر متفاوتی را برای تعداد کاربران و رویدادهای مرتبط با یک خرابی گزارش دهند. این تناقضات به این دلیل اتفاق می‌افتد که Play و Crashlytics می‌توانند در زمان‌های مختلف و برای کاربران مختلف دچار خرابی شوند. در اینجا چند دلیل برای اینکه چرا تعداد Play و Crashlytics ممکن است متفاوت باشد آورده شده است:

  • خرابی‌های Play از زمان راه‌اندازی شروع می‌شود، در حالی که Crashlytics خرابی‌هایی را که پس از راه‌اندازی Crashlytics SDK اتفاق می‌افتد، می‌گیرد.
  • اگر کاربر هنگام دریافت یک تلفن جدید از گزارش خرابی منصرف شود، این خرابی‌ها به Play گزارش نمی‌شوند. با این حال، Crashlytics بر اساس خط مشی رازداری خود برنامه، خرابی ها را می گیرد.

نمایه برق جدید

با شروع Android Studio Hedgehog، Power Profiler مصرف انرژی را در دستگاه‌ها نشان می‌دهد. می‌توانید این داده‌های جدید را در مانیتور ریل برق دستگاه (ODPM) مشاهده کنید. ODPM داده ها را بر اساس زیر سیستم هایی به نام Power Rails تقسیم می کند. برای فهرستی از زیرسیستم های پشتیبانی شده ، ریل های برق قابل مشاهده را ببینید.

System Trace داده های مصرف انرژی را ثبت و نمایش می دهد. این بخشی از پروفایلر CPU است. این داده ها به شما کمک می کند مصرف انرژی دستگاه را به صورت بصری با اقداماتی که در برنامه شما رخ می دهد مرتبط کنید. Power Profiler تجسم این داده ها را فعال می کند.

Power Profiler جدید

برای مشاهده داده‌های Power Profiler جدید، یک ردیابی سیستم را در دستگاه Pixel 6+ بگیرید:

  1. View > Tool Windows > Profiler را انتخاب کنید.
  2. روی هر نقطه از جدول زمانی CPU کلیک کنید تا نمایه CPU باز شود و ردیابی سیستم شروع شود.

دستیار پیوندهای برنامه جدید یک نمای کلی از پیوندهای عمیق تنظیم شده در برنامه شما ارائه می دهد. «دستیار» همه پیوندهای عمیق موجود در فایل AndroidManifest.xml برنامه را نمایش می‌دهد، تأیید می‌کند که آیا پیکربندی آن پیوندهای عمیق درست است یا خیر، و راهی سریع برای رفع خودکار پیکربندی‌های نادرست ارائه می‌دهد.

برای باز کردن App Links Assistant به Tools > App Links Assistant در Android Studio بروید. برای اطلاعات بیشتر درباره پیوندهای برنامه، به افزودن پیوندهای برنامه Android مراجعه کنید.

میانبر حالت دستی به روز شده ویرایش زنده

ویرایش زنده در Android Studio Hedgehog شامل یک میانبر جدید برای حالت دستی ( Push Manually ): Control+\ ( Command+\ برای macOS). حالت دستی در شرایطی مفید است که می‌خواهید کنترل دقیقی بر روی زمان به‌روزرسانی‌ها در برنامه در حال اجرا داشته باشید. به عنوان مثال، اگر در حال ایجاد تغییر در مقیاس بزرگ در یک فایل هستید و نمی خواهید هیچ حالت میانی روی دستگاه منعکس شود. در تنظیمات Live Edit یا با استفاده از نشانگر Live Edit UI می توانید بین Push Manually و Push Manually on Save یکی را انتخاب کنید. برای اطلاعات بیشتر، کلیپ ویدیویی را در ویرایش زنده برای Jetpack Compose ببینید.

قالب های Multipreview را بنویسید

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ الگوهای Multipreview API جدیدی را معرفی می‌کند: @PreviewScreenSizes ، @PreviewFontScales ، @PreviewLightDark ، و @PreviewDynamicColors ، به طوری که می‌توانید پیش‌نمایش مشترک خود را با یک UI ترکیب کنید. سناریوها

در Android Studio Hedgehog، یک حالت گالری جدید در Compose Preview معرفی شده است که به شما امکان می دهد هر بار بر روی یک پیش نمایش تمرکز کنید و منابع را در رندر ذخیره کنید. توصیه می‌کنیم زمانی که نیاز به تکرار در رابط کاربری برنامه خود دارید، از حالت گالری استفاده کنید و زمانی که نیاز به مشاهده انواع رابط کاربری دارید، به حالت‌های دیگر مانند Grid یا List بروید.

نوشتن اطلاعات وضعیت در دیباگر

وقتی بخش‌هایی از Compose UI شما به‌طور غیرمنتظره‌ای دوباره ترکیب می‌شوند، گاهی اوقات درک دلیل آن دشوار است. اکنون، هنگام تنظیم یک نقطه انفصال بر روی یک تابع قابل ترکیب، دیباگر پارامترهای قابل ترکیب و وضعیت آنها را فهرست می کند، بنابراین می توانید راحت تر تشخیص دهید که چه تغییراتی ممکن است باعث ترکیب مجدد شده باشد. به عنوان مثال، هنگامی که روی یک composable مکث می کنید، دیباگر می تواند دقیقاً به شما بگوید که کدام پارامترها "تغییر" کرده اند یا "بدون تغییر" باقی مانده اند، بنابراین می توانید به طور موثرتری علت ترکیب مجدد را بررسی کنید.

آینه کاری دستگاه

اکنون می توانید دستگاه فیزیکی خود را در پنجره Running Devices در Android Studio بازتاب دهید. با پخش مستقیم نمایشگر دستگاهتان در Android Studio، می‌توانید اقدامات معمولی مانند راه‌اندازی برنامه‌ها و تعامل با آن‌ها، چرخاندن صفحه، تا کردن و باز کردن گوشی، تغییر صدا و موارد دیگر را مستقیماً از خود Studio IDE انجام دهید.

وقتی دستگاه‌هایی به رایانه متصل هستند که USB یا اشکال‌زدایی بی‌سیم را فعال کرده‌اند، همیشه در دسترس است. می توانید با استفاده از پنجره Running Devices یا Device Manager ( نمایش > Tool Windows > Device Manager ) انعکاس را شروع و متوقف کنید. همچنین می‌توانید زمانی که انعکاس دستگاه در تنظیمات آن فعال می‌شود، سفارشی کنید ( تنظیمات > ابزارها > بازتاب دستگاه ).

در حال اجرا UI دستگاه ها

مسائل شناخته شده

برخی از دستگاه‌ها ممکن است قادر به رمزگذاری با نرخ بیت کافی برای پشتیبانی از انعکاس دستگاه نباشند. در این شرایط، ممکن است خطایی در پنجره Running Devices و همچنین گزارش هایی مشابه آنچه در زیر نشان داده شده است مشاهده کنید.

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

اطلاعیه حریم خصوصی

بر اساس تنظیمات انعکاس دستگاه، Android Studio می تواند به طور خودکار انعکاس دستگاه را برای هر دستگاه متصل و جفت شده شروع کند. این ممکن است منجر به افشای اطلاعات برای دستگاه‌های متصل به دستور adb tcpip شود، زیرا اطلاعات و دستورات انعکاسی از طریق یک کانال غیر رمزگذاری‌شده ارسال می‌شوند. علاوه بر این، Android Studio از یک کانال غیر رمزگذاری شده برای برقراری ارتباط با سرور adb استفاده می کند، بنابراین اطلاعات انعکاسی می تواند توسط سایر کاربران در دستگاه میزبان شما رهگیری شود.

ارسال ورودی سخت افزار

اکنون می‌توانید ارسال شفاف ورودی‌های سخت‌افزار ایستگاه کاری خود، مانند ماوس و صفحه‌کلید، به یک دستگاه فیزیکی و مجازی متصل را فعال کنید. برای فعال کردن ارسال شفاف، روی ورودی سخت افزار کلیک کنید برای دستگاه مورد نظر در پنجره Running Devices .

دستگاه ها را مستقیماً از پنجره Running Devices مدیریت کنید

اکنون می‌توانید یک دستگاه مجازی اندروید (AVD) را راه‌اندازی کنید یا مستقیماً از پنجره «دستگاه‌های در حال اجرا» با کلیک کردن روی نماد + و انتخاب یک دستگاه، انعکاس یک دستگاه فیزیکی را شروع کنید. برای متوقف کردن AVD یا انعکاس یک دستگاه فیزیکی، برگه دستگاه را ببندید.

کشویی Device از Running Devices

بازرس طرح بندی جاسازی شده

با شروع Android Studio Hedgehog Canary 2، می‌توانید Layout Inspector را مستقیماً در پنجره ابزار Running Devices اجرا کنید. این ویژگی آزمایشی املاک صفحه را حفظ می کند و به سازماندهی گردش کار اشکال زدایی رابط کاربری در یک پنجره ابزار کمک می کند. در حالت جاسازی شده می‌توانید سلسله‌مراتب نما را نشان دهید، ویژگی‌های هر نما را بررسی کنید و به سایر ویژگی‌های رایج Layout Inspector دسترسی پیدا کنید. برای دسترسی به مجموعه کامل گزینه‌ها، همچنان باید Layout Inspector را در یک پنجره مستقل اجرا کنید ( File > Settings > Experimental > Layout Inspector در Windows یا Android Studio > Settings > Experimental > Layout Inspector در macOS).

محدودیت Layout Inspector تعبیه شده این است که حالت سه بعدی فقط در عکس های فوری موجود است.

برای کمک به ما در بهبود Layout Inspector تعبیه شده، لطفاً بازخورد خود را برای ما ارسال کنید.

بهبودهای جدید رابط کاربری

رابط کاربری جدید اندروید استودیو ظاهر و احساسی مدرن‌تر و تمیزتر به Studio IDE می‌دهد. ما تاکنون به بازخورد شما گوش داده‌ایم و مشکلات مربوط به ویژگی‌های زیر را در Android Studio Hedgehog برطرف کرده‌ایم:

  • حالت فشرده
  • پشتیبانی از تقسیم عمودی یا افقی
  • برگه های پروژه برای macOS
  • حالت بدون حواس پرتی را رفع می کند
  • تنظیمات پیشرفته برای همیشه نمایش عملکردهای پنجره ابزار

به‌روزرسانی‌های دستیار ارتقا SDK

دستیار ارتقا SDK یک جریان جادوگر گام به گام را برای کمک به ارتقای targetSdkVersion ارائه می دهد. در اینجا به‌روزرسانی‌های دستیار ارتقا SDK در Android Studio Hedgehog آمده است:

  • تغییرات قطعی برای ارتقا به اندروید 14 را ببینید
  • فیلترهای مربوطه اضافه شد تا برخی از مراحل غیر ضروری حذف شوند
  • برای تغییرات خاص، دقیقاً در کجای کد که باید تغییرات انجام شود مشخص کنید

بهینه سازی ساخت را فقط برای سطح API هدف غیرفعال کنید

اکنون می توانید بهینه سازی IDE را برای سطح API دستگاه مورد نظر غیرفعال کنید. به طور پیش‌فرض، Android Studio زمان ساخت کلی را با تنظیم فرآیند dexing برای سطح API دستگاه هدفی که در آن مستقر می‌کنید، کاهش می‌دهد. برای خاموش کردن این ویژگی، به File > Settings > Experimental ( Android Studio > Settings > Experimental on macOS) بروید و علامت Optimize build فقط برای سطح API دستگاه مورد نظر را بردارید. توجه داشته باشید که خاموش کردن این بهینه سازی ساخت ممکن است زمان ساخت را افزایش دهد.

[فقط برای ویندوز] تأثیر نرم افزار آنتی ویروس بر سرعت ساخت را به حداقل برسانید

Build Analyzer به شما اطلاع می دهد که آیا نرم افزار آنتی ویروس ممکن است بر عملکرد ساخت شما تأثیر بگذارد. اگر نرم افزار آنتی ویروس مانند Windows Defender، دایرکتوری های مورد استفاده توسط Gradle را به صورت بلادرنگ اسکن کند، ممکن است این اتفاق بیفتد. Build Analyzer فهرستی از دایرکتوری‌ها را توصیه می‌کند تا از اسکن فعال حذف شوند و در صورت امکان، پیوندی را برای افزودن آنها به فهرست حذف پوشه Windows Defender ارائه می‌دهد.

پروژه های Eclipse Android Development Tool دیگر پشتیبانی نمی شوند

Android Studio Hedgehog و بالاتر از وارد کردن پروژه‌های Eclipse ADT پشتیبانی نمی‌کند. شما همچنان می توانید این پروژه ها را باز کنید، اما آنها دیگر به عنوان پروژه های اندروید شناخته نمی شوند. اگر نیاز به وارد کردن این نوع پروژه دارید، می توانید از نسخه قبلی Android Studio استفاده کنید. اگر نسخه‌ای از اندروید استودیو قادر به وارد کردن پروژه شما نیست، می‌توانید نسخه‌ای حتی قدیمی‌تر را امتحان کنید. هنگامی که پروژه با استفاده از نسخه قبلی اندروید استودیو به پروژه اندروید تبدیل شد، می توانید از دستیار ارتقاء AGP برای کار روی آن پروژه با استفاده از آخرین نسخه اندروید استودیو استفاده کنید.

از دستگاه های Firebase Test Lab با دستگاه های مدیریت شده Gradle استفاده کنید

هنگام استفاده از AGP 8.2.0-alpha03 یا بالاتر، می‌توانید هنگام استفاده از دستگاه‌های مدیریت‌شده Gradle، آزمایش‌های خودکار خودکار خود را در مقیاس دستگاه‌های Firebase Test Lab اجرا کنید. Test Lab به شما امکان می دهد تست های خود را به طور همزمان بر روی طیف گسترده ای از دستگاه های اندرویدی، فیزیکی و مجازی اجرا کنید. این تست ها در مراکز داده از راه دور گوگل اجرا می شوند. با پشتیبانی از دستگاه‌های مدیریت‌شده توسط Gradle (GMD)، سیستم ساخت اکنون می‌تواند به طور کامل آزمایش‌های در حال اجرا را بر اساس تنظیمات موجود در فایل‌های Gradle پروژه شما بر روی این دستگاه‌های Test Lab مدیریت کند.

با دستگاه‌های Firebase Test Lab با مدیریت Gradle شروع کنید

مراحل زیر نحوه شروع استفاده از دستگاه های Firebase Test Lab با GMD را شرح می دهد. توجه داشته باشید که این مراحل از gcloud CLI برای ارائه اعتبار کاربری استفاده می‌کنند که ممکن است برای همه محیط‌های توسعه اعمال نشود. برای اطلاعات بیشتر در مورد اینکه از چه فرآیند احراز هویت برای نیازهای خود استفاده کنید، به نحوه عملکرد اعتبارنامه پیش فرض برنامه مراجعه کنید.

  1. برای ایجاد یک پروژه Firebase، به کنسول Firebase بروید. روی افزودن پروژه کلیک کنید و اعلان های روی صفحه را برای ایجاد یک پروژه دنبال کنید. شناسه پروژه خود را به خاطر بسپارید.

  2. برای نصب Google Cloud CLI، مراحل Install the gcloud CLI را دنبال کنید.
  3. محیط محلی خود را پیکربندی کنید.
    1. پیوند به پروژه Firebase خود در gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. اجازه استفاده از اعتبار کاربری خود را برای دسترسی به API بدهید. توصیه می‌کنیم با ارسال یک فایل JSON حساب سرویس به Gradle با استفاده از DSL در اسکریپت ساخت سطح ماژول مجوز را صادر کنید:

      کاتلین 

        firebaseTestLab {
    ...
    serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
  }

      شیار 

        firebaseTestLab {
    ...
    serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
  }

      همچنین، می توانید با استفاده از دستور ترمینال زیر به صورت دستی مجوز دهید: 

        gcloud auth application-default login

    3. اختیاری: پروژه Firebase خود را به عنوان پروژه سهمیه اضافه کنید. این مرحله فقط در صورتی لازم است که از سهمیه بدون هزینه برای آزمایشگاه تست فراتر رفته باشید. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. API های مورد نیاز را فعال کنید.

    در صفحه کتابخانه Google Developers Console API ، Cloud Testing API و Cloud Tool Results API را با تایپ این نام‌های API در کادر جستجو در بالای کنسول فعال کنید و سپس روی Enable API در صفحه نمای کلی هر API کلیک کنید.

  5. پروژه اندروید خود را پیکربندی کنید.

    1. افزونه Firebase Test Lab را در اسکریپت ساخت سطح بالا اضافه کنید:

      کاتلین 

        plugins {
    ...
    id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
  }

      شیار 

        plugins {
    ...
    id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
  }

    2. انواع دستگاه های سفارشی را در فایل gradle.properties فعال کنید: 

        android.experimental.testOptions.managedDevices.customDevice=true

    3. افزونه Firebase Test Lab را در اسکریپت ساخت سطح ماژول اضافه کنید:

      کاتلین 

        plugins {
    ...
    id "com.google.firebase.testlab"
  }

      شیار 

        plugins {
    ...
    id 'com.google.firebase.testlab'
  }

    آزمایش‌هایی را روی دستگاه آزمایشگاه آزمایش Firebase با مدیریت Gradle ایجاد و اجرا کنید

    می توانید یک دستگاه Firebase Test Lab را برای Gradle تعیین کنید تا از آن برای آزمایش برنامه خود در اسکریپت ساخت سطح ماژول استفاده کند. نمونه کد زیر یک Pixel 3 را ایجاد می‌کند که API سطح 30 را به‌عنوان دستگاه آزمایشگاه آزمایشی مدیریت‌شده Gradle به نام ftlDevice اجرا می‌کند. بلوک firebaseTestLab {} زمانی در دسترس است که افزونه com.google.firebase.testlab را در ماژول خود اعمال کنید. حداقل نسخه Android Gradle Plugin پشتیبانی شده 8.2.0-alpha01 است.

    کاتلین 

    firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    شیار 

    firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    برای اجرای آزمایش‌های خود با استفاده از دستگاه‌های آزمایشگاهی با مدیریت Gradle که پیکربندی کرده‌اید، از دستور زیر استفاده کنید. device-name نام دستگاهی است که در اسکریپت ساخت Gradle خود پیکربندی کرده اید، مانند ftlDevice ، و BuildVariant نوع ساخت برنامه شما است که می خواهید آزمایش کنید. توجه داشته باشید که Gradle آزمایش‌ها را به صورت موازی اجرا نمی‌کند یا از دیگر تنظیمات Google Cloud CLI برای دستگاه‌های Test Lab پشتیبانی نمی‌کند.

    در ویندوز: 

    gradlew device-nameBuildVariantAndroidTest

    در لینوکس یا macOS: 

    ./gradlew device-nameBuildVariantAndroidTest

    خروجی تست شامل مسیری به یک فایل HTML است که دارای گزارش تست است. همچنین می‌توانید با کلیک روی Run > Test History در IDE، نتایج آزمایش را برای تجزیه و تحلیل بیشتر به Android Studio وارد کنید.

    آزمایش‌ها را روی یک گروه دستگاه ایجاد و اجرا کنید

    برای مقیاس‌بندی آزمایش خود، چندین دستگاه آزمایشگاه تست Firebase با مدیریت Gradle را به یک گروه دستگاه اضافه کنید و سپس با یک فرمان آزمایش‌ها را روی همه آن‌ها اجرا کنید. فرض کنید چندین دستگاه را به صورت زیر تنظیم کرده اید: 

    firebaseTestLab {
  managedDevices {
    create("GalaxyS23Ultra") { ... }
    create("GalaxyZFlip3") { ... }
    create("GalaxyZFold3") { ... }
    create("GalaxyTabS2") { ... }
  }
}

    برای افزودن آنها به گروه دستگاهی به نام samsungGalaxy ، از بلوک groups {} استفاده کنید: 

    firebaseTestLab {
  managedDevices {...}
}

android {
  ...
  testOptions {
    managedDevices {
      groups {
        create("samsungGalaxy") {
          targetDevices.add(devices["GalaxyS23Ultra"])
          targetDevices.add(devices["GalaxyZFlip3"])
          targetDevices.add(devices["GalaxyZFold3"])
          targetDevices.add(devices["GalaxyTabS3"])
        }
      }
    }
  }
}

    برای اجرای تست‌ها روی همه دستگاه‌های گروه دستگاه، از دستور زیر استفاده کنید:

    در ویندوز: 

    gradlew group-nameGroupBuildVariantAndroidTest

    در لینوکس یا macOS: 

    ./gradlew group-nameGroupBuildVariantAndroidTest

    اجرای آزمایشی را با اشتراک گذاری هوشمند بهینه کنید

    آزمایش بر روی دستگاه‌های آزمایشگاه تست با مدیریت Gradle اکنون از اشتراک‌گذاری هوشمند پشتیبانی می‌کند. اشتراک‌گذاری هوشمند به‌طور خودکار آزمایش‌های شما را در بین خرده‌ها توزیع می‌کند، به طوری که هر قطعه تقریباً برای یک زمان اجرا می‌شود، و تلاش‌های تخصیص دستی و مدت زمان اجرای آزمایش کلی را کاهش می‌دهد. اشتراک گذاری هوشمند از تاریخچه آزمایش شما یا اطلاعاتی در مورد مدت زمانی که آزمایش های شما قبلاً اجرا شده است استفاده می کند تا آزمایش ها را به روشی بهینه توزیع کند. توجه داشته باشید که برای استفاده از اشتراک گذاری هوشمند به نسخه 0.0.1-alpha05 پلاگین Gradle برای Firebase Test Lab نیاز دارید.

    برای فعال کردن اشتراک‌گذاری هوشمند، مدت زمان آزمایش‌های درون هر قطعه را مشخص کنید. شما باید مدت زمان خرده هدف را حداقل پنج دقیقه کمتر از timeoutMinutes تنظیم کنید تا از وضعیتی که در آن خرده‌ها قبل از پایان آزمایش‌ها لغو شوند، جلوگیری کنید. 

    firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

    برای کسب اطلاعات بیشتر، در مورد گزینه های جدید DSL بخوانید.

    DSL به روز شده برای دستگاه های آزمایشگاه تست Firebase با مدیریت Gradle

    گزینه‌های DSL بیشتری وجود دارد که می‌توانید برای کمک به سفارشی‌سازی آزمایش‌های خود یا مهاجرت از راه‌حل‌های دیگری که ممکن است قبلاً استفاده می‌کنید، پیکربندی کنید. برخی از این گزینه ها را همانطور که در قطعه کد زیر توضیح داده شده است مشاهده کنید. 

    firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       * 
       * Default to 0 for no sharding.
       */
      numUniformShards = 20

      /**
      * For smart sharding, the target length of time each shard should takes in
      * minutes. Maxes out at 50 shards for physical devices and 100 shards for
      * virtual devices.
      *
      * Only one of numUniformShards or targetedShardDurationMinutes can be set.
      *
      * Defaults to 0 for no smart sharding.
      */
      targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
    }
  }
}