Gradle से मैनेज किए जाने वाले डिवाइसों से, जांच का दायरा बढ़ाएं

Gradle से मैनेज किए जाने वाले डिवाइस, डिवाइसों के एक जैसे होने, परफ़ॉर्मेंस, और भरोसा बनाए रखने में मदद करते हैं का इस्तेमाल करने के लिए किया जा सकता है. यह सुविधा, एपीआई लेवल 27 और इससे आपको वर्चुअल या रिमोट फ़िज़िकल टेस्ट डिवाइसों को कॉन्फ़िगर करने की सुविधा मिलती है प्रोजेक्ट की Gradle फ़ाइलें होती हैं. बिल्ड सिस्टम, कॉन्फ़िगरेशन का पूरी तरह से इस्तेमाल करता है, अपने डिवाइस पर लागू करते समय उन डिवाइसों को मैनेज करना, डिप्लॉय करना, और अलग करना ऑटोमेटेड टेस्ट के बारे में बताया गया है.

इस सुविधा की मदद से, Gradle को सिर्फ़ आपके मौजूदा टेस्ट के साथ-साथ, साथ ही, डिवाइसों का लाइफ़साइकल भी होता है. इससे, आपके प्रॉडक्ट की क्वालिटी बेहतर होती है से इन तरीकों का इस्तेमाल करके टेस्ट किया जा सकता है:

  • यह सुविधा, डिवाइस से जुड़ी समस्याओं को मैनेज करती है, ताकि यह पक्का किया जा सके कि जांच सही तरीके से पूरी हो रही है
  • वर्चुअल डिवाइसों के लिए, डिवाइस के स्टार्टअप समय को बेहतर बनाने के लिए एम्युलेटर स्नैपशॉट का इस्तेमाल किया जाता है और मेमोरी के इस्तेमाल को कंट्रोल करने के साथ-साथ, टेस्ट के बीच डिवाइसों को वापस पहले जैसा करने की सुविधा पाएं
  • कैश मेमोरी में सेव जांच के नतीजे और सिर्फ़ उन जांच को फिर से चलाता है जो अलग-अलग नतीजे दे सकती हैं नतीजे
  • यह टेस्ट करने के लिए, एक जैसा एनवायरमेंट देता है रिमोट तरीके से टेस्ट करें

Gradle से मैनेज किया जाने वाला वर्चुअल डिवाइस बनाना

एक ऐसा वर्चुअल डिवाइस तय किया जा सकता है जिसका इस्तेमाल Gradle, ऐप्लिकेशन मौजूद है. नीचे दिया गया कोड सैंपल Pixel 2 बनाता है एपीआई लेवल 30 को Gradle से मैनेज किए जाने वाले डिवाइस के तौर पर चला रहा हो.

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

ग्रूवी

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

डिवाइसों के ग्रुप तय करना

आपके टेस्ट को कई डिवाइस कॉन्फ़िगरेशन में इस्तेमाल करने में मदद करना, जैसे कि यह अलग-अलग एपीआई लेवल और डिवाइस के नाप या आकार के लिए होता है. Gradle से मैनेज की जाने वाली कई डिवाइसों को नाम वाले किसी ग्रुप में जोड़ें. इसके बाद, Gradle आपके सभी टेस्ट को एक्ज़ीक्यूट कर पाएगा ग्रुप के सभी डिवाइस एक साथ चलाने होंगे.

नीचे दिए गए उदाहरण में, एक डिवाइस ग्रुप में जोड़े गए दो डिवाइस दिखाए गए हैं. phoneAndTablet.

Kotlin

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

ग्रूवी

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

जांच करना

Gradle से मैनेज किए गए जिन डिवाइसों को आपने कॉन्फ़िगर किया है उनका इस्तेमाल करके जांच करने के लिए, आदेश दिखाई देगा. device-name उस डिवाइस का नाम है जिसे आपने कॉन्फ़िगर किया है आपकी Gradle बिल्ड स्क्रिप्ट (जैसे कि pixel2api30) का है और BuildVariant अपने ऐप का वह वर्शन बनाएं जिसका आप परीक्षण करना चाहते हैं.

Windows पर:

gradlew device-nameBuildVariantAndroidTest

Linux या macOS पर:

./gradlew device-nameBuildVariantAndroidTest

Gradle से मैनेज किए जाने वाले डिवाइसों के ग्रुप पर जांच चलाने के लिए, इसका इस्तेमाल करें को कमांड देना होगा.

Windows पर:

gradlew group-nameGroupBuildVariantAndroidTest

Linux या macOS पर:

./gradlew group-nameGroupBuildVariantAndroidTest

टेस्ट आउटपुट में, ऐसी एचटीएमएल फ़ाइल का पाथ शामिल होता है जिसमें टेस्ट रिपोर्ट होती है. आपने लोगों तक पहुंचाया मुफ़्त में Android Studio में टेस्ट के नतीजे भी इंपोर्ट कर सकते हैं, ताकि Run > आईडीई में की जांच का इतिहास.

परीक्षण शार्डिंग सक्षम करें

Gradle से मैनेज किए जाने वाले डिवाइस, टेस्ट शार्डिंग की सुविधा देते हैं, जिससे आप अपने टेस्ट को अलग-अलग कर सकते हैं सुइट की संख्या एक जैसी कई वर्चुअल डिवाइस इंस्टेंस पर लागू होती है. इन्हें शर्ड कहा जाता है. जो साथ-साथ चलते हैं. टेस्ट शार्डिंग का इस्तेमाल करने से, पूरे टेस्ट एक्ज़िक्यूशन को कम करने में मदद मिल सकती है ज़्यादा कंप्यूटेशनल रिसॉर्स बनाने में खर्चा हो रहा है.

दिए गए टेस्ट रन में आपको जिन शार्ड का इस्तेमाल करना है उन्हें सेट करने के लिए आपकी gradle.properties फ़ाइल में फ़ॉलो किया जा रहा है:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

इस विकल्प का इस्तेमाल करके टेस्ट करते समय, Gradle से मैनेज किए जाने वाले डिवाइस, शार्ड की संख्या जिसे आपने टेस्ट रन के दौरान हर डिवाइस प्रोफ़ाइल के लिए तय किया है. इसलिए, उदाहरण के लिए, अगर आपने अपने टेस्ट को तीन डिवाइसों के ग्रुप में डिप्लॉय किया है और numManagedDeviceShards से दो, Gradle की मदद से मैनेज किए जाने वाले डिवाइस, छह वर्चुअल डिवाइस का इस्तेमाल कर सकते हैं.

आपके टेस्ट पूरे होने पर, Gradle, टेस्ट के नतीजों को .proto फ़ाइल में उपलब्ध कराता है का इस्तेमाल करें.

ऑटोमेटेड टेस्ट डिवाइस इस्तेमाल करना

Gradle से मैनेज किए जाने वाले डिवाइस, ऑटोमेटेड मशीन नाम के एम्युलेटर डिवाइस के साथ काम करते हैं टेस्ट डिवाइस (एटीडी), जिसे सीपीयू और मेमोरी संसाधनों को कम करने के लिए ऑप्टिमाइज़ किया गया है इंस्ट्रुमेंट्ड टेस्ट चलाना हो सकता है. एटीडी, रनटाइम की परफ़ॉर्मेंस को कई तरीकों से बेहतर बनाते हैं:

  • पहले से इंस्टॉल किए गए ऐसे ऐप्लिकेशन हटाएं जो आम तौर पर आपके ऐप्लिकेशन की जांच करने के लिए काम के नहीं होते
  • ऐसी कुछ बैकग्राउंड सेवाएं बंद करें जो आम तौर पर इनके लिए काम की नहीं होतीं ऐप्लिकेशन को टेस्ट किया जा रहा है
  • हार्डवेयर रेंडरिंग बंद करें

शुरू करने से पहले, पक्का करें कि Android Emulator को नए वर्शन में अपडेट करें उपलब्ध वर्शन है. इसके बाद, "-atd" लिखें Gradle से मैनेज की जाने वाली सेटिंग तय करते समय इमेज डिवाइस में ट्रांसफ़र कर सकते हैं, जैसा कि नीचे दिखाया गया है:

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

ग्रूवी

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

अन्य उपयोगकर्ताओं की तरह ही डिवाइस ग्रुप भी बनाए जा सकते हैं ऐसे डिवाइस जिन्हें Gradle मैनेज करता है. परफ़ॉर्मेंस को बेहतर बनाने के लिए, आपको कुल टेस्ट को कम करने के लिए, टेस्ट शार्डिंग के साथ एटीडी का भी इस्तेमाल किया जा सकता है आपके टेस्ट सुइट को लागू करने का समय.

ATD इमेज से क्या हटाया जाता है?

हेडलेस (सिर्फ़ बैक-एंड पर काम करने की सुविधा) मोड में काम करने के अलावा, ATDs उन ऐप्लिकेशन और सेवाओं को हटाना या बंद करना जो आम तौर पर इन कामों के लिए ज़रूरी नहीं होते कोड की जांच करना. नीचे दी गई टेबल, कॉम्पोनेंट के बारे में खास जानकारी देती है हमने ATD इमेज को हटा दिया है या बंद कर दिया है. साथ ही, इसमें यह भी बताया गया है कि वे उपयोगी होते हैं.

ATD इमेज से क्या हटाया जाता है अपने-आप होने वाली जांच के दौरान, आपको इसकी ज़रूरत क्यों नहीं होगी
Google प्रॉडक्ट ऐप्लिकेशन:
  • ईमेल भेजें
  • Maps
  • Chrome
  • मैसेज
  • Play Store और अन्य ऐप्लिकेशन
 यह मानते हुए कि अपने-आप होने वाले टेस्ट में ऐप्लिकेशन के लॉजिक पर ही फ़ोकस होना चाहिए दूसरे ऐप्लिकेशन या प्लैटफ़ॉर्म सही तरीके से काम करेंगे.

Espresso-Intents की मदद से, आपको अपने आउटगोइंग इंटेंट मैच करने और उनकी पुष्टि करने की सुविधा मिलती है. इसके अलावा, स्टब भी दिया जा सकता है वास्तविक इंटेंट रिस्पॉन्स की जगह पर जवाब दिया जाता है.

सेटिंग ऐप्लिकेशन और सेवाएं:
  • मोबाइल और इंटरनेट सेवा देने वाली कंपनी का कॉन्फ़िगरेशन
  • आपातकालीन जानकारी
  • एक बार शुरू करने वाला
  • फ़ोटोटेबल (स्क्रीनसेवर)
  • प्रॉविज़न
  • सेटिंग ऐप्लिकेशन
  • स्टोरेज मैनेजर
  • Telephony का एपीएन कॉन्फ़िगरेशन
  • वॉलपेपरक्रॉपर
  • वॉलपेपर पिकर
 ये ऐप्लिकेशन, असली उपयोगकर्ताओं के लिए एक जीयूआई उपलब्ध कराते हैं, ताकि वे अपना प्लैटफ़ॉर्म बदल सकें डिवाइस की सेटिंग मैनेज करें, डिवाइस सेट अप करें या डिवाइस का स्टोरेज मैनेज करें. आम तौर पर, यह को ऐप्लिकेशन-लेवल की ऑटोमेटेड टेस्टिंग के दायरे से बाहर रखा गया है.


अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है ध्यान दें: सेटिंग की सेवा देने वाली कंपनी ATD इमेज में अभी भी उपलब्ध है.

सिस्टम यूआई यह मानते हुए कि अपने-आप होने वाले टेस्ट में ऐप्लिकेशन के लॉजिक पर ही फ़ोकस होना चाहिए दूसरे ऐप्लिकेशन या प्लैटफ़ॉर्म सही तरीके से काम करेंगे.
AOSP ऐप्लिकेशन और सेवाएं:
  • ब्राउज़र2
  • Calendar
  • Camera2
  • संपर्क
  • Dialer
  • डेस्कक्लॉक
  • गैलरी2
  • लैटिनआईएमई
  • लॉन्चर3QuickStep
  • संगीत
  • क्विकसर्चबॉक्स
  • SettingsIntelligence
 आम तौर पर, ये ऐप्लिकेशन और सेवाएं ऑटोमेटेड कोड की जांच करता है.

Firebase टेस्ट लैब वाले डिवाइसों का इस्तेमाल करना

Firebase टेस्ट पर बड़े पैमाने पर अपने-आप इंस्ट्रुमेंट वाले टेस्ट चलाए जा सकते हैं Lab डिवाइसों का इस्तेमाल करते समय ऐसे डिवाइस जिन्हें Gradle मैनेज करता है. टेस्ट लैब से, आपको टेस्ट को एक साथ चलाने के लिए यह कई तरह के Android डिवाइसों की सूची उपलब्ध कराती है. इसमें फ़िज़िकल और वर्चुअल, दोनों तरह के डिवाइस शामिल हैं. ये टेस्ट रिमोट Google डेटा सेंटर. Gradle से मैनेज किए जाने वाले डिवाइसों की मदद से, बिल्ड सिस्टम, इन टेस्ट लैब डिवाइसों पर चल रहे टेस्ट को पूरी तरह से मैनेज कर सकता है. ये स्टैंडर्ड कॉन्फ़िगरेशन.

शुरू करें

नीचे दिए गए चरण, ऐसे डिवाइस जिन्हें Gradle मैनेज करता है. ध्यान दें कि इन चरणों में, उपयोगकर्ता को उपलब्ध कराने के लिए gcloud सीएलआई का इस्तेमाल किया जाता है क्रेडेंशियल, जो शायद सभी डेवलपमेंट एनवायरमेंट पर लागू न हो. ज़्यादा के लिए आपकी ज़रूरतों के लिए पुष्टि करने की कौनसी प्रोसेस का इस्तेमाल किया जाए, इसके बारे में जानने के लिए, कैसे ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल काम करता है.

  1. Firebase प्रोजेक्ट बनाने के लिए, यहां जाएं Firebase कंसोल. क्लिक करें प्रोजेक्ट जोड़ें और कोई प्रोजेक्ट बनाने के लिए स्क्रीन पर दिए गए निर्देशों का पालन करें. अपना प्रोजेक्ट आईडी याद रखें.

  2. Google Cloud सीएलआई को इंस्टॉल करने के लिए, gcloud सीएलआई इंस्टॉल करें.

  3. अपने लोकल एनवायरमेंट को कॉन्फ़िगर करें.

    1. gcloud में अपने Firebase प्रोजेक्ट को लिंक करें:

      gcloud config set project FIREBASE_PROJECT_ID

    2. एपीआई ऐक्सेस के लिए, अपने उपयोगकर्ता क्रेडेंशियल के इस्तेमाल की अनुमति दें. हमारा सुझाव है कि आप: इसके लिए, सेवा खाते की JSON फ़ाइल को Gradle में जोड़ें. इसके लिए: मॉड्यूल-लेवल बिल्ड स्क्रिप्ट में DSL:

      Kotlin

      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. ज़रूरी एपीआई चालू करें.

    इस Google Developers Console एपीआई लाइब्रेरी पेज, Cloud Testing API चालू करें और Cloud Tool के खोज के नतीजे एपीआई कंसोल के सबसे ऊपर खोज बॉक्स में एपीआई के ये नाम टाइप करें. इसके बाद, एपीआई चालू करें पर क्लिक करें हर एपीआई के बारे में खास जानकारी देने वाले पेज पर.

  5. अपने Android प्रोजेक्ट को कॉन्फ़िगर करें.

    1. टॉप-लेवल बिल्ड स्क्रिप्ट में Firebase टेस्ट लैब प्लग इन जोड़ें:

      Kotlin

      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 टेस्ट लैब प्लग इन जोड़ें:

      Kotlin

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

      ग्रूवी

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

एक टेस्ट लैब डिवाइस तय करें

Gradle के लिए, Firebase टेस्ट लैब डिवाइस तय किया जा सकता है, ताकि आप ऐप्लिकेशन मौजूद है. नीचे दिया गया कोड सैंपल एक एपीआई लेवल 30 को Gradle से मैनेज किए जाने वाले टेस्ट लैब डिवाइस के तौर पर इस्तेमाल कर रहा Pixel 3 ftlDevice. firebaseTestLab {} ब्लॉक तब उपलब्ध होता है, जब आप आपके मॉड्यूल के लिए com.google.firebase.testlab प्लगिन.

Kotlin

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

ग्रूवी

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

Gradle से मैनेज किए जाने वाले डिवाइसों का ग्रुप तय करने के लिए, जिनमें Firebase टेस्ट लैब वाले डिवाइस शामिल हैं, डिवाइसों के ग्रुप तय करना देखें.

जांच करने के लिए, उन निर्देशों का इस्तेमाल करें जिनका इस्तेमाल Gradle की मदद से मैनेज किए जाने वाले अन्य ऐप्लिकेशन चलाने के लिए किया जाता था डिवाइस में बदल सकते हैं. ध्यान दें कि Gradle, टेस्ट को साथ-साथ या सही तरीके से नहीं चलाता है टेस्ट लैब वाले डिवाइसों के लिए, Google Cloud के अन्य सीएलआई कॉन्फ़िगरेशन.

स्मार्ट शार्डिंग की मदद से टेस्ट रन ऑप्टिमाइज़ करें

Gradle से मैनेज किए जाने वाले टेस्ट लैब डिवाइसों पर टेस्टिंग, स्मार्ट शार्डिंग की सुविधा का इस्तेमाल करती है. स्मार्ट कैंपेन शार्डिंग अपने आप आपके परीक्षणों को शार्ड में इस तरह वितरित करती है कि प्रत्येक शार्ड करीब-करीब एक ही समय पर काम करती है. इससे मैन्युअल तरीके से बजट असाइन करने में कम समय लगता है और टेस्ट चलाने की कुल अवधि. स्मार्ट शार्डिंग आपके परीक्षण इतिहास या जानकारी का उपयोग करती है इससे पता चलता है कि पहले आपके टेस्ट को कितना समय लगा था. सबसे सही तरीका है. ध्यान दें कि आपको Gradle प्लग इन के 0.0.1-alpha05 वाला वर्शन चाहिए Firebase टेस्ट लैब के लिए बनाया है.

स्मार्ट शार्डिंग चालू करने के लिए, हर शार्ड के अंदर टेस्ट की अवधि तय करें लेना चाहिए. आपको लक्षित शार्ड समय अवधि को कम से कम पांच पर सेट करना चाहिए शार्ड वाली स्थिति से बचने के लिए timeoutMinutes से मिनट कम रद्द कर दिया जाता है.

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

ज़्यादा जानने के लिए, Firebase टेस्ट लैब डिवाइस के डीएसएल के विकल्प.

टेस्ट लैब वाले डिवाइसों के लिए 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
  }
}