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, на котором приложение запускается. Код использует проверки версий и conditional API calls. Такой подход обеспечивает совместимость без потери новых функций.

Состав 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 permissions — приложение запрашивает разрешения во время работы, а не при установке. Android 8.0 (API 26) ввёл автозаполнение форм и каналы уведомлений. Android 12 (API 31) кардинально изменил подход к интентам — появился SplashScreen API и экспорт компонентов через exported-атрибут. Android 14 (API 34) обязал указывать флаги для BroadcastReceiver и ввёл строгие ограничения на foreground services.

Понимание истории 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) {
            // Notification channels доступны с API 26
            val channel = NotificationChannel(
                "updates",
                "Обновления",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Использование новых API с @RequiresApi

Для методов, которые вызываются только на определённых версиях, используйте аннотацию @RequiresApi. Это подсказывает lint-проверкам, что метод безопасен, и отключает предупреждения. В kombinации с проверкой 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
}