Android Studio Iguana में ये नई सुविधाएं शामिल हैं.
पैच रिलीज़
यहां Android Studio Iguana और 'Android Gradle प्लग इन' 8.3 में रिलीज़ किए गए पैच की सूची दी गई है.
Android Studio Iguana | 2023.2.1 पैच 2 और AGP 8.3.2 (अप्रैल 2024)
इस छोटे अपडेट में, गड़बड़ियां ठीक करने से जुड़े ये अपडेट शामिल हैं.
Android Studio Iguana | 2023.2.1 Patch 1 और AGP 8.3.1 (मार्च 2024)
इस छोटे अपडेट में, गड़बड़ियां ठीक करने से जुड़े ये अपडेट शामिल हैं.
IntelliJ IDEA 2023.2 प्लैटफ़ॉर्म का अपडेट
Android Studio Iguana में IntelliJ IDEA 2023.2 के अपडेट शामिल हैं. इनसे Studio IDE का अनुभव बेहतर होता है. बदलावों के बारे में ज़्यादा जानने के लिए, IntelliJ IDEA 2023.2 के रिलीज़ नोट देखें.
ऐप्लिकेशन क्वालिटी की अहम जानकारी में वर्शन कंट्रोल सिस्टम का इंटिग्रेशन
ऐप्लिकेशन क्वालिटी की अहम जानकारी की मदद से, अब क्रैश होने के समय पर, क्रैश की जानकारी देने वाले Crashlytics स्टैक ट्रेस से काम के कोड पर नेविगेट किया जा सकता है. AGP, क्रैश की रिपोर्ट में git commit हैश डेटा अटैच करता है. इससे Android Studio को आपके कोड पर जाने और यह दिखाने में मदद मिलती है कि समस्या वाले वर्शन में यह कैसा था. ऐप्लिकेशन क्वालिटी की अहम जानकारी में क्रैश की रिपोर्ट देखने पर, आपके पास अपने मौजूदा git चेकआउट में कोड की लाइन पर जाने का विकल्प होता है. इसके अलावा, मौजूदा चेकआउट और क्रैश जनरेट करने वाले कोडबेस के वर्शन के बीच का अंतर भी देखा जा सकता है.
अपने वर्शन कंट्रोल सिस्टम को ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी के साथ इंटिग्रेट करने के लिए, आपके पास ये ज़रूरी शर्तें होनी चाहिए:
- Android Studio Iguana का नया Canary वर्शन
- Android Gradle प्लग इन 8.3 का नया अल्फा वर्शन
- Crashlytics SDK टूल का 18.3.7 वर्शन (या Firebase Android बिल ऑफ़ मटीरियल का 32.0.0 वर्शन)
डीबग किए जा सकने वाले बिल्ड टाइप के लिए, वर्शन कंट्रोल इंटिग्रेशन का इस्तेमाल करने के लिए, मॉड्यूल-लेवल की बिल्ड फ़ाइल में vcsInfo फ़्लैग चालू करें. रिलीज़ (डीबग नहीं किए जा सकने वाले) बिल्ड के लिए, यह फ़्लैग डिफ़ॉल्ट रूप से चालू होता है.
Kotlin
android { buildTypes { getByName("debug") { vcsInfo { include = true } } } }
Groovy
android { buildTypes { debug { vcsInfo { include true } } } }
अब जब आपका ऐप्लिकेशन बन जाता है और उसे Google Play पर पब्लिश किया जाता है, तो क्रैश रिपोर्ट में वह डेटा शामिल होता है जो IDE को स्टैक ट्रेस से आपके ऐप्लिकेशन के पिछले वर्शन से लिंक करने के लिए ज़रूरी होता है.
ऐप्लिकेशन क्वालिटी इनसाइट में, Crashlytics के बंद होने के वैरिएंट देखना
ऐप्लिकेशन के क्रैश होने की मुख्य वजहों का विश्लेषण करने के लिए, अब ऐप्लिकेशन क्वालिटी के बारे में अहम जानकारी का इस्तेमाल किया जा सकता है. इससे, समस्या के वैरिएंट या मिलते-जुलते स्टैक ट्रेस वाले इवेंट के ग्रुप के हिसाब से इवेंट देखे जा सकते हैं. क्रैश रिपोर्ट के हर वैरिएंट में इवेंट देखने के लिए, ड्रॉपडाउन से कोई वैरिएंट चुनें. सभी वैरिएंट की जानकारी इकट्ठा करने के लिए, सभी चुनें.
यूज़र इंटरफ़ेस (यूआई) की जांच करना
Android Studio Iguana Canary 5 ने Compose Preview में नया यूज़र इंटरफ़ेस (यूआई) चेक मोड लॉन्च किया है. इससे डेवलपर को Jetpack Compose में ज़्यादा अडैप्टिव और ऐक्सेस किए जा सकने वाले यूआई बनाने में मदद मिलेगी. यह सुविधा, व्यू के लिए विज़ुअल लिंटिंग और सुलभता जांच के इंटिग्रेशन की तरह ही काम करती है. Compose यूज़र इंटरफ़ेस (यूआई) की जांच करने वाले मोड को चालू करने पर, Android Studio आपके Compose यूज़र इंटरफ़ेस (यूआई) की अपने-आप जांच करता है. साथ ही, अलग-अलग स्क्रीन साइज़ के हिसाब से बदलने और सुलभता से जुड़ी समस्याओं की जांच करता है. जैसे, बड़ी स्क्रीन पर टेक्स्ट का स्ट्रेच होना या रंग का कंट्रास्ट कम होना. यह मोड, झलक के अलग-अलग कॉन्फ़िगरेशन में मिली समस्याओं को हाइलाइट करता है और उन्हें समस्याओं वाले पैनल में दिखाता है.
इस सुविधा को आज ही आज़माएं. इसके लिए, 'झलक देखें' पर 'यूज़र इंटरफ़ेस (यूआई) की जांच करें' बटन
पर क्लिक करें और अपना सुझाव भेजें:
यूज़र इंटरफ़ेस (यूआई) की जांच करने वाले मोड से जुड़ी समस्याएं:
- समस्या पैनल में चुनी गई समस्या पर फ़ोकस नहीं हो सकता
- "नियम को दबाएं" सुविधा काम नहीं करती
Compose की झलक के लिए प्रोग्रेसिव रेंडरिंग
Android Studio Iguana Canary 3 ने Compose की झलक में प्रोग्रेसिव रेंडरिंग को लॉन्च किया. हम झलक को बेहतर बनाने की लगातार कोशिश कर रहे हैं. इसके तहत, अब हम ऐसे किसी भी प्रीव्यू के लिए, रेंडर की क्वालिटी को जान-बूझकर कम करते हैं, ताकि इस्तेमाल की गई मेमोरी सेव की जा सके.
इस सुविधा को इस मकसद से बनाया गया है कि फ़ाइल में एक साथ कई झलकें देखी जा सकें. इससे, झलक देखने की सुविधा को और बेहतर बनाया जा सकेगा. इसे आज ही आज़माएं और अपना सुझाव, शिकायत या राय सबमिट करें.
बेसलाइन प्रोफ़ाइल मॉड्यूल का विज़र्ड
Android Studio Iguana की शुरुआत में, नए मॉड्यूल विज़र्ड में बेसलाइन प्रोफ़ाइल जनरेटर टेंप्लेट का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए बेसलाइन प्रोफ़ाइल जनरेट की जा सकती हैं (फ़ाइल > नया > नया मॉड्यूल).
यह टेंप्लेट आपके प्रोजेक्ट को सेट अप करता है, ताकि वह बेसलाइन प्रोफ़ाइलों के साथ काम कर सके. इसमें नए बेसलाइन प्रोफ़ाइल Gradle प्लग इन का इस्तेमाल किया जाता है, जो एक Gradle टास्क की मदद से, आपके प्रोजेक्ट को अपने-आप सेट अप करने की प्रोसेस को ऑटोमेट करता है.
यह टेंप्लेट एक रन कॉन्फ़िगरेशन भी बनाता है, जिसकी मदद से रन/डीबग कॉन्फ़िगरेशन चुनें ड्रॉप-डाउन सूची से सिर्फ़ एक क्लिक करके, बेसलाइन प्रोफ़ाइल बनाई जा सकती है.
Espresso Device API की मदद से, कॉन्फ़िगरेशन में हुए बदलावों की जांच करें
जब डिवाइस के कॉन्फ़िगरेशन में सामान्य बदलाव होते हैं, जैसे कि स्क्रीन घुमाना और स्क्रीन को फ़ोल्ड करना, तो अपने ऐप्लिकेशन की जांच करने के लिए Espresso Device API का इस्तेमाल करें. Espresso Device API की मदद से, वर्चुअल डिवाइस पर कॉन्फ़िगरेशन में किए गए इन बदलावों को सिम्युलेट किया जा सकता है. साथ ही, यह आपके टेस्ट को एक साथ चलाता है, ताकि एक समय पर सिर्फ़ एक यूज़र इंटरफ़ेस (यूआई) ऐक्शन या एश्योरेशन हो और आपके टेस्ट के नतीजे ज़्यादा भरोसेमंद हों. Aspresso की मदद से यूज़र इंटरफ़ेस (यूआई) टेस्ट लिखने के तरीके के बारे में ज़्यादा जानें.
Espresso Device API का इस्तेमाल करने के लिए, आपके पास ये चीज़ें होनी चाहिए:
- Android Studio Iguana या इसके बाद वाला वर्शन
- 'Android Gradle प्लग इन 8.3' या इसके बाद वाला वर्शन
- Android Emulator 33.1.10 या इसके बाद का वर्शन
- एपीआई लेवल 24 या उसके बाद के वर्शन पर चलने वाला Android वर्चुअल डिवाइस
Espresso Device API के लिए अपना प्रोजेक्ट सेट अप करना
अपने प्रोजेक्ट को Espresso Device API के साथ काम करने के लिए सेट अप करने के लिए, यह तरीका अपनाएं:
टेस्ट को टेस्ट डिवाइस पर निर्देश भेजने की अनुमति देने के लिए,
androidTestसोर्स सेट में मौजूद मेनिफ़ेस्ट फ़ाइल मेंINTERNETऔरACCESS_NETWORK_STATEअनुमतियां जोड़ें:<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />
gradle.propertiesफ़ाइल में,enableEmulatorControlएक्सपेरिमेंटल फ़्लैग को चालू करें:android.experimental.androidTest.enableEmulatorControl=true
मॉड्यूल-लेवल की बिल्ड स्क्रिप्ट में
emulatorControlविकल्प चालू करें:Kotlin
testOptions { emulatorControl { enable = true } }
ग्रूवी
testOptions { emulatorControl { enable = true } }
मॉड्यूल-लेवल बिल्ड स्क्रिप्ट में, अपने प्रोजेक्ट में Espresso डिवाइस लाइब्रेरी को इंपोर्ट करें:
Kotlin
dependencies { androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1") }
ग्रूवी
dependencies { androidTestImplementation 'androidx.test.espresso:espresso-device:3.6.1' }
कॉन्फ़िगरेशन में आम तौर पर होने वाले बदलावों के लिए जांच करना
Espresso Device API में, स्क्रीन के कई ओरिएंटेशन और फ़ोल्ड किए जा सकने वाले डिवाइस की कई स्थितियां होती हैं. इनका इस्तेमाल, डिवाइस के कॉन्फ़िगरेशन में होने वाले बदलावों को सिम्युलेट करने के लिए किया जा सकता है.
स्क्रीन के रोटेट होने के हिसाब से जांच करना
डिवाइस की स्क्रीन घुमाने पर, आपके ऐप्लिकेशन पर क्या असर पड़ता है, यह जांचने का तरीका यहां बताया गया है:
सबसे पहले, डिवाइस को पोर्ट्रेट मोड पर सेट करें, ताकि हर बार एक जैसी शुरुआत हो:
import androidx.test.espresso.device.action.ScreenOrientation import androidx.test.espresso.device.rules.ScreenOrientationRule ... @get:Rule val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)
ऐसा टेस्ट बनाएं जो टेस्ट के दौरान डिवाइस को लैंडस्केप ओरिएंटेशन पर सेट करता हो:
@Test fun myRotationTest() { ... // Sets the device to landscape orientation during test execution. onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE) ... }
स्क्रीन के घूमने के बाद, देखें कि यूज़र इंटरफ़ेस (यूआई), उम्मीद के मुताबिक नए लेआउट के हिसाब से ढल गया है या नहीं:
@Test fun myRotationTest() { ... // Sets the device to landscape orientation during test execution. onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE) composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed() composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist() }
स्क्रीन के फ़ोल्ड होने के दौरान जांच करना
यहां एक उदाहरण दिया गया है, जिसमें यह जांचने का तरीका बताया गया है कि अगर आपका ऐप्लिकेशन फ़ोल्ड किए जा सकने वाले डिवाइस पर है और स्क्रीन को फ़ोल्ड किया जाता है, तो क्या होगा:
सबसे पहले, डिवाइस को फ़ोल्ड करके,
onDevice().setClosedMode()को कॉल करके जांच करें. पक्का करें कि आपके ऐप्लिकेशन का लेआउट, स्क्रीन की छोटी चौड़ाई के हिसाब से हो:@Test fun myUnfoldedTest() { onDevice().setClosedMode() composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed() composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist() ... }
डिवाइस को पूरी तरह से अनफ़ोल्ड करने के लिए,
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() {
...
}