Android Studio Iguana में ये नई सुविधाएं शामिल हैं.
पैच रिलीज़
यहां Android Studio Iguana और 'Android Gradle प्लग इन' 8.3 में रिलीज़ किए गए पैच की सूची दी गई है.
Android Studio Iguana | 2023.2.1 Patch 2 और AGP 8.3.2 (अप्रैल 2024)
इस छोटे अपडेट में, गड़बड़ियां ठीक करने से जुड़े ये अपडेट शामिल हैं.
Android Studio Iguana | 2023.2.1 पैच 1 और AGP 8.3.1 (मार्च 2024)
इस छोटे अपडेट में, ये गड़बड़ियां ठीक की गई हैं.
IntelliJ IDEA 2023.2 प्लैटफ़ॉर्म से जुड़ा अपडेट
Android Studio Iguana में IntelliJ IDEA 2023.2 के अपडेट शामिल हैं. इससे Studio IDE का अनुभव बेहतर होता है. इन बदलावों के बारे में ज़्यादा जानने के लिए, InteliJ IDEA 2023.2 के प्रॉडक्ट की जानकारी देखें.
ऐप्लिकेशन क्वालिटी की अहम जानकारी में वर्शन कंट्रोल सिस्टम का इंटिग्रेशन
ऐप्लिकेशन क्वालिटी की अहम जानकारी की मदद से, अब क्रैश होने के समय पर, क्रैश की जानकारी देने वाले Crashlytics स्टैक ट्रेस से काम के कोड पर नेविगेट किया जा सकता है. AGP, क्रैश की रिपोर्ट में git commit हैश डेटा अटैच करता है. इससे Android Studio को आपके कोड पर जाने और यह दिखाने में मदद मिलती है कि समस्या वाले वर्शन में यह कैसा था. ऐप्लिकेशन क्वालिटी की अहम जानकारी में क्रैश की रिपोर्ट देखने पर, आपके पास अपने मौजूदा git चेकआउट में कोड की लाइन पर जाने का विकल्प होता है. इसके अलावा, मौजूदा चेकआउट और क्रैश जनरेट करने वाले कोडबेस के वर्शन के बीच का अंतर भी देखा जा सकता है.
अपने वर्शन कंट्रोल सिस्टम को ऐप्लिकेशन की क्वालिटी के बारे में अहम जानकारी के साथ इंटिग्रेट करने के लिए, आपके पास ये ज़रूरी शर्तें होनी चाहिए:
- Android Studio Iguana का नया कैनरी वर्शन
- Android Gradle प्लग इन 8.3 का नया अल्फा वर्शन
- Crashlytics SDK टूल का 18.3.7 वर्शन (या Firebase Android बिल ऑफ़ मटीरियल का 32.0.0 वर्शन)
डीबग किए जा सकने वाले बिल्ड टाइप के लिए, वर्शन कंट्रोल इंटिग्रेशन का इस्तेमाल करने के लिए, मॉड्यूल-लेवल की बिल्ड फ़ाइल में vcsInfo फ़्लैग चालू करें. रिलीज़ (डीबग नहीं किए जा सकने वाले) बिल्ड के लिए, यह फ़्लैग डिफ़ॉल्ट रूप से चालू होता है.
Kotlin
android { buildTypes { getByName("debug") { vcsInfo { include = true } } } }
ग्रूवी
android { buildTypes { debug { vcsInfo { include true } } } }
अब जब आपका ऐप्लिकेशन बन जाता है और उसे Google Play पर पब्लिश किया जाता है, तो क्रैश रिपोर्ट में वह डेटा शामिल होता है जो IDE को स्टैक ट्रेस से आपके ऐप्लिकेशन के पिछले वर्शन से लिंक करने के लिए ज़रूरी होता है.
ऐप्लिकेशन की क्वालिटी की अहम जानकारी में, Crashlytics के क्रैश वैरिएंट देखना
ऐप्लिकेशन के क्रैश होने की मुख्य वजहों का विश्लेषण करने के लिए, अब ऐप्लिकेशन क्वालिटी के बारे में अहम जानकारी का इस्तेमाल किया जा सकता है. इससे, समस्या के वैरिएंट या मिलते-जुलते स्टैक ट्रेस वाले इवेंट के ग्रुप के हिसाब से इवेंट देखे जा सकते हैं. क्रैश रिपोर्ट के हर वैरिएंट में इवेंट देखने के लिए, ड्रॉपडाउन से कोई वैरिएंट चुनें. सभी वैरिएंट की जानकारी इकट्ठा करने के लिए, सभी चुनें.
यूज़र इंटरफ़ेस (यूआई) की जांच करने वाला टूल लिखें
डेवलपर को Jetpack Compose में ज़्यादा अडैप्टिव और ऐक्सेस किए जा सकने वाले यूज़र इंटरफ़ेस (यूआई) बनाने में मदद करने के लिए, Android Studio Iguana Canary 5 में Compose के झलक वाले वर्शन में यूआई की जांच करने का नया मोड जोड़ा गया है. यह सुविधा, व्यू के लिए विज़ुअल लिंटिंग और सुलभता जांच के इंटिग्रेशन की तरह ही काम करती है. Compose यूज़र इंटरफ़ेस (यूआई) की जांच करने वाले मोड को चालू करने पर, Android Studio आपके Compose यूज़र इंटरफ़ेस (यूआई) की अपने-आप जांच करता है. साथ ही, अलग-अलग स्क्रीन साइज़ के हिसाब से बदलने और सुलभता से जुड़ी समस्याओं की जांच करता है. जैसे, बड़ी स्क्रीन पर टेक्स्ट का स्ट्रेच होना या रंग का कंट्रास्ट कम होना. यह मोड, झलक के अलग-अलग कॉन्फ़िगरेशन में मिली समस्याओं को हाइलाइट करता है और उन्हें समस्याओं वाले पैनल में दिखाता है.
इस सुविधा को आज ही आज़माएं. इसके लिए, 'लिखें' पेज पर, यूज़र इंटरफ़ेस (यूआई) की जांच करने वाले बटन
पर क्लिक करें और अपना सुझाव/राय/शिकायत भेजें:
यूज़र इंटरफ़ेस (यूआई) जांच मोड की पहले से मालूम समस्याएं:
- समस्या पैनल में चुनी गई समस्या पर फ़ोकस नहीं हो सकता
- "जानकारी छिपाने का नियम" काम नहीं करता है
Compose की झलक के लिए प्रोग्रेसिव रेंडरिंग
Android Studio Iguana Canary 3 में, Compose के झलक वाले वर्शन में प्रोग्रेसिव रेंडरिंग की सुविधा जोड़ी गई है. झलक को बेहतर बनाने के लिए, हम लगातार काम कर रहे हैं. इसलिए, अब हम स्क्रीन पर न दिखने वाली झलक की रेंडर क्वालिटी को कम कर देते हैं, ताकि इस्तेमाल की जा रही मेमोरी को बचाया जा सके.
इस सुविधा को इस मकसद से बनाया गया है कि फ़ाइल में एक साथ कई झलकें देखी जा सकें. इससे, झलक देखने की सुविधा को और बेहतर बनाया जा सकेगा. इसे आज ही आज़माएं और अपना सुझाव, शिकायत या राय सबमिट करें.
बेसलाइन प्रोफ़ाइल मॉड्यूल का विज़र्ड
Android Studio Iguana में, नए मॉड्यूल विज़र्ड (फ़ाइल > नया > नया मॉड्यूल) में बेसलाइन प्रोफ़ाइल जनरेटर टेंप्लेट का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए बेसलाइन प्रोफ़ाइल जनरेट की जा सकती हैं.
यह टेंप्लेट आपके प्रोजेक्ट को सेट अप करता है, ताकि वह बेसलाइन प्रोफ़ाइलों के साथ काम कर सके. यह, नए Baseline Profiles Gradle प्लग इन का इस्तेमाल करता है. यह एक Gradle टास्क की मदद से, आपके प्रोजेक्ट को ज़रूरी तरीके से सेट अप करने की प्रोसेस को ऑटोमेट करता है.
टेंप्लेट, एक रन कॉन्फ़िगरेशन भी बनाता है. इससे, रन/डीबग कॉन्फ़िगरेशन चुनें ड्रॉप-डाउन सूची से एक क्लिक में बेसलाइन प्रोफ़ाइल जनरेट की जा सकती है.
Espresso Device API की मदद से, कॉन्फ़िगरेशन में हुए बदलावों की जांच करना
जब डिवाइस के कॉन्फ़िगरेशन में सामान्य बदलाव होते हैं, जैसे कि स्क्रीन घुमाना और स्क्रीन को फ़ोल्ड करना, तो अपने ऐप्लिकेशन की जांच करने के लिए Espresso Device API का इस्तेमाल करें. Espresso Device API की मदद से, वर्चुअल डिवाइस पर कॉन्फ़िगरेशन में किए गए इन बदलावों को सिम्युलेट किया जा सकता है. साथ ही, यह आपके टेस्ट को एक साथ चलाता है, ताकि एक समय पर सिर्फ़ एक यूज़र इंटरफ़ेस (यूआई) ऐक्शन या एश्योरेशन हो और आपके टेस्ट के नतीजे ज़्यादा भरोसेमंद हों. Espresso की मदद से यूज़र इंटरफ़ेस (यूआई) टेस्ट लिखने के तरीके के बारे में ज़्यादा जानें.
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 } }
Groovy
testOptions { emulatorControl { enable = true } }
मॉड्यूल-लेवल की बिल्ड स्क्रिप्ट में, अपने प्रोजेक्ट में Espresso डिवाइस लाइब्रेरी को इंपोर्ट करें:
Kotlin
dependencies { androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1") }
Groovy
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() {
...
}