आपके ऐप्लिकेशन का वर्शन

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

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

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

Android सिस्टम, सिस्टम के वर्शन के साथ काम करने की सुविधा को लागू करता है. इसे बिल्ड फ़ाइलों में minSdk सेटिंग के तौर पर दिखाया गया है. इस सेटिंग की मदद से, कोई ऐप्लिकेशन यह तय कर सकता है कि वह कम से कम किस सिस्टम एपीआई के साथ काम कर सकता है. एपीआई से जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, एपीआई लेवल (SDK टूल का वर्शन) से जुड़ी ज़रूरी शर्तें तय करना लेख पढ़ें.

वर्शनिंग की ज़रूरी शर्तें, अलग-अलग प्रोजेक्ट के हिसाब से अलग-अलग होती हैं. हालांकि, कई डेवलपर सिमैंटिक वर्शनिंग को वर्शनिंग की रणनीति के लिए एक अच्छा आधार मानते हैं.

ऐप्लिकेशन के वर्शन की जानकारी सेट करना

अपने ऐप्लिकेशन के वर्शन की जानकारी तय करने के लिए, Gradle बिल्ड फ़ाइलों में वर्शन सेटिंग की वैल्यू सेट करें:

Groovy

    android {
      namespace 'com.example.testapp'
      compileSdk 33

      defaultConfig {
          applicationId "com.example.testapp"
          minSdk 24
          targetSdk 33
          versionCode 1
          versionName "1.0"
          ...
      }
      ...
    }
    ...
    

Kotlin

    android {
      namespace = "com.example.testapp"
      compileSdk = 33

      defaultConfig {
          applicationId = "com.example.testapp"
          minSdk = 24
          targetSdk = 33
          versionCode = 1
          versionName = "1.0"
          ...
      }
      ...
    }
    ...
      

वर्शन की सेटिंग

उपलब्ध दोनों वर्शन सेटिंग के लिए वैल्यू तय करें: versionCode और versionName.

versionCode

यह एक पॉज़िटिव पूर्णांक होता है, जिसका इस्तेमाल इंटरनल वर्शन नंबर के तौर पर किया जाता है. इस नंबर से यह पता चलता है कि कौनसे वर्शन को हाल ही में अपडेट किया गया है. ज़्यादा नंबर का मतलब है कि वर्शन को हाल ही में अपडेट किया गया है. यह वह वर्शन नंबर नहीं है जो उपयोगकर्ताओं को दिखता है. यह नंबर, versionName सेटिंग से सेट होता है. Android सिस्टम, versionCode वैल्यू का इस्तेमाल करके, ऐप्लिकेशन के वर्शन को डाउनग्रेड होने से बचाता है. इसके लिए, वह लोगों को ऐसे APK को इंस्टॉल करने से रोकता है जिसमें versionCode वैल्यू, उनके डिवाइस पर इंस्टॉल किए गए मौजूदा वर्शन की versionCode वैल्यू से कम हो.

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

ध्यान दें: Google Play पर versionCode के लिए सबसे बड़ी वैल्यू 2,10,00,00,000 हो सकती है.

Play Store पर ऐसा APK अपलोड नहीं किया जा सकता जिसमें versionCode का इस्तेमाल किया गया हो. हालांकि, इसका इस्तेमाल पिछले वर्शन के लिए पहले ही किया जा चुका हो.

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

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

versionName

यह एक स्ट्रिंग है. इसका इस्तेमाल, उपयोगकर्ताओं को दिखाए जाने वाले वर्शन नंबर के तौर पर किया जाता है. इस सेटिंग को रॉ स्ट्रिंग के तौर पर या स्ट्रिंग संसाधन के रेफ़रंस के तौर पर सेट किया जा सकता है.

वैल्यू एक स्ट्रिंग होती है, ताकि ऐप्लिकेशन के वर्शन को <major>.<minor>.<point> स्ट्रिंग के तौर पर या किसी अन्य तरह के ऐब्सलूट या रिलेटिव वर्शन आइडेंटिफ़ायर के तौर पर बताया जा सके. versionName ही वह वैल्यू है जो उपयोगकर्ताओं को दिखती है.

वर्शन वैल्यू तय करना

इन सेटिंग के लिए डिफ़ॉल्ट वैल्यू तय की जा सकती हैं. इसके लिए, उन्हें अपने मॉड्यूल की build.gradle या build.gradle.kts फ़ाइल के android {} ब्लॉक में नेस्ट किए गए defaultConfig {} ब्लॉक में शामिल करें. इसके बाद, अपने ऐप्लिकेशन के अलग-अलग वर्शन के लिए, इन डिफ़ॉल्ट वैल्यू को बदला जा सकता है. इसके लिए, आपको हर बिल्ड टाइप या प्रॉडक्ट फ़्लेवर के लिए अलग-अलग वैल्यू तय करनी होंगी. इस फ़ाइल में, defaultConfig {} ब्लॉक में versionCode और versionName सेटिंग के साथ-साथ productFlavors {} ब्लॉक दिखाया गया है.

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

Groovy

    android {
        ...
        defaultConfig {
            ...
            versionCode 2
            versionName "1.1"
        }
        productFlavors {
            demo {
                ...
                versionName "1.1-demo"
            }
            full {
                ...
            }
        }
    }
    

Kotlin

    android {
        ...
        defaultConfig {
            ...
            versionCode = 2
            versionName = "1.1"
        }
        productFlavors {
            create("demo") {
                ...
                versionName = "1.1-demo"
            }
            create("full") {
                ...
            }
        }
    }
    

इस उदाहरण के defaultConfig {} ब्लॉक में, versionCode वैल्यू से पता चलता है कि मौजूदा APK में ऐप्लिकेशन की दूसरी रिलीज़ शामिल है. साथ ही, versionName स्ट्रिंग से पता चलता है कि यह उपयोगकर्ताओं को वर्शन 1.1 के तौर पर दिखेगा. इस फ़ाइल में, प्रॉडक्ट के दो वर्शन भी तय किए गए हैं: "demo" और "full." "demo" प्रॉडक्ट फ़्लेवर के लिए versionName को "1.1-demo" के तौर पर तय किया गया है. इसलिए, "demo" बिल्ड में डिफ़ॉल्ट वैल्यू के बजाय इस versionName का इस्तेमाल किया जाता है. "full" प्रॉडक्ट फ़्लेवर ब्लॉक में versionName को तय नहीं किया गया है. इसलिए, यह "1.1" की डिफ़ॉल्ट वैल्यू का इस्तेमाल करता है.

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

Android फ़्रेमवर्क, एक एपीआई उपलब्ध कराता है. इसकी मदद से, सिस्टम से अपने ऐप्लिकेशन के वर्शन की जानकारी के बारे में क्वेरी की जा सकती है. वर्शन की जानकारी पाने के लिए, PackageManager.getPackageInfo(java.lang.String, int) तरीके का इस्तेमाल करें.

एपीआई लेवल (एसडीके वर्शन) से जुड़ी ज़रूरी शर्तें तय करना

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

ध्यान दें: अगर आपने एपीआई लेवल की ज़रूरी शर्तों को सीधे तौर पर अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में बताया है, तो बिल्ड फ़ाइलों में मौजूद सेटिंग, मेनिफ़ेस्ट फ़ाइल में मौजूद सेटिंग को बदल देंगी. इसके अलावा, Gradle बिल्ड फ़ाइलों में इन सेटिंग को तय करने से, आपको अपने ऐप्लिकेशन के अलग-अलग वर्शन के लिए अलग-अलग वैल्यू तय करने की सुविधा मिलती है. ज़्यादा सुविधा पाने और मेनिफ़ेस्ट मर्ज होने पर संभावित ओवरराइटिंग से बचने के लिए, इन एट्रिब्यूट को <uses-sdk> एलिमेंट से हटाएं. इसके बजाय, Gradle बिल्ड फ़ाइलों में अपने एपीआई लेवल की सेटिंग तय करें.

एपीआई लेवल की दो सेटिंग उपलब्ध हैं:

• minSdk — Android प्लैटफ़ॉर्म का वह कम से कम वर्शन जिस पर ऐप्लिकेशन चलेगा. इसे प्लैटफ़ॉर्म के एपीआई लेवल आइडेंटिफ़ायर से तय किया जाता है.
• targetSdk — यह एपीआई लेवल, <SDK_INT> कॉन्स्टेंट से जुड़ा होता है. इसी लेवल पर ऐप्लिकेशन को चलाने के लिए डिज़ाइन किया जाता है. कुछ मामलों में, इससे ऐप्लिकेशन को टारगेट एपीआई लेवल में तय किए गए मेनिफ़ेस्ट एलिमेंट या व्यवहारों का इस्तेमाल करने की अनुमति मिलती है. इसके बजाय, ऐप्लिकेशन को सिर्फ़ उन एलिमेंट या व्यवहारों का इस्तेमाल करने की अनुमति मिलती है जो कम से कम एपीआई लेवल के लिए तय किए गए हैं.

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

if (SDK_INT_FULL >= VERSION_CODES_FULL.[MAJOR or MINOR RELEASE]) {
  // Use APIs introduced in a major or minor SDK version
}

build.gradle या build.gradle.kts फ़ाइल में, एपीआई लेवल की डिफ़ॉल्ट ज़रूरी शर्तों के बारे में बताने के लिए, defaultConfig{} ब्लॉक में एपीआई लेवल की एक या उससे ज़्यादा सेटिंग जोड़ें. यह ब्लॉक, android {} ब्लॉक में नेस्ट किया गया है. बिल्ड टाइप या प्रॉडक्ट फ़्लेवर में सेटिंग जोड़कर, अपने ऐप्लिकेशन के अलग-अलग वर्शन के लिए इन डिफ़ॉल्ट वैल्यू को बदला भी जा सकता है.

इस फ़ाइल में, defaultConfig {} ब्लॉक में minSdk और targetSdk की डिफ़ॉल्ट सेटिंग के बारे में बताया गया है. साथ ही, इसमें प्रॉडक्ट के एक फ़्लेवर के लिए minSdk की सेटिंग में बदलाव करने की जानकारी दी गई है:

Groovy

android {
    ...
    defaultConfig {
        ...
        minSdk 21
        targetSdk 33
    }
    productFlavors {
        main {
            ...
        }
        afterNougat {
            ...
            minSdk 24
        }
    }
}

Kotlin

android {
    ...
    defaultConfig {
        ...
        minSdk = 21
        targetSdk = 33
    }
    productFlavors {
        create("main") {
            ...
        }
        create("afterNougat") {
            ...
            minSdk = 24
        }
    }
}

ऐप्लिकेशन इंस्टॉल करने से पहले, सिस्टम इन सेटिंग की वैल्यू की जांच करता है. साथ ही, इनकी तुलना सिस्टम के वर्शन से करता है. अगर minSdk की वैल्यू सिस्टम वर्शन से ज़्यादा है, तो सिस्टम ऐप्लिकेशन को इंस्टॉल होने से रोक देता है.

इन सेटिंग को तय न करने पर, सिस्टम यह मान लेता है कि आपका ऐप्लिकेशन सभी प्लैटफ़ॉर्म वर्शन के साथ काम करता है. यह minSdk को 1 पर सेट करने के बराबर है.

ज़्यादा जानकारी के लिए, एपीआई लेवल क्या है? लेख पढ़ें. Gradle की बिल्ड सेटिंग के लिए, बिल्ड वैरिएंट कॉन्फ़िगर करना लेख पढ़ें.