SDK Platform: What It Is, Versions and Android SDK Manager

What is SDK Platform

SDK Platform is a fundamental component of the Android SDK, representing a complete set of libraries and tools for developing applications for a specific Android version. Each platform is identified by its API Level — an integer that increases with new OS releases. For example, Android 13 corresponds to API Level 33, Android 14 to API Level 34, Android 15 to API Level 35.

Unlike Android Studio (IDE), SDK Platform does not contain a code editor or debugger. It is a system layer that connects to the compiler and build system. When a developer writes import android.app.Activity, the compiler takes this class from android.jar of a specific SDK Platform. Without an installed platform with the required API Level, the code will not compile.

Google releases a new SDK Platform for each stable Android version. The history includes over 35 API Levels — from Android 1.0 (API 1) to Android 15 (API 35). Each platform is backward compatible: code written for API Level 21 will run on API Level 35, but not vice versa.

Why a separate SDK Platform is needed for each version

Android evolves rapidly: each version adds new APIs, changes the behavior of existing ones and introduces restrictions. For example, Android 10 (API 29) introduced Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — mandatory BroadcastReceiver flags. A developer must compile the application against the current platform to use these capabilities.

At the same time, the application can run on older OS versions. To achieve this, minSdk is specified in Gradle — the minimum API Level on which the application runs. The code uses version checks and conditional API calls. This approach ensures compatibility without losing new features.

SDK Platform Composition: Main Components

SDK Platform is not a single file, but a set of components that together ensure compilation, building and testing of the application. The main element is android.jar — an archive with Android API classes included in this version. This file connects to the Kotlin or Java compiler and determines which classes, methods and annotations are available to the developer.

System Images and Emulator

Each SDK Platform includes a System Image — an operating system image for the Android Virtual Device emulator. Without the corresponding image, the emulator cannot start a virtual device with the required API Level. System Images come in different types: Google APIs (with Google services), Google Play (with Play Store) and AOSP (pure Android without Google services).

Build and Debug Tools

SDK Platform includes a version of Build-Tools and Platform-Tools optimized for this API Level. Build-Tools contain aapt2 (Android Asset Packaging Tool), dx/d8 (Dalvik/ART compiler) and ApkSigner. Platform-Tools provide ADB (Android Debug Bridge), fastboot and SQLite. These tools are updated independently of SDK Platform via SDK Manager.

Platform Resources

Each platform includes standard Android resources — system themes, styles, animations, colors and dimensions. These resources are used during compilation: if a developer references @android:style/Theme.Material.Light, the build system takes the definition from the SDK Platform resources. This ensures a consistent look of system components across all devices.

API Level and SDK Platform Versions

API Level is an integer identifier of the Android SDK version. Each Android release corresponds to one API Level, which monotonically increases. The developer specifies API Level in three key build.gradle parameters: compileSdk, minSdk and targetSdk. The choice of these parameters determines which APIs are available and how the system handles the application.

Google recommends keeping minSdk at a level not lower than the current distribution threshold — according to Android Studio Distribution Dashboard (2026), about 95% of devices run Android 8.0 (API 26) and above. compileSdk should be the latest stable — this provides access to new APIs and allows lint checks to detect deprecated methods.

API Level Evolution: Key Changes

With each new API Level, Google introduces significant changes. Android 6.0 (API 23) added runtime permissions — the application requests permissions during execution, not at installation. Android 8.0 (API 26) introduced autofill forms and notification channels. Android 12 (API 31) radically changed the approach to intents — SplashScreen API appeared and component export via the exported attribute. Android 14 (API 34) made it mandatory to specify flags for BroadcastReceiver and introduced strict restrictions on foreground services.

Understanding the history of API Levels helps the developer choose the right compatibility strategy. If the application uses compileSdk 35 but minSdk 26, the code can call API 35 methods only after checking the version via Build.VERSION.SDK_INT. This approach is called version-gated development and is an industry standard.

SDK Manager: Installation and Setup

SDK Manager is a tool for managing Android SDK components: installing new SDK Platform, updating existing ones and removing outdated ones. SDK Manager is available as a graphical interface in Android Studio as well as a command-line tool through sdkmanager. The command-line SDK Manager is convenient to use in CI/CD pipelines where there is no graphical interface.

SDK Manager installs platforms into the Android SDK directory, which by default is located at $HOME/Android/Sdk on Linux and macOS or %LOCALAPPDATA%\Android\Sdk on Windows. Inside the platforms directory there are folders named android-{API Level}, each containing the complete SDK Platform.

Installing SDK Platform via sdkmanager

The sdkmanager command accepts a package identifier in the format "platforms;android-{API}". For example, to install SDK Platform 35 the command looks like this:

# Install SDK Platform for API Level 35
sdkmanager "platforms;android-35"

# Install multiple platforms with one command
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# List installed platforms
sdkmanager --list_installed | grep platforms

# Remove outdated platform
sdkmanager --uninstall "platforms;android-28"

Automatic Installation via Gradle

Modern Android projects use Gradle Plugin, which can automatically install SDK Platform on the first build. To do this, you need to specify compileSdk in build.gradle and add the SDK directory in the local configuration. Android Studio also offers to install the missing platform when opening a project — just click the "Install SDK Platform" button in the Gradle sync window.

It is important to regularly update SDK Platform via SDK Manager — together with the platform, Build-Tools and Platform-Tools are updated, which affects build performance and debugging stability. Google recommends checking SDK updates every 2–3 weeks, especially before publishing a new application version on Google Play.

Setting Up a System Image for the Emulator

To run the emulator with a specific API Level, you need to install a System Image of the same version. SDK Manager allows downloading images of different architectures (x86_64, arm64-v8a) and types (Google APIs, Google Play, AOSP). After downloading the image, AVD Manager creates a virtual device based on it.

# Install System Image with Google APIs for API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Create AVD via command line
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# List created AVDs
avdmanager list avd

compileSdk, targetSdk and minSdk in Gradle

Three parameters in build.gradle define how the application works with SDK Platform. compileSdk is the API Level used for compilation. This parameter specifies which Android API classes are available in the code. compileSdk should be the newest among all three and does not affect runtime behavior — the application compiles but uses only the APIs available on the device.

minSdk is the minimum API Level on which the application can be installed. Google Play will not allow installing the application on a device with a version lower than minSdk. This parameter defines the compatibility threshold and affects audience coverage. The lower the minSdk, the more devices are supported, but the fewer new APIs can be used without checks.

targetSdk is the API Level against which the application was tested. The Android system uses targetSdk to apply behavioral changes: if the application is not updated to a new API Level, the system enables compatibility mode for older versions. Google Play requires targetSdk to be not lower than a certain level — as of 2026 it is API 34 (Android 14).

Gradle Configuration Example

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 version must be installed via SDK Manager
// sdkmanager "platforms;android-35"

How to choose compileSdk, minSdk and targetSdk

The selection strategy depends on the project goals. For a new application: compileSdk — latest stable (35 as of early 2026), minSdk — API 26 (Android 8.0, covers 95% of devices), targetSdk — latest stable. For updating an existing application: raise compileSdk immediately, targetSdk — after testing all behavioral changes, minSdk — only when it is necessary to drop support for outdated devices.

Google requires that targetSdk be updated within a year after the release of a new Android version. Applications that do not meet this requirement cannot publish updates on Google Play. To track deadlines, use the official Android OS updates calendar.

Working with SDK Platform in Code Examples

When developing for different Android versions, it is necessary to consider API availability. If the application uses compileSdk 35 but runs on a device with API 31, calling methods added in API 34 will result in NoSuchMethodError or AbstractMethodError. For safe calling of new APIs, version checks via Build.VERSION.SDK_INT are used.

Checking API Level at Runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Notification channels are available from API 26
            val channel = NotificationChannel(
                "updates",
                "Updates",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Using New APIs with @RequiresApi

For methods that are only called on specific versions, use the @RequiresApi annotation. This tells lint checks that the method is safe and disables warnings. Combined with SDK_INT check, the annotation makes the code cleaner and more understandable for reviewers.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact with SCHEDULE_EXACT_ALARM flag
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Request SCHEDULE_EXACT_ALARM permission
        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 {
        // Old setExact method without permission check
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Determining the Installed SDK Platform

Sometimes you need to know which SDK Platform version is installed on the developer's device or in CI. This can be done via ADB or programmatically in the application code. Knowing the device API Level helps when testing version-specific behavior.

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")
    }
    // Output: SDK_INT: 35, RELEASE: 15, CODENAME: REL
}