SDK Platform: यह क्या है, संस्करण और Android SDK Manager

SDK Platform क्या है

SDK Platform Android SDK का एक मूलभूत घटक है, जो Android के किसी विशिष्ट संस्करण के लिए एप्लिकेशन विकसित करने हेतु लाइब्रेरी और टूल्स का एक पूर्ण सेट प्रस्तुत करता है। प्रत्येक प्लेटफ़ॉर्म की पहचान उसके API Level से होती है — एक पूर्णांक जो नए OS रिलीज़ के साथ बढ़ता है। उदाहरण के लिए, Android 13 API Level 33 से, Android 14 API Level 34 से, Android 15 API Level 35 से मेल खाता है।

Android Studio (IDE) के विपरीत, SDK Platform में कोड एडिटर या डीबगर नहीं होता है। यह एक सिस्टम लेयर है जो कंपाइलर और बिल्ड सिस्टम से जुड़ती है। जब कोई डेवलपर import android.app.Activity लिखता है, तो कंपाइलर इस क्लास को किसी विशिष्ट SDK Platform के android.jar से लेता है। आवश्यक API Level वाली स्थापित प्लेटफ़ॉर्म के बिना, कोड संकलित नहीं होगा।

Google प्रत्येक स्थिर Android संस्करण के लिए एक नई SDK Platform जारी करता है। इतिहास में 35 से अधिक API Levels शामिल हैं — Android 1.0 (API 1) से Android 15 (API 35) तक। प्रत्येक प्लेटफ़ॉर्म पिछड़ा-संगत है: API Level 21 के लिए लिखा गया कोड API Level 35 पर चलेगा, लेकिन इसके विपरीत नहीं।

प्रत्येक संस्करण के लिए अलग SDK Platform की आवश्यकता क्यों है

Android तेज़ी से विकसित होता है: प्रत्येक संस्करण नई API जोड़ता है, मौजूदा के व्यवहार को बदलता है और प्रतिबंध लाता है। उदाहरण के लिए, Android 10 (API 29) ने Scoped Storage पेश किया, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — अनिवार्य BroadcastReceiver फ़्लैग। डेवलपर को इन क्षमताओं का उपयोग करने के लिए वर्तमान प्लेटफ़ॉर्म के विरुद्ध एप्लिकेशन संकलित करना चाहिए।

साथ ही, एप्लिकेशन पुराने OS संस्करणों पर चल सकता है। इसके लिए, Gradle में minSdk निर्दिष्ट किया जाता है — न्यूनतम API Level जिस पर एप्लिकेशन चलता है। कोड संस्करण जाँच और सशर्त API कॉल का उपयोग करता है। यह दृष्टिकोण नई सुविधाओं को खोए बिना संगतता सुनिश्चित करता है।

SDK Platform संरचना: मुख्य घटक

SDK Platform एक फ़ाइल नहीं है, बल्कि घटकों का एक सेट है जो एक साथ एप्लिकेशन के संकलन, निर्माण और परीक्षण को सुनिश्चित करते हैं। मुख्य तत्व android.jar है — इस संस्करण में शामिल Android API क्लासेस के साथ एक संग्रह। यह फ़ाइल Kotlin या Java कंपाइलर से जुड़ती है और यह निर्धारित करती है कि डेवलपर के लिए कौन सी क्लासेस, विधियाँ और एनोटेशन उपलब्ध हैं।

सिस्टम इमेज और एमुलेटर

प्रत्येक SDK Platform में Android Virtual Device एमुलेटर के लिए एक System Image — ऑपरेटिंग सिस्टम इमेज शामिल होती है। संबंधित इमेज के बिना, एमुलेटर आवश्यक API Level वाला वर्चुअल डिवाइस शुरू नहीं कर सकता। System Images विभिन्न प्रकारों में आती हैं: Google APIs (Google सेवाओं के साथ), Google Play (Play Store के साथ) और AOSP (Google सेवाओं के बिना शुद्ध Android)।

बिल्ड और डीबग टूल्स

SDK Platform में इस API Level के लिए अनुकूलित Build-Tools और Platform-Tools का एक संस्करण शामिल है। Build-Tools में aapt2 (Android Asset Packaging Tool), dx/d8 (Dalvik/ART कंपाइलर) और ApkSigner शामिल हैं। Platform-Tools ADB (Android Debug Bridge), fastboot और SQLite प्रदान करते हैं। ये टूल्स SDK Platform से स्वतंत्र रूप से SDK Manager के माध्यम से अपडेट किए जाते हैं।

प्लेटफ़ॉर्म संसाधन

प्रत्येक प्लेटफ़ॉर्म में मानक Android संसाधन शामिल हैं — सिस्टम थीम, शैलियाँ, एनिमेशन, रंग और आयाम। ये संसाधन संकलन के दौरान उपयोग किए जाते हैं: यदि कोई डेवलपर @android:style/Theme.Material.Light का संदर्भ देता है, तो बिल्ड सिस्टम SDK Platform संसाधनों से परिभाषा लेता है। यह सभी उपकरणों पर सिस्टम घटकों की एक समान उपस्थिति सुनिश्चित करता है।

API Level और SDK Platform संस्करण

API Level Android SDK संस्करण का एक पूर्णांक पहचानकर्ता है। प्रत्येक Android रिलीज़ एक API Level से मेल खाता है, जो एकदिशीय रूप से बढ़ता है। डेवलपर तीन मुख्य build.gradle पैरामीटर में API Level निर्दिष्ट करता है: compileSdk, minSdk और targetSdk। इन मापदंडों का चुनाव यह निर्धारित करता है कि कौन सी API उपलब्ध हैं और सिस्टम एप्लिकेशन को कैसे संभालता है।

Google minSdk को वर्तमान वितरण सीमा से कम न रखने की सलाह देता है — Android Studio Distribution Dashboard (2026) के अनुसार, लगभग 95% डिवाइस Android 8.0 (API 26) और उससे ऊपर चलते हैं। compileSdk नवीनतम स्थिर होना चाहिए — यह नई API तक पहुँच प्रदान करता है और lint जाँच को पदावनत विधियों का पता लगाने की अनुमति देता है।

API Level का विकास: मुख्य परिवर्तन

प्रत्येक नए API Level के साथ, Google महत्वपूर्ण परिवर्तन लाता है। Android 6.0 (API 23) ने रनटाइम अनुमतियाँ जोड़ीं — एप्लिकेशन स्थापना के समय नहीं, बल्कि निष्पादन के दौरान अनुमतियाँ माँगता है। Android 8.0 (API 26) ने ऑटोफ़िल फ़ॉर्म और सूचना चैनल पेश किए। Android 12 (API 31) ने इंटेंट के दृष्टिकोण को मौलिक रूप से बदल दिया — SplashScreen API और exported विशेषता के माध्यम से घटक निर्यात दिखाई दिया। Android 14 (API 34) ने BroadcastReceiver के लिए फ़्लैग निर्दिष्ट करना अनिवार्य कर दिया और अग्रभूमि सेवाओं पर सख्त प्रतिबंध लगाए।

API Levels के इतिहास को समझने से डेवलपर को सही संगतता रणनीति चुनने में मदद मिलती है। यदि एप्लिकेशन compileSdk 35 का उपयोग करता है लेकिन minSdk 26, तो कोड Build.VERSION.SDK_INT के माध्यम से संस्करण की जाँच के बाद ही API 35 विधियों को कॉल कर सकता है। इस दृष्टिकोण को संस्करण-गेटेड डेवलपमेंट कहा जाता है और यह एक उद्योग मानक है।

SDK Manager: स्थापना और सेटअप

SDK Manager Android SDK घटकों के प्रबंधन के लिए एक उपकरण है: नई SDK Platform स्थापित करना, मौजूदा को अपडेट करना और पुराने को हटाना। SDK Manager Android Studio में ग्राफ़िकल इंटरफ़ेस के साथ-साथ sdkmanager के माध्यम से कमांड-लाइन टूल के रूप में उपलब्ध है। SDK Manager की कमांड लाइन CI/CD पाइपलाइनों में उपयोग करना सुविधाजनक है जहाँ कोई ग्राफ़िकल इंटरफ़ेस नहीं है।

SDK Manager प्लेटफ़ॉर्म को Android SDK निर्देशिका में स्थापित करता है, जो डिफ़ॉल्ट रूप से Linux और macOS पर $HOME/Android/Sdk या Windows पर %LOCALAPPDATA%\Android\Sdk पर स्थित है। platforms निर्देशिका के अंदर android-{API Level} नाम के फ़ोल्डर हैं, जिनमें से प्रत्येक में पूर्ण SDK Platform है।

sdkmanager के माध्यम से SDK Platform स्थापित करना

sdkmanager कमांड "platforms;android-{API}" प्रारूप में एक पैकेज पहचानकर्ता स्वीकार करता है। उदाहरण के लिए, SDK Platform 35 स्थापित करने के लिए कमांड इस प्रकार है:

# API Level 35 के लिए SDK Platform स्थापित करें
sdkmanager "platforms;android-35"

# एक कमांड से कई प्लेटफ़ॉर्म स्थापित करें
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# स्थापित प्लेटफ़ॉर्म की सूची
sdkmanager --list_installed | grep platforms

# पुराने प्लेटफ़ॉर्म को हटाएँ
sdkmanager --uninstall "platforms;android-28"

Gradle के माध्यम से स्वचालित स्थापना

आधुनिक Android प्रोजेक्ट Gradle Plugin का उपयोग करते हैं, जो पहले बिल्ड पर स्वचालित रूप से SDK Platform स्थापित कर सकता है। ऐसा करने के लिए, build.gradle में compileSdk निर्दिष्ट करना और स्थानीय कॉन्फ़िगरेशन में SDK निर्देशिका जोड़ना आवश्यक है। Android Studio प्रोजेक्ट खोलते समय लापता प्लेटफ़ॉर्म स्थापित करने की भी पेशकश करता है — बस Gradle सिंक विंडो में "Install SDK Platform" बटन पर क्लिक करें।

SDK Manager के माध्यम से नियमित रूप से SDK Platform को अपडेट करना महत्वपूर्ण है — प्लेटफ़ॉर्म के साथ Build-Tools और Platform-Tools भी अपडेट होते हैं, जो बिल्ड प्रदर्शन और डीबगिंग स्थिरता को प्रभावित करता है। Google हर 2–3 सप्ताह में SDK अपडेट की जाँच करने की सलाह देता है, विशेष रूप से Google Play पर एप्लिकेशन का नया संस्करण प्रकाशित करने से पहले।

एमुलेटर के लिए सिस्टम इमेज सेट करना

एमुलेटर को किसी विशिष्ट API Level के साथ चलाने के लिए, उसी संस्करण की System Image स्थापित करनी होगी। SDK Manager विभिन्न आर्किटेक्चर (x86_64, arm64-v8a) और प्रकारों (Google APIs, Google Play, AOSP) की इमेज डाउनलोड करने की अनुमति देता है। इमेज डाउनलोड करने के बाद, AVD Manager उसके आधार पर एक वर्चुअल डिवाइस बनाता है।

# API 35 के लिए Google APIs के साथ System Image स्थापित करें
sdkmanager "system-images;android-35;google_apis;x86_64"

# कमांड लाइन के माध्यम से AVD बनाएँ
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# बनाए गए AVD की सूची
avdmanager list avd

Gradle में compileSdk, targetSdk और minSdk

build.gradle में तीन पैरामीटर यह परिभाषित करते हैं कि एप्लिकेशन SDK Platform के साथ कैसे काम करता है। compileSdk संकलन के लिए उपयोग किया जाने वाला API Level है। यह पैरामीटर निर्दिष्ट करता है कि कोड में कौन सी Android API क्लासेस उपलब्ध हैं। compileSdk तीनों में सबसे नया होना चाहिए और रनटाइम व्यवहार को प्रभावित नहीं करता है — एप्लिकेशन संकलित होता है लेकिन डिवाइस पर उपलब्ध केवल API का उपयोग करता है।

minSdk न्यूनतम API Level है जिस पर एप्लिकेशन स्थापित किया जा सकता है। Google Play minSdk से कम संस्करण वाले डिवाइस पर एप्लिकेशन स्थापित करने की अनुमति नहीं देगा। यह पैरामीटर संगतता सीमा को परिभाषित करता है और दर्शक कवरेज को प्रभावित करता है। minSdk जितना कम होगा, उतने अधिक डिवाइस समर्थित होंगे, लेकिन बिना जाँच के उतनी ही कम नई API का उपयोग किया जा सकता है।

targetSdk वह API Level है जिसके विरुद्ध एप्लिकेशन का परीक्षण किया गया। Android सिस्टम व्यवहार परिवर्तन लागू करने के लिए targetSdk का उपयोग करता है: यदि एप्लिकेशन को नए API Level में अपडेट नहीं किया गया है, तो सिस्टम पुराने संस्करणों के लिए संगतता मोड सक्षम करता है। Google Play को targetSdk को एक निश्चित स्तर से कम नहीं होना आवश्यक है — 2026 तक यह API 34 (Android 14) है।

Gradle कॉन्फ़िगरेशन उदाहरण

android {
    compileSdk 35

    defaultConfig {
        applicationId "com.example.app"
        minSdk 26
        targetSdk 35
        versionCode 1
        versionName "1.0"
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
}

// Android SDK संस्करण SDK Manager के माध्यम से स्थापित किया जाना चाहिए
// sdkmanager "platforms;android-35"

compileSdk, minSdk और targetSdk कैसे चुनें

चयन रणनीति परियोजना के लक्ष्यों पर निर्भर करती है। नए एप्लिकेशन के लिए: compileSdk — नवीनतम स्थिर (2026 की शुरुआत में 35), minSdk — API 26 (Android 8.0, 95% डिवाइस को कवर करता है), targetSdk — नवीनतम स्थिर। मौजूदा एप्लिकेशन को अपडेट करने के लिए: compileSdk को तुरंत बढ़ाएँ, targetSdk — सभी व्यवहार परिवर्तनों के परीक्षण के बाद, minSdk — केवल तभी जब पुराने डिवाइसों के लिए समर्थन छोड़ना आवश्यक हो।

Google को आवश्यक है कि targetSdk को Android के नए संस्करण के जारी होने के एक वर्ष के भीतर अपडेट किया जाए। इस आवश्यकता को पूरा न करने वाले एप्लिकेशन Google Play पर अपडेट प्रकाशित नहीं कर सकते। समय-सीमा को ट्रैक करने के लिए, आधिकारिक Android OS अपडेट कैलेंडर का उपयोग करें।

कोड में SDK Platform के साथ काम करने के उदाहरण

विभिन्न Android संस्करणों के लिए विकास करते समय, API उपलब्धता पर विचार करना आवश्यक है। यदि एप्लिकेशन compileSdk 35 का उपयोग करता है लेकिन API 31 वाले डिवाइस पर चलता है, तो API 34 में जोड़ी गई विधियों को कॉल करने से NoSuchMethodError या AbstractMethodError होगा। नई API को सुरक्षित रूप से कॉल करने के लिए, Build.VERSION.SDK_INT के माध्यम से संस्करण जाँच का उपयोग किया जाता है।

रनटाइम में API Level जाँच

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // सूचना चैनल API 26 से उपलब्ध हैं
            val channel = NotificationChannel(
                "updates",
                "अपडेट",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

@RequiresApi के साथ नई API का उपयोग

उन विधियों के लिए जो केवल विशिष्ट संस्करणों पर कॉल की जाती हैं, @RequiresApi एनोटेशन का उपयोग करें। यह lint जाँच को बताता है कि विधि सुरक्षित है और चेतावनियों को अक्षम करता है। SDK_INT जाँच के साथ संयुक्त, एनोटेशन कोड को क्लीनर और समीक्षकों के लिए अधिक समझने योग्य बनाता है।

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: SCHEDULE_EXACT_ALARM फ़्लैग के साथ scheduleExact
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // SCHEDULE_EXACT_ALARM अनुमति का अनुरोध करें
        val intent = Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM)
        context.startActivity(intent)
    }
}

fun safeScheduleAlarm(context: Context, triggerTime: Long) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        scheduleExactAlarm(getAlarmManager(context), triggerTime)
    } else {
        // अनुमति जाँच के बिना पुरानी setExact विधि
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

स्थापित SDK Platform का निर्धारण

कभी-कभी यह जानना आवश्यक होता है कि डेवलपर के डिवाइस या CI में SDK Platform का कौन सा संस्करण स्थापित है। यह ADB के माध्यम से या प्रोग्रामेटिक रूप से एप्लिकेशन कोड में किया जा सकता है। डिवाइस के API Level को जानने से संस्करण-विशिष्ट व्यवहार का परीक्षण करने में मदद मिलती है।

fun logDeviceInfo() {
    with (Build.VERSION) {
        Log.d("SDK_Demo", "SDK_INT: $SDK_INT")
        Log.d("SDK_Demo", "RELEASE: $RELEASE")
        Log.d("SDK_Demo", "CODENAME: $CODENAME")
        Log.d("SDK_Demo", "PREVIEW_SDK_INT: $PREVIEW_SDK_INT")
    }
    // आउटपुट: SDK_INT: 35, RELEASE: 15, CODENAME: REL
}