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 Level код не скомпілюється.

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-прапорці. Розробник повинен зібрати додаток проти актуальної платформи, щоб використовувати ці можливості.

При цьому додаток може працювати на старих версіях ОС. Для цього в Gradle вказують minSdk — мінімальний API Level, на якому додаток запускається. Код використовує перевірки версій та умовні виклики API. Такий підхід забезпечує сумісність без втрати нових функцій.

Склад SDK Platform: основні компоненти

SDK Platform — це не один файл, а набір компонентів, які разом забезпечують компіляцію, збірку та тестування додатка. Основний елемент — android.jar — архів з класами Android API, включеними в дану версію. Цей файл підключається до компілятора Kotlin або Java і визначає, які класи, методи та анотації доступні розробнику.

Системні образи та емулятор

Кожна SDK Platform включає System Image — образ операційної системи для емулятора Android Virtual Device. Без відповідного образу емулятор не зможе запустити віртуальний пристрій з потрібним API Level. System Images бувають різних типів: Google APIs (із сервісами Google), Google Play (з Play Store) та AOSP (чистий Android без сервісів Google).

Інструменти збірки та налагодження

SDK Platform включає версію Build-Tools та Platform-Tools, оптимізовані для даного API Level. 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, який монотонно збільшується. Розробник вказує 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) додав дозволи runtime — додаток запитує дозволи під час роботи, а не при встановленні. Android 8.0 (API 26) ввів автозаповнення форм та канали сповіщень. Android 12 (API 31) кардинально змінив підхід до інтентів — з'явився SplashScreen API та експорт компонентів через exported-атрибут. Android 14 (API 34) зобов'язав вказувати прапорці для BroadcastReceiver та ввів суворі обмеження на служби переднього плану.

Розуміння історії API Level допомагає розробнику вибрати правильну стратегію сумісності. Якщо додаток використовує compileSdk 35, але minSdk 26, код може викликати методи API 35 тільки після перевірки версії через Build.VERSION.SDK_INT. Такий підхід називається version-gated development і є стандартом індустрії.

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 Level 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 directory в локальну конфігурацію. Android Studio також пропонує встановити відсутню платформу при відкритті проекту — достатньо натиснути кнопку "Install SDK Platform" у вікні синхронізації Gradle.

Важливо регулярно оновлювати SDK Platform через SDK Manager — разом з платформою оновлюються Build-Tools та Platform-Tools, що впливає на продуктивність збірки та стабільність налагодження. Google рекомендує перевіряти оновлення SDK кожні 2–3 тижні, особливо перед публікацією нової версії додатка в Google Play.

Налаштування системного образу для емулятора

Для запуску емулятора з конкретним API Level потрібно встановити 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 Level, який використовується для компіляції. Цей параметр вказує, які класи Android API доступні в коді. compileSdk повинен бути найновішим серед усіх трьох і не впливає на поведінку runtime — додаток компілюється, але використовує тільки ті API, які є на пристрої.

minSdk — мінімальний API Level, на якому додаток може бути встановлений. Google Play не дозволить встановити додаток на пристрій з версією нижче minSdk. Цей параметр визначає поріг сумісності та впливає на охоплення аудиторії. Чим нижчий minSdk, тим більше пристроїв підтримується, але тим менше нових API можна використовувати без перевірок.

targetSdk — API Level, під який додаток тестувався. Система Android використовує targetSdk для застосування behavioural changes: якщо додаток не оновлено до нового 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 — останній стабільний (35 на початок 2026), minSdk — API 26 (Android 8.0, покриває 95% пристроїв), targetSdk — останній стабільний. Для оновлення існуючого додатка: підвищуйте compileSdk одразу, targetSdk — після тестування всіх behavioural changes, minSdk — тільки при необхідності відмовитися від застарілих пристроїв.

Google вимагає, щоб targetSdk оновлювався протягом року після виходу нової версії Android. Додатки, які не відповідають цій вимозі, не можуть публікувати оновлення в Google Play. Для відстеження дедлайнів використовуйте офіційний календар Android OS updates.

Приклади роботи з SDK Platform в коді

При розробці під різні версії Android необхідно враховувати доступність API. Якщо додаток використовує compileSdk 35, але працює на пристрої з API 31, виклик методів, доданих в API 34, призведе до NoSuchMethodError або AbstractMethodError. Для безпечного виклику нових API застосовуються перевірки версій через Build.VERSION.SDK_INT.

Перевірка API Level в runtime

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 пристрою допомагає при тестуванні version-specific поведінки.

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
}