Android Studio हेजहॉग | 1.1.2023 (नवंबर 2023)

Android Studio Hedgehog में ये नई सुविधाएं जोड़ी गई हैं.

IntelliJ IDEA 2023.1 प्लैटफ़ॉर्म के बारे में अपडेट

Android Studio Hedgehog में IntelliJ IDEA 2023.1 के अपडेट शामिल हैं. इन अपडेट से, Studio IDE का अनुभव पाने के लिए. बदलावों के बारे में जानकारी के लिए, यहां देखें: IntellaJ IDEA 2023.1 के प्रॉडक्ट की जानकारी.

ऐप्लिकेशन की क्वालिटी से जुड़ी अहम जानकारी में, 'Android की ज़रूरी जानकारी' का विश्लेषण करें

ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी में अब ये चीज़ें शामिल हैं Android की ज़रूरी जानकारी का डेटा, ताकि आप इसे ज़्यादा आसानी से ऐक्सेस कर सकें Google Play की ओर से इकट्ठा की गई मुख्य मेट्रिक और उपयोगकर्ता अनुभव को बेहतर बनाने के लिए किया जाता है. इस्तेमाल की जाने वाली चीज़ें 'Android की ज़रूरी जानकारी' की मदद से, ऐप्लिकेशन के क्रैश या फ़्रीज़ होने से जुड़ी समस्याओं को हल करें. इससे, आपके ऐप्लिकेशन को बेहतर बनाने में मदद मिलेगी Google Play पर आपके ऐप्लिकेशन की क्वालिटी कैसी होती है.

'Android की ज़रूरी जानकारी' से जुड़ी समस्याएं देखने और उन्हें फ़िल्टर करने के साथ-साथ, स्टैक ट्रेस से सीधे इस पर जाएं ऐप्लिकेशन की क्वालिटी से जुड़ी अहम जानकारी टूल विंडो से कोड पाएं. शुरू करने के लिए, फ़ॉलो करें यह तरीका अपनाएं:

  1. प्रोफ़ाइल आइकॉन का इस्तेमाल करके Android Studio में अपने डेवलपर खाते में साइन इन करें में टूलबार के आखिर में मौजूद होता है.
  2. इसमें मौजूद टूल विंडो पर क्लिक करके, ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी खोलें Android Studio या View > टूल की विंडो > ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी.
  3. ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी में, Android की ज़रूरी जानकारी टैब पर क्लिक करें.

'Android की ज़रूरी जानकारी' और Crashlytics से मिले डेटा में अंतर

ध्यान दें कि 'Android की ज़रूरी जानकारी' और Crashlytics, 'Android की ज़रूरी जानकारी' के लिए अलग-अलग वैल्यू रिपोर्ट कर सकते हैं क्रैश होने से जुड़े उपयोगकर्ताओं और इवेंट की संख्या. ये अंतर ऐसा इसलिए होता है, क्योंकि Play और Crashlytics, ऐप्लिकेशन क्रैश होने की जानकारी अलग-अलग समय पर और अलग-अलग उपयोगकर्ता अनुभव करते हैं. Play और Crashlytics की मदद से, इन वजहों को समझा जा सकता है संख्या में अंतर हो सकता है:

  • Play ने बूट के समय शुरू होने वाले क्रैश का पता लगाया, जबकि Crashlytics को गेम कैच किया गया Crashlytics SDK टूल के शुरू होने के बाद होने वाले क्रैश.
  • अगर कोई व्यक्ति नया फ़ोन खरीदने के बाद, क्रैश रिपोर्ट से ऑप्ट आउट करता है, तो Play को रिपोर्ट नहीं किए जाते; हालांकि, Crashlytics, किसी ऐप्लिकेशन की खुद की निजता नीति चुनें.

नया पावर प्रोफ़ाइलर

Android Studio Hedgehog की शुरुआत में, पावर प्रोफ़ाइलर बिजली की खपत की जानकारी दिखाता है डिवाइसों पर. इस नए डेटा को ऑन डिवाइस पावर रेल मॉनिटर (ओडीपीएम) में देखा जा सकता है. ओडीपीएम, डेटा को पावर रेल नाम के सबसिस्टम के हिसाब से बांटता है. प्रोफ़ाइल बनाने लायक पावर रेल देखें देखें.

सिस्टम ट्रेस ऊर्जा की खपत के डेटा को रिकॉर्ड और दिखाता है. यह सीपीयू प्रोफ़ाइलर का हिस्सा है. पावर की तुलना करने के लिए, इस डेटा से आपको ऐप्लिकेशन में होने वाली कार्रवाइयों के साथ डिवाइस के इस्तेमाल का डेटा. पावर प्रोफ़ाइलर की मदद से, इस डेटा को विज़ुअलाइज़ किया जा सकता है.

नया पावर प्रोफ़ाइलर

नए पावर प्रोफ़ाइलर से डेटा देखने के लिए, Pixel 6 या इसके बाद के वर्शन वाले फ़ोन पर सिस्टम ट्रेस करें डिवाइस:

  1. देखें > टूल की विंडो > प्रोफ़ाइलर.
  2. सीपीयू प्रोफ़ाइलर खोलने के लिए, सीपीयू टाइमलाइन पर कहीं भी क्लिक करें और सिस्टम ट्रेस शुरू करें.

नए ऐप्लिकेशन लिंक के लिए Assistant में, डीप लिंक के बारे में खास जानकारी उपलब्ध है अपने ऐप्लिकेशन में सेट अप करें. Assistant, ऐप्लिकेशन के सभी मौजूदा डीप लिंक दिखाती है AndroidManifest.xml फ़ाइल से पता चलता है कि उन डीप फ़ाइलों का कॉन्फ़िगरेशन लिंक सही है और कॉन्फ़िगरेशन से जुड़ी गड़बड़ियां.

ऐप्लिकेशन लिंक Assistant खोलने के लिए, टूल > इसमें ऐप्लिकेशन लिंक असिस्टेंट Android Studio. ऐप्लिकेशन लिंक के बारे में ज़्यादा जानकारी के लिए, यहां देखें Android ऐप्लिकेशन के लिंक जोड़ना.

'लाइव बदलाव' के लिए, मैन्युअल मोड का शॉर्टकट अपडेट किया गया

Android में लाइव एडिट Studio Hedgehog में मैन्युअल मोड के लिए एक नया शॉर्टकट जोड़ा गया है (मैन्युअल तरीके से पुश करें): Control+\ (macOS के लिए Command+\). मैन्युअल मोड मददगार है आप उन स्थितियों में सटीक कंट्रोल पाना चाहते हों जिनमें अपडेट चल रहे ऐप्लिकेशन में डिप्लॉय किया गया है. उदाहरण के लिए, अगर आपको बड़े पैमाने पर नहीं करना चाहते और आप चाहते हैं कि फ़ाइल में कोई मध्यवर्ती स्थिति न दिखे डिवाइस. मैन्युअल तरीके से पुश करें और सेव करने पर मैन्युअल तरीके से पुश करें में से किसी एक को चुना जा सकता है ऐसा करने के लिए, 'लाइव एडिट' सेटिंग का इस्तेमाल करें या 'लाइव एडिट करें' यूज़र इंटरफ़ेस (यूआई) इंडिकेटर का इस्तेमाल करें. ज़्यादा के लिए जानकारी, Jetpack के लिए लाइव एडिट की सुविधा में वीडियो क्लिप देखें लिखें.

मल्टीझलक टेंप्लेट कंपोज़ करें

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ नया पेश करता है Multipreview API टेंप्लेट: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark, और @PreviewDynamicColors, ताकि एक एकल एनोटेशन के साथ आप सामान्य स्थितियों में अपने कंपोज़ यूज़र इंटरफ़ेस (यूआई) की झलक देखें.

Android Studio Hedgehog में, एक नया गैलरी मोड पेश किया गया है प्रीव्यू कंपोज़ करें. इससे आपको एक बार में सिर्फ़ एक प्रीव्यू पर फ़ोकस करने में मदद मिलेगी और इससे रेंडर होने में लगने वाले समय की बचत होती है. हम गैलरी मोड इस्तेमाल करने का सुझाव देते हैं जब आपको अपने ऐप्लिकेशन का यूज़र इंटरफ़ेस (यूआई) दोहराना हो और किसी दूसरे मोड पर स्विच करना हो, उदाहरण के लिए, जब आपको यूज़र इंटरफ़ेस (यूआई) के वैरिएंट देखने हों, तब ग्रिड या सूची का इस्तेमाल करें.

डीबगर में स्थिति की जानकारी लिखें

जब आपके Compose के यूज़र इंटरफ़ेस (यूआई) के कुछ हिस्से अचानक फिर से दिखते हैं, तो कभी-कभी उनमें मुश्किल होती है इसकी वजह समझने के लिए. अब, कंपोज़ेबल फ़ंक्शन पर ब्रेकपॉइंट सेट करते समय, डीबगर, कंपोज़ेबल और उनके पैरामीटर की सूची बनाता है ताकि आप उन बदलावों की वजह आसानी से समझ सकें शॉर्ट वीडियो में बदलाव करना. उदाहरण के लिए, जब कंपोज़ेबल पर रोका जाता है, तो डीबगर आपको यह बताता है कि किन पैरामीटर में "बदलाव" हुआ है या "इसमें कोई बदलाव न किया गया हो", ताकि आप उन्हें दोबारा बनाने की वजह की ज़्यादा बेहतर ढंग से जांच कर सकें.

डिवाइस का डुप्लीकेट वर्शन

अब चल रहे डिवाइस विंडो में, अपने डिवाइस का डुप्लीकेट वर्शन बनाया जा सकता है: Android Studio. अपने डिवाइस के डिसप्ले को सीधे Android Studio पर स्ट्रीम करके, सामान्य कार्रवाइयां पूरी की जा सकती हैं. जैसे, ऐप्लिकेशन शुरू करना और उनसे इंटरैक्ट करना, स्क्रीन को घुमाना, फ़ोन को फ़ोल्ड और अनफ़ोल्ड करना, वॉल्यूम कम या ज़्यादा करना, और स्टूडियो आईडीई से ही जाना जा सकता है.

डिवाइस मिररिंग की सुविधा तब ही उपलब्ध होती है, जब ऐसे कंप्यूटर जिनमें यूएसबी या वायरलेस तरीके से डीबग करने की सुविधा चालू हो. इसे चालू और बंद किया जा सकता है चल रहे डिवाइस विंडो का इस्तेमाल करके डुप्लीकेट डिवाइस बनाने की सुविधा या डिवाइस मैनेजर (देखें > टूल Windows > डिवाइस मैनेजर). आप यह भी कर सकते हैं डिवाइस की सेटिंग में जाकर, डुप्लीकेट वर्शन बनाने की सुविधा चालू करें (सेटिंग > टूल > डिवाइस मिररिंग).

चल रहे डिवाइसों का यूज़र इंटरफ़ेस (यूआई)

पहले से मालूम समस्याएं

ऐसा हो सकता है कि कुछ डिवाइस, YouTube TV के साथ काम करने के लिए ज़रूरी बिटरेट पर एन्कोडिंग न कर पाएं डिवाइस मिररिंग. इन स्थितियों में, आपको दौड़ने की प्रक्रिया में गड़बड़ी दिखाई दे सकती है डिवाइस विंडो और साथ ही ऐसे लॉग देखें जो नीचे दिखाए गए लॉग से मिलते-जुलते हैं.

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 बातचीत करने के लिए ऐसे चैनल का इस्तेमाल करता है जिसे एन्क्रिप्ट (सुरक्षित) नहीं किया गया है के लिए है, इसलिए डुप्लीकेट जानकारी को दूसरे उपयोगकर्ता ऐक्सेस कर सकते हैं होस्ट मशीन पर.

हार्डवेयर इनपुट फ़ॉरवर्ड करने की सुविधा

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

सीधे चल रहे डिवाइस की विंडो से, डिवाइसों को मैनेज करें

अब Android वर्चुअल डिवाइस (एवीडी) को चालू किया जा सकता है या किसी फ़िज़िकल डिवाइस को डाउनलोड करने के लिए, चल रहे डिवाइस विंडो से + आइकॉन पर क्लिक करके किसी डिवाइस को चुना जा रहा है. एवीडी को रोकने या स्क्रीन का डुप्लीकेट वर्शन बनाने का तरीका डिवाइस, डिवाइस टैब बंद करें.

चल रहे डिवाइस से डिवाइस ड्रॉप-डाउन

एम्बेड किए गए लेआउट इंस्पेक्टर

Android Studio Hedgehog Canary 2 की शुरुआत के साथ, लेआउट इंस्पेक्टर चल रहे डिवाइस टूल विंडो. प्रयोग के तौर पर शुरू की गई यह सुविधा स्क्रीन पर असल में जगह बचाती है एस्टेट और एक ही टूल विंडो में आपके यूज़र इंटरफ़ेस (यूआई) के डीबगिंग वर्कफ़्लो को व्यवस्थित करने में मदद करता है. तय सीमा में इस मोड में, व्यू हैरारकी (व्यू और व्यू ग्रुप के लेआउट का क्रम) दिखाया जा सकता है. अन्य सामान्य लेआउट इंस्पेक्टर की सुविधाओं को देख और ऐक्सेस कर सकते है. पूरे सेट को ऐक्सेस करने के लिए के अलग-अलग विकल्प हैं, तो आपको अब भी एक स्टैंडअलोन विंडो में लेआउट इंस्पेक्टर चलाना होगा (Windows पर फ़ाइल > सेटिंग > एक्सपेरिमेंटल > लेआउट इंस्पेक्टर या Android स्टूडियो > सेटिंग > एक्सपेरिमेंटल > macOS पर Layout Inspector).

एम्बेड किए गए लेआउट इंस्पेक्टर की एक सीमा यह है कि 3D मोड सिर्फ़ यहां उपलब्ध है स्नैपशॉट.

एम्बेड किए गए लेआउट इंस्पेक्टर को बेहतर बनाने में हमारी मदद करने के लिए, कृपया हमें सुझाव/राय दें या शिकायत करें.

यूज़र इंटरफ़ेस (यूआई) में नए सुधार

कॉन्टेंट बनाने नया यूज़र इंटरफ़ेस (यूआई) Android Studio के लिए, Android Studio को ज़्यादा मॉडर्न और साफ़-सुथरा किया गया है आईडीई. हमने अब तक आपके सुझाव पर गौर किया है. साथ ही, हमने Android Studio Hedgehog में ये सुविधाएं शामिल की गई हैं:

  • कॉम्पैक्ट मोड
  • वर्टिकल या हॉरिज़ॉन्टल तौर पर बांटने की सुविधा
  • macOS के लिए प्रोजेक्ट टैब
  • ध्यान भटकाने वाले मोड को ठीक करने की सुविधा
  • टूल विंडो की कार्रवाइयों को हमेशा दिखाने के लिए बेहतर सेटिंग

SDK टूल अपग्रेड असिस्टेंट से जुड़े अपडेट

SDK अपग्रेड असिस्टेंट आपकी मदद करने के लिए, सिलसिलेवार तरीक़े से विज़र्ड फ़्लो targetSdkVersion अपग्रेड करें. Android Studio में SDK टूल अपग्रेड असिस्टेंट से जुड़े अपडेट यहां दिए गए हैं हेजहॉग:

  • Android 14 में अपग्रेड करने से जुड़े नुकसान पहुंचा सकने वाले बदलाव देखें
  • ज़रूरत के मुताबिक फ़िल्टर जोड़े गए हैं, ताकि कुछ ग़ैर-ज़रूरी चरण हटा दिए गए हों
  • कुछ बदलावों के लिए, सटीक तौर पर बताएं कि बदलाव कोड में कहां होने चाहिए बनाया गया

सिर्फ़ टारगेट एपीआई लेवल के लिए बिल्ड ऑप्टिमाइज़ेशन बंद करें

अब टारगेट किए गए डिवाइस के एपीआई लेवल के लिए, IDE ऑप्टिमाइज़ेशन को बंद किया जा सकता है. इन्होंने बदलाव किया है डिफ़ॉल्ट रूप से, Android Studio आपके डिवाइस की डेक्सिंग सुविधा के हिसाब से, बिल्ड में लगने वाला कुल समय कम करता है ऐप्लिकेशन को जिस टारगेट डिवाइस पर डिप्लॉय किया जा रहा है उसके एपीआई लेवल के लिए प्रोसेस. इसे चालू करने के लिए सुविधा को बंद करने के लिए, फ़ाइल > सेटिंग > एक्सपेरिमेंट के तौर पर उपलब्ध (Android Studio > सेटिंग > macOS पर प्रयोग के तौर पर उपलब्ध है और Optimize के टारगेट के लिए बिल्ड हटाएं' से सही का निशान हटाएं सिर्फ़ डिवाइस के एपीआई लेवल पर सेट किए जा सकते हैं. ध्यान दें कि इस बिल्ड ऑप्टिमाइज़ेशन को बंद करने से बिल्ड का समय बढ़ाने में मदद मिलती है.

[सिर्फ़ Windows के लिए] बिल्ड स्पीड पर एंटीवायरस सॉफ़्टवेयर के असर को कम करें

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

Eclipse Android डेवलपमेंट टूल प्रोजेक्ट अब काम नहीं करते

Android Studio Hedgehog और उसके बाद के वर्शन पर, Eclipse ADT को इंपोर्ट नहीं किया जा सकता प्रोजेक्ट. आपके पास अब भी ये प्रोजेक्ट खोलने का विकल्प है. हालांकि, ये प्रोजेक्ट अब काम नहीं कर रहे हैं Android प्रोजेक्ट के तौर पर पहचाना जाता है. अगर आपको इस तरह का प्रोजेक्ट इंपोर्ट करना है, तो Android Studio के पुराने वर्शन का इस्तेमाल किया जा सकता है. यदि Android का कोई वर्शन दिया गया हो Studio आपका प्रोजेक्ट इंपोर्ट नहीं कर पा रहा है. आप चाहें, तो किसी इवेंट के लिए भी . प्रोजेक्ट को Android प्रोजेक्ट में बदलने के बाद, वर्शन है, तो काम करने के लिए AGP अपग्रेड असिस्टेंट का इस्तेमाल किया जा सकता है Android Studio के सबसे नए वर्शन का इस्तेमाल करके उस प्रोजेक्ट पर

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

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

Gradle से मैनेज किए जाने वाले Firebase टेस्ट लैब डिवाइसों का इस्तेमाल शुरू करना

नीचे दिए गए चरण, जीएमडी. ध्यान दें कि ये चरण उपयोगकर्ता क्रेडेंशियल देने के लिए 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 टेस्ट लैब डिवाइस पर जांच बनाना और चलाना

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

    Kotlin

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

    ग्रूवी

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

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

    Windows पर:

    gradlew device-nameBuildVariantAndroidTest
    

    Linux या macOS पर:

    ./gradlew device-nameBuildVariantAndroidTest
    

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

    डिवाइस ग्रुप पर टेस्ट बनाना और चलाना

    अपने ऐप्लिकेशन की टेस्टिंग को स्केल करने के लिए, Gradle से मैनेज किए जाने वाले कई Firebase टेस्ट लैब डिवाइस जोड़ें किया जा सकता है और फिर एक निर्देश से उन सभी की जांच की जा सकती है. कहें एक से ज़्यादा डिवाइस इस तरह सेट अप करें:

    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"])
            }
          }
        }
      }
    }
    

    डिवाइस ग्रुप के सभी डिवाइसों पर जांच चलाने के लिए, इस निर्देश का इस्तेमाल करें:

    Windows पर:

    gradlew group-nameGroupBuildVariantAndroidTest
    

    Linux या macOS पर:

    ./gradlew group-nameGroupBuildVariantAndroidTest
    

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

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

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

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

    ज़्यादा जानने के लिए, डीएसएल के नए विकल्पों के बारे में पढ़ें.

    Gradle से मैनेज किए जाने वाले Firebase टेस्ट लैब डिवाइसों के लिए, डीएसएल को अपडेट किया गया

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

    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
        }
      }
    }