डिपेंडेंसी वर्शन अपग्रेड करें

डिपेंडेंसी को अपग्रेड करने से, आपको उनकी नई सुविधाओं, गड़बड़ियों को ठीक करने के तरीकों, और सुधारों का ऐक्सेस मिलता है. अपनी डिपेंडेंसी को अपग्रेड करने के लिए, आपको यह समझना होगा कि Gradle, आपके अनुरोध किए गए वर्शन को कैसे हल करता है. साथ ही, आपको यह भी पता होना चाहिए कि इससे क्या जोखिम हो सकते हैं और उन जोखिमों को कम करने के लिए क्या किया जा सकता है.

अपग्रेड करने की रणनीति के बारे में सोचें

किसी भी अपग्रेड के लिए, जोखिम का विश्लेषण करना सबसे अहम चरण है. यह तय करें कि अपग्रेड की गई हर डिपेंडेंसी के साथ आप कितने सहज हैं. अपग्रेड की रणनीति तय करते समय, कई बातों का ध्यान रखना ज़रूरी है. इनमें ये भी शामिल हैं:

लाइब्रेरी बनाना

क्या आप ऐसा ऐप्लिकेशन बना रहे हैं जिसे उपयोगकर्ता डाउनलोड करके अपने डिवाइस पर चलाएं? क्या आपने कोई लाइब्रेरी बनाई है, ताकि अन्य डेवलपर अपने ऐप्लिकेशन बना सकें?

अगर कोई ऐप्लिकेशन बनाया जा रहा है, तो आपका ध्यान उसे अप-टू-डेट और स्टेबल रखने पर होना चाहिए.

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

पहला - जहां भी हो सके वहां अपनी लाइब्रेरी की डिपेंडेंसी कम करें. आपके पास जितनी कम निर्भरता होगी, आपके उपभोक्ता के डिपेंडेंसी रिज़ॉल्यूशन पर उतना ही कम असर होगा.

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

उपयोगकर्ताओं को रिलीज़ से पहले टेस्ट करने के लिए, अपनी लाइब्रेरी का रिलीज़-कैंडिडेट (आरसी) बनाएं.

अपनी लाइब्रेरी के ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के साथ काम करने के बारे में जानने के लिए, लाइब्रेरी के लेखकों के लिए पुराने सिस्टम के साथ काम करने से जुड़े दिशा-निर्देश देखें. इंटिग्रेशन टेस्ट और बाइनरी के साथ काम करने की पुष्टि करने वाले टूल का इस्तेमाल करके, पक्का करें कि एबीआई में किए गए बदलाव, आपके वर्शन में किए गए बदलाव से मेल खाते हों.

अगर आपने लाइब्रेरी के पुराने वर्शन में patch में सुधार किए हैं, तो आपके उपयोगकर्ताओं को लाइब्रेरी को अगले major या minor वर्शन में अपग्रेड करने की ज़रूरत नहीं है. ऐसा तब तक नहीं करना होगा, जब तक उन्हें नई सुविधाएं नहीं चाहिए. इन अपग्रेड में, ट्रांज़िशन डिपेंडेंसी को अपग्रेड करने से बचें.

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

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

रिलीज़ साइकल

आपका ऐप्लिकेशन या लाइब्रेरी कितनी बार रिलीज़ होती है?

डेवलपमेंट और रिलीज़ साइकल कम होना

  • अपग्रेड करने में कम समय लगता है.
  • आपके पास बहुत कम समय होता है.
  • बार-बार छोटे अपग्रेड करने से, काम का बोझ कम हो सकता है.
  • अगर लाइब्रेरी को अपग्रेड करने में समस्या आती है, तो उस अपग्रेड को तुरंत रोल-बैक किया जा सकता है.
  • Dependabot और Renovate जैसे टूल, आपके काम का बोझ कम करते हैं. हालांकि, जोखिम का पता लगाने के लिए, नतीजों का विश्लेषण करना न भूलें.

डेवलपमेंट और रिलीज़ साइकल ज़्यादा लंबे होते हैं

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

नई सुविधाओं के बारे में अप-टू-डेट रहें

क्या आपको उपलब्ध नई सुविधाओं और एपीआई का इस्तेमाल करना पसंद है या सिर्फ़ तब अपग्रेड करना है, जब आपको कोई सुविधा या गड़बड़ी ठीक करनी हो?

बार-बार अपग्रेड करने के फ़ायदे और नुकसान के बारे में सोचें. आने वाले समय में अपग्रेड करने में आसानी होगी (इसमें कम बदलाव किए जा सकते हैं), लेकिन अपग्रेड से जुड़े जोखिम ज़्यादा हो रहे हैं.

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

नई डिपेंडेंसी

अगर कोई नई डिपेंडेंसी जोड़ी जा रही है, तो समीक्षा की ऐसी प्रोसेस अपनाएं जो उस लाइब्रेरी की सभी जोखिम वाली शर्तों की जांच करे. इससे यह पक्का किया जा सकेगा कि उसका सही तरीके से आकलन किया गया है. समीक्षा किए बिना नई डिपेंडेंसी जोड़ने की अनुमति न दें.

खास टीम

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

अपग्रेड का टाइप

कुछ अपग्रेड दूसरों की तुलना में ज़्यादा ज़रूरी होते हैं. देखें कि आपके लिए कौनसे सबसे ज़रूरी हैं.

आम तौर पर, Gradle और Gradle प्लग इन जैसे बिल्ड टूल के अपग्रेड से आपके उपयोगकर्ताओं पर कम असर पड़ता है. साथ ही, ज़्यादातर जोखिम आपके बिल्ड में ही होता है. इन बदलावों की पुष्टि करने में, बिल्ड की मदद मिलती है. लाइब्रेरी और SDK टूल के अपग्रेड की पुष्टि करना मुश्किल होता है. साथ ही, इनसे आपके उपयोगकर्ताओं को ज़्यादा खतरा होता है.

Android Gradle प्लग इन (AGP) — यह टूल, आपके Android ऐप्लिकेशन या लाइब्रेरी को बनाने के लिए इस्तेमाल किया जाता है. यह सबसे ज़रूरी अपग्रेड है, क्योंकि इसमें अक्सर परफ़ॉर्मेंस में सुधार, गड़बड़ी ठीक करना, नए लिंट नियम, और Android प्लैटफ़ॉर्म के नए वर्शन के लिए सहायता शामिल होती है या शामिल होती हैं.

Gradle — AGP या किसी दूसरे Gradle प्लग इन को अपग्रेड करने पर, आपको अक्सर Gradle को भी अपग्रेड करना पड़ता है.

अन्य Gradle प्लग इन — कभी-कभी Gradle का प्लग इन एपीआई बदल जाता है. Gradle को अपग्रेड करते समय, इस्तेमाल किए जा रहे प्लग इन के अपग्रेड देखें.

Kotlin और Java — कुछ लाइब्रेरी और प्लग इन के लिए, Kotlin या Java के कम से कम वर्शन की ज़रूरत होती है. इसके अलावा, भाषा की नई सुविधाओं, एपीआई या परफ़ॉर्मेंस में हुए सुधारों का फ़ायदा पाने के लिए भी ऐसा किया जा सकता है.

Android प्लैटफ़ॉर्म — Play Store के लिए, Android SDK टूल को नियमित तौर पर अपग्रेड करना ज़रूरी है. आपको Android SDK टूल के नए वर्शन की जांच जल्द से जल्द करनी चाहिए. SDK टूल के कुछ अपग्रेड के लिए, आपके ऐप्लिकेशन में बदलाव करना ज़रूरी होता है. जैसे, नई अनुमतियां या नए एपीआई का इस्तेमाल करना.

लाइब्रेरी — क्या आपको लाइब्रेरी को प्राथमिकता देनी है, ताकि वे आपके पूरे आर्किटेक्चर के हिसाब से काम कर सकें?

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

Android Studio — Android Studio को अप-टू-डेट रखने से, आपको IntelliJ IDEA प्लैटफ़ॉर्म की नई सुविधाओं और गड़बड़ियों को ठीक करने के टूल का ऐक्सेस मिलता है. साथ ही, आपको Android के नए SDK टूल के साथ काम करने की सुविधा भी मिलती है.

उपलब्ध टूल

अपग्रेड करने में आपकी मदद करने के लिए, कई टूल और प्लग इन उपलब्ध हैं. Dependabot और Renovate जैसे टूल, आपके बिल्ड में लाइब्रेरी के वर्शन को अपने-आप अपग्रेड करते हैं. हालांकि, खतरों का पता लगाने के लिए, नतीजों का विश्लेषण करना न भूलें.

खास तरह के अपग्रेड के लिए रणनीतियां

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

डिपेंडेंसी और उनके रिलेशनशिप बनाना
पहली इमेज. रिश्ते बनाएं.

हर तरह के कॉम्पोनेंट को अपग्रेड करते समय, इस बात का ध्यान रखें कि अपग्रेड से बिल्ड में मौजूद अन्य कॉम्पोनेंट पर क्या असर पड़ेगा.

Android Gradle प्लग इन (AGP)

Android Studio में AGP अपग्रेड असिस्टेंट शामिल है, जो इन कामों में मदद कर सकता है.

अगर Assistant का इस्तेमाल किया जाता है या मैन्युअल तरीके से अपग्रेड किया जाता है, तो इन बातों को ध्यान में रखें:

AGP के रिलीज़ नोट देखें.

Gradle को कम से कम, सूची में दिए गए वर्शन पर अपग्रेड करें.

Android Studio को ऐसे वर्शन पर अपग्रेड करें जो चुने गए AGP वर्शन के साथ काम करता हो.

आपको जिस Android SDK टूल का इस्तेमाल करना है उसके साथ काम करने वाले, Android Studio और AGP के वर्शन का इस्तेमाल करें.

देखें कि SDK टूल बिल्ड टूल, एनडीके (NDK), और JDK के साथ काम करता है या नहीं.

अगर आपने संगठन के अंदर या सार्वजनिक तौर पर इस्तेमाल करने के लिए, ऐसा Gradle प्लग इन डेवलप किया है जो AGP के डेटा को बढ़ाता है या उसका इस्तेमाल करता है, तो देखें कि आपको अपना प्लग इन अपग्रेड करना होगा या नहीं. कभी-कभी एजीपी, एपीआई को बंद कर देता है और बाद में हटा देता है. इससे, पिछले प्लग इन के साथ काम नहीं करता.

Kotlin कंपाइलर, भाषा, और रनटाइम

पहले से मौजूद समस्याओं और काम न करने की समस्याओं के बारे में जानने के लिए, Kotlin रिलीज़ नोट देखें.

अगर Jetpack Compose का इस्तेमाल किया जाता है, तो:

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

इस्तेमाल किए जा रहे सभी अन्य Kotlin कंपाइलर प्लग इन को अपग्रेड करें. Kotlin कंपाइलर प्लगिन एपीआई अक्सर रिलीज़ के बीच बदलता है और प्लगिन को इसके साथ काम करने वाले एपीआई का इस्तेमाल करना चाहिए. अगर प्लग इन, कंपाइलर प्लग इन में शामिल है, तो आपको Kotlin कंपाइलर के उसी वर्शन का इस्तेमाल करना होगा. किसी भी अन्य कंपाइल प्लग इन के लिए, सही मैपिंग के लिए उनके दस्तावेज़ देखें.

ध्यान दें कि जिन कंपाइलर प्लगिन को Kotlin कंपाइलर के साथ मैनेज नहीं किया जाता है उन्हें रिलीज़ होने में अक्सर देरी होती है. ऐसा इसलिए होता है, क्योंकि वे कंपाइलर प्लगिन एपीआई के स्थिर होने का इंतज़ार करते हैं. Kotlin को अपग्रेड करने से पहले, देख लें कि आपके इस्तेमाल किए जा रहे सभी कंपाइलर प्लग इन के लिए, मिलते-जुलते अपग्रेड उपलब्ध हों.

आखिर में, कुछ मामलों में Kotlin भाषा में बदलाव होता है. ऐसे में, आपको अपना कोड अपडेट करना पड़ता है. ऐसा अक्सर तब होता है, जब एक्सपेरिमेंट के तौर पर शुरू की गई सुविधाओं को आज़माया जा रहा हो. अगर Kotlin कंपाइलर को अपग्रेड करने के बाद आपका कोड ठीक से नहीं बनता है, तो Kotlin के रिलीज़ नोट में भाषा में हुए बदलावों या रनटाइम लाइब्रेरी के क्रैश होने की जांच करें.

Kotlin कंपाइलर प्लग इन

अगर आपको Kotlin कंपाइलर प्लग इन को अपग्रेड करना है, तो Kotlin के इस्तेमाल किए जा रहे वर्शन के हिसाब से अपग्रेड करें.

ज़्यादातर Kotlin कंपाइलर प्लगिन या तो Kotlin कंपाइलर के जैसे वर्शन का इस्तेमाल करते हैं या वे Kotlin कंपाइलर के ज़रूरी वर्शन से शुरू करते हैं. उदाहरण के लिए, अगर प्लगिन का वर्शन 2.0.21-1.0.25 है, तो आपको Kotlin कंपाइलर के वर्शन 2.0.21 का इस्तेमाल करना होगा.

Kotlin कंपाइलर के वर्शन को बदलने के लिए, कभी-कभी अन्य बदलाव करने पड़ते हैं.

लाइब्रेरी

लाइब्रेरी, आपके बिल्ड में सबसे ज़्यादा अपग्रेड की जाने वाली डिपेंडेंसी होती हैं. आपको Android Studio एडिटर में उपलब्ध अपग्रेड दिखेंगे. इसके अलावा, डिपेंडेंसी टूल और प्लगिन का इस्तेमाल करने पर भी आपको अपग्रेड दिखेंगे.

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

कुछ लाइब्रेरी, इस्तेमाल के लिए Kotlin के कम से कम वर्शन की जानकारी भी देती हैं. अपनी बिल्ड फ़ाइलों में Kotlin के वर्शन को अपडेट करें, ताकि वह कम से कम तय किए गए वर्शन के बराबर हो.

Gradle

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

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

Gradle को अपग्रेड करने के लिए:

Gradle प्लग इन

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

प्लग इन अपग्रेड करते समय, Gradle को भी अपग्रेड करें.

Android SDK टूल

Android Studio में Android SDK टूल के लिए अपग्रेड असिस्टेंट की सुविधा मौजूद है. इससे इन टास्क को पूरा करने में मदद मिलती है.

अगर आपने Assistant का इस्तेमाल किया है या मैन्युअल तरीके से अपग्रेड किया है, तो इन बातों का ध्यान रखें:

Android SDK के हर रिलीज़ में नई सुविधाएं और एपीआई, गड़बड़ियां ठीक की गई हैं, और काम करने के तरीके में बदलाव किए गए हैं. Play Store के लिए, आपको targetSdk को अपडेट करना ज़रूरी है. हालांकि, targetSdk को समयसीमा खत्म होने से पहले अपडेट करें, ताकि ज़रूरी बदलाव करने के लिए आपको ज़्यादा समय मिल सके.

Android SDK टूल को अपग्रेड करने से पहले, रिलीज़ नोट को ध्यान से पढ़ें. व्यवहार में बदलाव वाले सेक्शन पर खास ध्यान दें, जिसमें ये शामिल हैं:

  • नई अनुमतियां, जिनका अनुरोध आपको इंस्टॉल या रनटाइम के दौरान करना होगा.
  • बंद किए गए एपीआई और उनके बदले इस्तेमाल किए जा सकने वाले एपीआई.
  • एपीआई या उनके काम करने के तरीके में होने वाले बदलाव.
  • नए Kotlin या Java एपीआई, जिनका असर आपके कोड पर पड़ सकता है.

व्यवहार में बदलाव वाला सेक्शन काफ़ी लंबा हो सकता है. हालांकि, ध्यान रखें, क्योंकि इसमें अक्सर ऐसे अहम बदलाव होते हैं जिनकी आपको अपने ऐप्लिकेशन में ज़रूरत होती है.

Play Store की शर्तों को पूरा करने के लिए, आपको targetSdk को अपग्रेड करना होगा. compileSdk को अपग्रेड करना ज़रूरी नहीं है. इससे आपको नए एपीआई का ऐक्सेस मिल जाएगा. ध्यान दें कि AndroidX जैसी कुछ लाइब्रेरी में, compileSdk की कम से कम ज़रूरत शामिल होती है.

डेवलपमेंट के दौरान, SDK टूल की नई सुविधाओं का फ़ायदा पाने और अपने बिल्ड के दौरान यह पक्का करने के लिए कि वे साथ काम करते हों, 'Android Gradle प्लग इन (AGP)' और Android Studio को अपग्रेड करें. इनमें नए SDK टूल के लिए, नए और बेहतर टूल शामिल हैं. Android एपीआई लेवल के लिए टूल के कम से कम वर्शन देखें.

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

Android Studio

आम तौर पर, Android Studio को कभी भी अपग्रेड किया जा सकता है. आपको AGP टूल को अपग्रेड करने या Android SDK टूल को अपग्रेड करने के लिए कहा जा सकता है. हमारा सुझाव है कि आप इन अपग्रेड को ज़रूर करें. हालांकि, ऐसा करना ज़रूरी नहीं है.

अगर आपको बाद में AGP या Android SDK टूल को अपग्रेड करने के लिए, Android Studio का इस्तेमाल करना है, तो आपको टूल मेन्यू में ये विकल्प मिलेंगे:

Java

अगर आपके Android ऐप्लिकेशन में Java सोर्स कोड है, तो हो सकता है कि आप नए Java API का फ़ायदा लेना चाहें.

Android SDK के हर वर्शन में, Java API के सबसेट और भाषा से जुड़ी सुविधाएं इस्तेमाल की जा सकती हैं. AGP, डिसगैरिंग नाम की प्रोसेस का इस्तेमाल करके, Android SDK टूल के पुराने वर्शन के साथ काम करने की सुविधा देता है.

Android SDK के रिलीज़ नोट में बताया जाता है कि कौनसा Java लेवल काम करता है और संभावित समस्याएं क्या हैं. इनमें से कुछ समस्याओं का असर Kotlin सोर्स कोड पर भी पड़ सकता है, क्योंकि Kotlin के पास उन ही Java API का ऐक्सेस होता है. रिलीज़ नोट के 'कार्रवाइयों में हुए बदलाव' सेक्शन में दिखने वाले JDK API सेक्शन पर ध्यान दें. भले ही, आपके पास कोई Java सोर्स कोड न हो.

आपकी बिल्ड स्क्रिप्ट में कई जगहों पर JDK के इस्तेमाल की जानकारी दी गई है. ज़्यादा जानकारी के लिए, Android बिल्ड में Java के वर्शन देखें.

अपग्रेड का विश्लेषण

किसी डिपेंडेंसी को अपग्रेड करने पर, एपीआई और काम करने के तरीके बदलने, इस्तेमाल की नई ज़रूरी शर्तों, सुरक्षा से जुड़ी नई समस्याओं या लाइसेंस में बदलाव के रूप में जोखिम हो सकते हैं. उदाहरण के लिए, क्या आपको:

  • क्या एपीआई के बदलावों के लिए कोड बदलना है?
  • क्या आपको अनुमतियों की नई जांच जोड़नी है?
  • क्या आपको व्यवहार में हुए बदलावों के लिए, अतिरिक्त टेस्ट बनाने हैं या मौजूदा टेस्ट में बदलाव करने हैं?

ध्यान रखें कि आपने जिस डिपेंडेंसी को अपग्रेड किया है उसने अपनी डिपेंडेंसी के वर्शन अपग्रेड कर दिए हैं. इससे, बदलावों का एक बड़ा सेट तेज़ी से स्पाइडर किया जा सकता है.

अगर अपग्रेड को ऑटोमेट करने के लिए, Renovate या Deppdabot जैसे टूल का इस्तेमाल किया जाता है, तो ध्यान रखें कि वे आपके लिए कोई विश्लेषण नहीं करते. वे लाइब्रेरी के सबसे नए वर्शन पर अपग्रेड करते हैं. यह मत सोचें कि इस तरह के अपने-आप होने वाले अपग्रेड के बाद, सब कुछ ठीक से काम करेगा.

अपग्रेड का विश्लेषण करना, अपग्रेड को सफल बनाने की कुंजी है:

  1. अपग्रेड करने से पहले और बाद में, डिपेंडेंसी में हुए अंतर का पता लगाएं.
  2. हर बदलाव की जांच करें और उससे जुड़े जोखिमों का पता लगाएं.
  3. जोखिमों को कम करें या बदलावों को स्वीकार या अस्वीकार करें.

डिपेंडेंसी में अंतर का पता लगाना

अपग्रेड के विश्लेषण का पहला चरण यह तय करना है कि आपकी डिपेंडेंसी कैसे बदलती हैं. बदलावों को तुरंत देखने के लिए, वर्शन कंट्रोल (VCS, जैसे कि Git) और Dependency Guard प्लग इन का फ़ायदा लें. आपका लक्ष्य, पहले और बाद के स्नैपशॉट बनाना और उनकी तुलना करना है.

अपना पहला बेसलाइन सेट अप करना और बनाना

अपग्रेड शुरू करने से पहले, पक्का कर लें कि आपका प्रोजेक्ट सही तरीके से बिल्ड हो गया हो.

जहां तक हो सके, ज़्यादा से ज़्यादा चेतावनियों को ठीक करें या बेसलाइन बनाएं, ताकि यह पता लगाया जा सके कि आपने पहले कौनसी चेतावनियां देख ली हैं.

  • लिंट: लिंट की मौजूदा चेतावनियों की जांच करें और Android लिंट के आधारभूत लेवल को बनाएं.
  • Kotlin कंपाइलर:
  • अन्य टूल: अगर बेसलाइन ट्रैकिंग के साथ काम करने वाले अन्य स्टैटिक विश्लेषण टूल (जैसे कि Detekt) का इस्तेमाल किया जाता है, तो उनकी बेसलाइन सेट अप करें.

चेतावनी के इन बेसलाइन की मदद से, डिपेंडेंसी को अपग्रेड करने पर मिलने वाली नई चेतावनियां आसानी से देखी जा सकती हैं.

Dependency Guard को सेट अप और चलाकर, डिपेंडेंसी का बेसलाइन बनाएं. अपने gradle/libs.versions.toml वर्शन कैटलॉग में, यह जोड़ें:

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

साथ ही, अपने ऐप्लिकेशन की बिल्ड फ़ाइल में ये चीज़ें जोड़ें:

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

releaseRuntimeClasspath कॉन्फ़िगरेशन, टारगेट होने की संभावना वाला कॉन्फ़िगरेशन है. हालांकि, अगर आपको किसी दूसरे कॉन्फ़िगरेशन का इस्तेमाल करना है, तो सभी उपलब्ध कॉन्फ़िगरेशन देखने के लिए, अपनी बिल्ड फ़ाइल में सूची में शामिल कॉन्फ़िगरेशन के बिना ./gradlew dependencyGuard चलाएं.

सेटअप करने के बाद, app/dependencies/releaseRuntimeClasspath.txt में रिपोर्ट जनरेट करने के लिए ./gradlew dependencyGuard चलाएं. यह आपकी बेसलाइन रिपोर्ट है. इसे सेव करने के लिए, अपने वर्शन कंट्रोल सिस्टम (वीसीएस) में कमिट करें.

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

अपग्रेड करना और अपने बेसलाइन से तुलना करना

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

लिंट से जुड़ी नई चेतावनियां या गड़बड़ियां देखने के लिए, ./gradlew lint चलाएं. किसी भी अहम समस्या को ठीक करें. इसके बाद, ./gradlew lint -Dlint.baselines.continue=true को चलाकर चेतावनी का बेसलाइन अपडेट करें. अगर आपने चेतावनी की बुनियादी रेखाएं कैप्चर करने के लिए, Kotlin War Baseline या Kotlin चीज़ों की बुनियादी जानकारी देने वाला बेसलाइन जनरेट करने वाला टूल इस्तेमाल किया है, तो नई चेतावनियों को ठीक करें और उनकी बेसलाइन अपडेट भी करें.

अपनी बेसलाइन रिपोर्ट अपडेट करने के लिए, ./gradlew dependencyGuard चलाएं. इसके बाद, लाइब्रेरी से बाहर के बदलावों को देखने के लिए, अपनी VCS diff को चलाएं. हो सकता है कि इसमें आपकी उम्मीद से ज़्यादा लाइब्रेरी अपग्रेड शामिल हों.

जोखिमों का विश्लेषण करना

बदलावों के बारे में जानने के बाद, अपग्रेड की गई हर लाइब्रेरी के संभावित जोखिमों को ध्यान में रखें. इससे, आपको बदलावों की जांच करने या उन पर ज़्यादा बारीकी से नज़र रखने में मदद मिलती है. अपने प्रोजेक्ट के लिए, जोखिम का एक सेट तय करें, ताकि लगातार विश्लेषण किया जा सके.

इन बातों का ध्यान रखें:

मेजर वर्शन बंप

क्या मेजर वर्शन का नंबर बदला है?

सेमेंटिक वर्शनिंग में, पहले नंबर को मेजर वर्शन कहा जाता है. उदाहरण के लिए, अगर किसी लाइब्रेरी का वर्शन 1.2.3 से 2.0.1 पर अपग्रेड किया गया है, तो इसका मतलब है कि लाइब्रेरी का मुख्य वर्शन बदल गया है. आम तौर पर, यह इस बात का संकेत होता है कि लाइब्रेरी डेवलपर ने अलग-अलग वर्शन के बीच काम न करने वाले बदलाव किए हैं. जैसे, एपीआई के कुछ हिस्सों को हटाना या उनमें बदलाव करना.

यह मैसेज दिखने पर, इनमें से कोई भी कार्रवाई करते समय, उन लाइब्रेरी पर ज़्यादा ध्यान दें जिन पर असर पड़ा है.

अगर आपका कोड किसी एक्सपेरिमेंटल एपीआई का इस्तेमाल करता है (जिसके लिए आपको अक्सर एनोटेशन या बिल्ड-फ़ाइल की खास बातों का इस्तेमाल करके ऑप्ट-इन करना पड़ता है), तो 1.2.3 से 1.3.1 या 1.2.3 से 1.2.5 जैसे छोटे या पैच वर्शन में बदलाव करने पर भी अतिरिक्त जोखिम हो सकते हैं.

अस्थिर एपीआई

कुछ लाइब्रेरी रिलीज़ में नॉनस्टेबल एपीआई शामिल हो सकते हैं. आम तौर पर, ये ऐसे एपीआई होते हैं जो अभी काम में हैं या किसी ऐसे एपीआई पर निर्भर हैं जो ठीक से काम नहीं करता.

आम तौर पर, ये लाइब्रेरी सिर्फ़ झलक के तौर पर उपलब्ध होती हैं. जैसे, अल्फा, डेवलपर या प्रयोग के तौर पर रिलीज़ की गई लाइब्रेरी. हालांकि, कुछ लाइब्रेरी में ऐसे एपीआई भी शामिल होते हैं जिन्हें प्रयोग के तौर पर या अस्थिर के तौर पर मार्क किया गया हो.

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

डाइनैमिक व्यवहार

कुछ लाइब्रेरी, बाहरी फ़ैक्टर के आधार पर अलग तरह से काम करती हैं. उदाहरण के लिए, कोई लाइब्रेरी जो किसी सर्वर से इंटरैक्ट करती है वह उस सर्वर में होने वाले बदलावों पर निर्भर करती है.

  • क्या लाइब्रेरी को किसी खास सर्वर वर्शन से मैच करना ज़रूरी है?
  • क्या लाइब्रेरी, सर्वर के अलग-अलग वर्शन से कनेक्ट हो सकती है?
  • क्या किसी बाहरी वजह से लाइब्रेरी के सही तरीके से काम करने पर असर पड़ता है?

मेनिफ़ेस्ट मर्ज करना

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

रनटाइम से जुड़े अपडेट

कुछ लाइब्रेरी ऐसी सुविधाओं का उपयोग करती हैं जिन्हें आपके ऐप्लिकेशन के नियंत्रण से बाहर अपडेट किया जा सकता है. कोई लाइब्रेरी, Play services का इस्तेमाल कर सकती है. इसे Android SDK टूल से अलग से अपग्रेड किया जाता है. अन्य लाइब्रेरी, स्वतंत्र रूप से अपडेट किए गए बाहरी ऐप्लिकेशन (आम तौर पर AIDL का इस्तेमाल करके) में सेवाओं से बंधी हो सकती हैं.

आपको कितने वर्शन छोड़ने हैं?

लाइब्रेरी को अपग्रेड करने के लिए, जितना ज़्यादा इंतज़ार करना पड़ेगा, उतने ही ज़्यादा जोखिम हो सकते हैं. अगर आपको किसी वर्शन में काफ़ी बदलाव दिखता है, जैसे कि 1.2.3 से 1.34.5, तो इस लाइब्रेरी पर ज़्यादा ध्यान दें.

डेटा को दूसरी जगह भेजने से जुड़ी गाइड

देखें कि लाइब्रेरी में, डेटा को दूसरी जगह भेजने से जुड़ी गाइड है या नहीं. यह आपके जोखिम के विश्लेषण और कम करने की योजना को काफ़ी हद तक कम कर सकता है.

ध्यान दें कि इस तरह की गाइड का होना इस बात का अच्छा संकेत है कि डेवलपर ने आपके डिवाइस के साथ काम करने की सुविधा पर ध्यान दिया है और उसने आपके अपग्रेड को लागू करने के लिए ज़रूरी कदम उठाए हैं.

रिलीज़ नोट

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

रीडमी

लाइब्रेरी के लिए कुछ README फ़ाइलों में संभावित जोखिमों के बारे में बताया जाता है. ऐसा तब किया जाता है, जब लाइब्रेरी में रिलीज़ नोट न दिए गए हों. _known issues_ (खास तौर पर जानी-पहचानी समस्याएं) से जुड़ी समस्याओं को देखें.

पहले से पता चली हुई कमजोरियों की जांच करना

Play SDK Index, कई लोकप्रिय SDK टूल के लिए जोखिम ट्रैक करता है. Play Console से यह पता चलता है कि आपने सूची में शामिल ऐसे किसी एसडीके टूल का इस्तेमाल किया है या नहीं जिसमें पहले से मौजूद जोखिम हैं. Android Studio में बिल्ड फ़ाइलों में बदलाव करते समय, आईडीई, SDK इंडेक्स की जांच करता है और जोखिम वाली लाइब्रेरी के वर्शन के इस्तेमाल को फ़्लैग करता है.

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

डिपेंडेंसी जांचने की सुविधा का इस्तेमाल करने के लिए, NVD API पासकोड का अनुरोध करें, Gradle प्लग इन सेट अप करें, और ./gradlew dependencyCheckAnalyze चलाएं. ध्यान दें कि इसमें काफ़ी समय लग सकता है.

वर्शन से जुड़े विवाद

क्या वर्शन उम्मीद के मुताबिक रिज़ॉल्व हो रहे हैं? कॉन्फ़िगरेशन में अंतर देखें. खास तौर पर, वर्शन में बड़े अंतर देखें. कॉन्फ़्लिक्ट देखने का तरीका जानने के लिए, Gredle डिपेंडेंसी रिज़ॉल्यूशन देखें. खास तौर पर, ./gradlew app:dependencies रिपोर्ट में -> खोजें.

अगर संभव हो, तो डिपेंडेंसी के लेखकों के साथ मिलकर काम करें, ताकि उनकी डिपेंडेंसी में कोई विरोध न हो. अगर आपकी कंपनी की अनुमति है, तो लाइब्रेरी के साथ काम करने के लिए लाइब्रेरी में बदलाव करें (अपस्ट्रीमिंग).

लाइसेंस की जांच करना

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

मेंटेनेंस और
क्वालिटी से जुड़े जोखिम

सार्वजनिक रिपॉज़िटरी वाली लाइब्रेरी के लिए:

  • लाइब्रेरी को कितने योगदानकर्ता मैनेज कर रहे हैं?
  • आखिरी बार अपग्रेड कब किया गया था और लाइब्रेरी कितनी बार बदलती है?
  • समस्या का बैकलॉग (अगर उपलब्ध हो) कैसा दिखता है? लाइब्रेरी की संभावित समस्याओं और तकनीकी बकाया के बारे में जानने के लिए, इसे स्किम करें.
  • यूनिट टेस्ट, लाइब्रेरी को कितनी अच्छी तरह कवर करते हैं?
  • क्या कोडबेस में एंटी-पैटर्न मौजूद हैं?
  • क्या लाइब्रेरी के बारे में अच्छी तरह से जानकारी दी गई है?
  • क्या कोडबेस में _fixme_ वाली कई टिप्पणियां हैं?

ओपन सोर्स बनाम क्लोज़्ड सोर्स

अगर कोई लाइब्रेरी ओपन सोर्स है, तो क्लोज़्ड सोर्स की तुलना में समस्याओं को डीबग करना आसान होगा. भले ही, समस्याएं आपके कोड या लाइब्रेरी कोड में हों.

क्लोज़्ड सोर्स डिपेंडेंसी को कम से कम करें और उनके आकलन के दौरान ज़्यादा जांच करें. क्या आपके इस्तेमाल के उदाहरण के हिसाब से, अच्छे विकल्प उपलब्ध हैं? क्लोज़्ड सोर्स लाइब्रेरी के लिए कौनसे सेवा-लेवल समझौते उपलब्ध हैं? अगर आपको क्लोज़्ड सोर्स डिपेंडेंसी का इस्तेमाल करना है, तो जोखिम को कम करने के लिए ज़्यादा टेस्ट केस लिखने के लिए तैयार रहें.

बिल्ड रन करें

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

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

एपीआई से जुड़ी समस्याओं का पता लगाने के लिए, lint का इस्तेमाल करना

Android lint आपके ऐप्लिकेशन में कई समस्याओं का पता लगा सकता है. इनमें, कुछ ऐसी समस्याएं भी शामिल हैं जो डिपेंडेंसी या Android SDK टूल के वर्शन में बदलाव होने की वजह से होती हैं. उदाहरण के लिए, अगर आपने compileSdk को अपग्रेड किया है और इसके नए एपीआई का इस्तेमाल किया है, तो lint उन एपीआई की शिकायत करता है जो SDK टूल के पुराने वर्शन में उपलब्ध नहीं हैं.

Lint, Android Studio एडिटर में चलता है. इसमें बदलाव करने पर, समस्याओं की रिपोर्टिंग की जाती है. आम तौर पर, यह Studio में आपके बिल्ड के हिस्से के तौर पर या कमांड-लाइन बिल्ड को चलाने पर तब तक काम नहीं करता, जब तक कि build या lint टारगेट का इस्तेमाल नहीं किया जाता.

अगर कंटिन्यूअस इंटिग्रेशन (सीआई) का इस्तेमाल किया जा रहा है, तो इस तरह की गड़बड़ियों का पता लगाने के लिए, सीआई बिल्ड के दौरान (या कम से कम हर रात के बिल्ड के दौरान) gradlew build या gradlew lint चलाएं.

अगर सीआई का इस्तेमाल नहीं किया जा रहा है, तो कम से कम कभी-कभी gradlew lint चलाना न भूलें.

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

जोखिम कम करना

अपग्रेड से जुड़े जोखिम का पता लगाने के बाद, यह तय करें कि उन्हें कैसे कम किया जाए:

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

अपने फ़ैसलों को दस्तावेज़ में रिकॉर्ड करें. अगर आपका ऐप्लिकेशन चलाते समय, अपग्रेड से होने वाले जोखिम एक समस्या बन जाते हैं, तो जोखिम के विश्लेषण की जानकारी देने वाला दस्तावेज़ ज़रूरी गड़बड़ी विश्लेषण को कम कर सकता है.

लाइसेंस की पुष्टि करना

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

किसी भी रिलीज़ के साथ लाइसेंस बदल सकते हैं. जब भी अपग्रेड करें, तो आपको पुष्टि करनी चाहिए कि इस्तेमाल की जा रही डिपेंडेंसी का लाइसेंस, आपके ऐप्लिकेशन या लाइब्रेरी के साथ काम करता हो.

अगर लाइसेंस काम नहीं करता है या अब काम नहीं करता है, तो लाइसेंस के उस वर्शन का इस्तेमाल नहीं किया जा सकता. यहां आप:

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