SDK Platform: ما هي، الإصدارات و Android SDK Manager

ما هي SDK Platform

SDK Platform هي مكون أساسي من Android SDK، تمثل مجموعة كاملة من المكتبات والأدوات لتطوير التطبيقات لإصدار معين من Android. يتم تحديد كل منصة بواسطة API Level — رقم صحيح يزداد مع إصدارات نظام التشغيل الجديدة. على سبيل المثال، Android 13 يقابل API Level 33، Android 14 يقابل API Level 34، Android 15 يقابل API Level 35.

على عكس Android Studio (IDE)، لا تحتوي SDK Platform على محرر كود أو مصحح أخطاء. إنها طبقة نظام تتصل بالمترجم ونظام البناء. عندما يكتب المطور import android.app.Activity، يأخذ المترجم هذه الفئة من android.jar الخاص بـ SDK Platform محددة. بدون منصة مثبتة بمستوى API المطلوب، لن يتم تجميع الكود.

تصدر Google SDK Platform جديدة لكل إصدار مستقر من Android. يتضمن التاريخ أكثر من 35 API Level — من 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 الإلزامية. يجب على المطور تجميع التطبيق ضد المنصة الحالية لاستخدام هذه الإمكانيات.

في نفس الوقت، يمكن للتطبيق العمل على إصدارات نظام تشغيل قديمة. لهذا، يتم تحديد minSdk في Gradle — الحد الأدنى لمستوى API الذي يعمل عليه التطبيق. يستخدم الكود فحوصات الإصدار واستدعاءات API الشرطية. يضمن هذا النهج التوافق دون فقدان الميزات الجديدة.

تكوين SDK Platform: المكونات الرئيسية

SDK Platform ليست ملفاً واحداً، بل مجموعة من المكونات التي تضمن معاً التجميع والبناء واختبار التطبيق. العنصر الرئيسي هو android.jar — أرشيف مع فئات Android API المضمنة في هذا الإصدار. يتصل هذا الملف بمترجم Kotlin أو Java ويحدد الفئات والطرق والتعليقات التوضيحية المتاحة للمطور.

صور النظام والمحاكي

تتضمن كل SDK Platform System Image — صورة لنظام التشغيل لمحاكي Android Virtual Device. بدون الصورة المقابلة، لا يمكن للمحاكي تشغيل جهاز افتراضي بمستوى API المطلوب. تأتي System Images بأنواع مختلفة: Google APIs (مع خدمات Google)، Google Play (مع Play Store) و AOSP (Android نقي بدون خدمات Google).

أدوات البناء والتصحيح

تتضمن SDK Platform إصداراً من Build-Tools و Platform-Tools محسّناً لمستوى API هذا. تحتوي Build-Tools على aapt2 (أداة تغليف أصول Android)، dx/d8 (مترجم Dalvik/ART) و ApkSigner. توفر Platform-Tools ADB (جسر تصحيح Android) و fastboot و SQLite. يتم تحديث هذه الأدوات بشكل مستقل عن SDK Platform عبر SDK Manager.

موارد المنصة

تتضمن كل منصة موارد Android قياسية — سمات النظام وأنماطه ورسومه المتحركة وألوانه وأبعاده. تُستخدم هذه الموارد أثناء التجميع: إذا أشار المطور إلى @android:style/Theme.Material.Light، يأخذ نظام البناء التعريف من موارد SDK Platform. يضمن هذا مظهراً موحداً لمكونات النظام على جميع الأجهزة.

مستوى API وإصدارات SDK Platform

API Level هو معرف عددي لإصدار Android SDK. كل إصدار من Android يقابله API Level واحد يزداد رتيباً. يحدد المطور API Level في ثلاثة معايير رئيسية في build.gradle: 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) غيّر جذرياً نهج الـ intents — ظهر SplashScreen API وتصدير المكونات عبر السمة exported. جعل Android 14 (API 34) من الإلزامي تحديد أعلام BroadcastReceiver وقدم قيوداً صارمة على الخدمات الأمامية.

يساعد فهم تاريخ API Levels المطور على اختيار استراتيجية التوافق الصحيحة. إذا كان التطبيق يستخدم compileSdk 35 لكن minSdk 26، يمكن للكود استدعاء طرق API 35 فقط بعد التحقق من الإصدار عبر Build.VERSION.SDK_INT. يُسمى هذا النهج التطوير المقيد بالإصدار وهو معيار صناعي.

SDK Manager: التثبيت والإعداد

SDK Manager هي أداة لإدارة مكونات Android SDK: تثبيت SDK Platform جديدة وتحديث الحالية وإزالة القديمة. SDK Manager متاح كواجهة رسومية في Android Studio وكأداة سطر أوامر عبر sdkmanager. من الملائم استخدام سطر أوامر SDK Manager في خطوط CI/CD حيث لا توجد واجهة رسومية.

يقوم SDK Manager بتثبيت المنصات في دليل Android SDK، والذي يوجد افتراضياً في $HOME/Android/Sdk على Linux و macOS أو %LOCALAPPDATA%\Android\Sdk على Windows. داخل دليل platforms توجد مجلدات باسم android-{API Level}، كل منها يحتوي على SDK Platform كاملة.

تثبيت SDK Platform عبر sdkmanager

يقبل أمر sdkmanager معرف حزمة بتنسيق "platforms;android-{API}". على سبيل المثال، لتثبيت SDK Platform 35 يكون الأمر كالتالي:

# تثبيت SDK Platform لمستوى API 35
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 تلقائياً في أول بناء. للقيام بذلك، يجب تحديد compileSdk في build.gradle وإضافة دليل SDK في التكوين المحلي. يعرض Android Studio أيضاً تثبيت المنصة المفقودة عند فتح مشروع — فقط انقر على زر "Install SDK Platform" في نافذة مزامنة Gradle.

من المهم تحديث SDK Platform بانتظام عبر SDK Manager — مع المنصة يتم تحديث Build-Tools و Platform-Tools، مما يؤثر على أداء البناء واستقرار التصحيح. توصي Google بفحص تحديثات SDK كل 2–3 أسابيع، خاصة قبل نشر إصدار جديد من التطبيق على Google Play.

إعداد صورة النظام للمحاكي

لتشغيل المحاكي بمستوى API معين، يجب تثبيت System Image من نفس الإصدار. يسمح SDK Manager بتنزيل صور من بنيات مختلفة (x86_64، arm64-v8a) وأنواع (Google APIs، Google Play، AOSP). بعد تنزيل الصورة، يقوم AVD Manager بإنشاء جهاز افتراضي بناءً عليها.

# تثبيت System Image مع Google APIs لمستوى API 35
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

compileSdk و targetSdk و minSdk في Gradle

ثلاثة معايير في build.gradle تحدد كيفية عمل التطبيق مع SDK Platform. compileSdk هو مستوى API المستخدم للتجميع. يحدد هذا المعيار فئات Android API المتاحة في الكود. يجب أن يكون compileSdk الأحدث بين الثلاثة ولا يؤثر على سلوك وقت التشغيل — يتم تجميع التطبيق لكنه يستخدم فقط API المتاحة على الجهاز.

minSdk هو الحد الأدنى لمستوى API الذي يمكن تثبيت التطبيق عليه. لن يسمح Google Play بتثبيت التطبيق على جهاز بإصدار أقل من minSdk. يحدد هذا المعيار عتبة التوافق ويؤثر على تغطية الجمهور. كلما كان minSdk أقل، زادت الأجهزة المدعومة، لكن قل عدد API الجديدة التي يمكن استخدامها دون فحوصات.

targetSdk هو مستوى API الذي تم اختبار التطبيق عليه. يستخدم نظام Android targetSdk لتطبيق تغييرات السلوك: إذا لم يتم تحديث التطبيق إلى مستوى API جديد، يقوم النظام بتفعيل وضع التوافق للإصدارات القديمة. يتطلب 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 — الأحدث المستقر (35 بداية 2026)، 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)
        }
    }
}

استخدام API جديدة مع @RequiresApi

للطرق التي تُستدعى فقط على إصدارات محددة، استخدم التعليق التوضيحي @RequiresApi. هذا يخبر فحوصات lint أن الطريقة آمنة ويعطل التحذيرات. بالاقتران مع فحص SDK_INT، يجعل التعليق التوضيحي الكود أنظف وأسهل فهماً للمراجعين.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact مع علم SCHEDULE_EXACT_ALARM
    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 المثبتة

أحياناً تحتاج إلى معرفة أي إصدار من SDK Platform مثبت على جهاز المطور أو في CI. يمكن القيام بذلك عبر 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
}