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 पैच 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 कमिट हैश डेटा जोड़ता है. इससे Android Studio को आपके कोड पर जाने और यह दिखाने में मदद मिलती है कि समस्या वाले वर्शन में वह कोड कैसा था. ऐप्लिकेशन क्वालिटी इनसाइट में क्रैश रिपोर्ट देखते समय, आपके पास मौजूदा git चेकआउट में कोड की लाइन पर जाने या मौजूदा चेकआउट और आपके कोडबेस के उस वर्शन के बीच अंतर देखने का विकल्प होता है जिसकी वजह से क्रैश हुआ था.
अपने वर्शन कंट्रोल सिस्टम को ऐप्लिकेशन क्वालिटी इनसाइट के साथ इंटिग्रेट करने के लिए, आपको ये ज़रूरी शर्तें पूरी करनी होंगी:
- Android Studio Iguana का सबसे नया Canary वर्शन
- Android Gradle प्लगिन 8.3 का सबसे नया Alpha वर्शन
- Crashlytics SDK v18.3.7 (या Firebase Android Bill of Materials v32.0.0)
डीबग की जा सकने वाली बिल्ड टाइप के लिए, वर्शन कंट्रोल इंटिग्रेशन का इस्तेमाल करने के लिए, मॉड्यूल-लेवल की बिल्ड फ़ाइल में vcsInfo फ़्लैग चालू करें. रिलीज़ (डीबग नहीं की जा सकने वाली) बिल्ड के लिए, यह फ़्लैग डिफ़ॉल्ट रूप से चालू होता है.
Kotlin
android { buildTypes { getByName("debug") { vcsInfo { include = true } } } }
शानदार
android { buildTypes { debug { vcsInfo { include true } } } }
अब, जब अपने ऐप्लिकेशन को बिल्ड करके Google Play पर पब्लिश किया जाता है, तो क्रैश रिपोर्ट में वह डेटा शामिल होता है जिसकी मदद से IDE, स्टैक ट्रेस से आपके ऐप्लिकेशन के पिछले वर्शन से लिंक हो सकता है.
ऐप्लिकेशन क्वालिटी इनसाइट में, Crashlytics क्रैश वैरिएंट देखना
क्रैश की वजहों का विश्लेषण करने में आपकी मदद करने के लिए, अब ऐप्लिकेशन क्वालिटी इनसाइट का इस्तेमाल करके, समस्या के वैरिएंट या एक जैसे स्टैक ट्रेस वाले इवेंट के ग्रुप देखे जा सकते हैं. क्रैश रिपोर्ट के हर वैरिएंट में इवेंट देखने के लिए, ड्रॉपडाउन से कोई वैरिएंट चुनें. सभी वैरिएंट की जानकारी इकट्ठा करने के लिए, सभी को चुनें.
Compose यूज़र इंटरफ़ेस की जांच करें
डेवलपर को Jetpack Compose में ज़्यादा अडैप्टिव और सुलभ यूज़र इंटरफ़ेस (यूआई) बनाने में मदद करने के लिए, Android Studio Iguana Canary 5 में Compose की झलक में, यूज़र इंटरफ़ेस की जांच करने का नया मोड जोड़ा गया है. यह सुविधा, विज़ुअल लिंटिंग और सुलभता की जांच के इंटिग्रेशन की तरह काम करती है. Compose यूज़र इंटरफ़ेस की जांच करने का मोड चालू करने पर, Android Studio अपने-आप आपके Compose यूज़र इंटरफ़ेस की ऑडिट करता है. साथ ही, अलग-अलग स्क्रीन साइज़ के हिसाब से, अडैप्टिव और सुलभता से जुड़ी समस्याओं की जांच करता है. जैसे, बड़ी स्क्रीन पर टेक्स्ट का स्ट्रेच होना या कम कलर कंट्रास्ट. यह मोड, झलक के अलग-अलग कॉन्फ़िगरेशन में मिली समस्याओं को हाइलाइट करता है और उन्हें समस्याओं वाले पैनल में दिखाता है.
Compose की झलक में, यूज़र इंटरफ़ेस की जांच करने वाले बटन
पर क्लिक करके, आज ही इस सुविधा को आज़माएं और अपनी राय भेजें:
यूज़र इंटरफ़ेस की जांच करने वाले मोड की समस्याएं:
- समस्याओं वाले पैनल में चुनी गई समस्या से फ़ोकस हट सकता है
- "नियम को दबाएं" काम नहीं करता
Compose की झलक के लिए, प्रोग्रेसिव रेंडरिंग की सुविधा
Android Studio Iguana Canary 3 में, Compose की झलक में प्रोग्रेसिव रेंडरिंग की सुविधा जोड़ी गई है. झलक को बेहतर बनाने की कोशिश के तहत, अब व्यू से बाहर की किसी भी झलक के लिए, हम जान-बूझकर उसकी रेंडर क्वालिटी कम करते हैं, ताकि इस्तेमाल की गई मेमोरी को बचाया जा सके.
इस सुविधा को इस मकसद से डेवलप किया गया है, ताकि एक ही फ़ाइल में एक साथ ज़्यादा झलकें हैंडल करके, झलक की सुविधा को और बेहतर बनाया जा सके. इसे आज ही आज़माएं और अपनी राय सबमिट करें.
बेसलाइन प्रोफ़ाइल मॉड्यूल विज़र्ड
Android Studio Iguana से, नए मॉड्यूल विज़र्ड (फ़ाइल > नया > नया मॉड्यूल) में मौजूद बेसलाइन प्रोफ़ाइल जनरेटर टेंप्लेट का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए बेसलाइन प्रोफ़ाइलें जनरेट की जा सकती हैं.
यह टेंप्लेट, आपके प्रोजेक्ट को इस तरह सेट अप करता है कि वह बेसलाइन प्रोफ़ाइल के साथ काम कर सके. यह नए बेसलाइन प्रोफ़ाइल 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 या इसके बाद का वर्शन
- Android वर्चुअल डिवाइस, जो एपीआई लेवल 24 या इसके बाद के वर्शन पर चलता हो
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 Device लाइब्रेरी को अपने प्रोजेक्ट में इंपोर्ट करें:
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() {
...
}