SDK Platform: co to jest, wersje i Android SDK Manager

Co to jest SDK Platform

SDK Platform — to fundamentalny komponent Android SDK, stanowiący kompletny zestaw bibliotek i narzędzi do tworzenia aplikacji dla konkretnej wersji Android. Każda platforma jest identyfikowana przez API Level — liczbę całkowitą, która rośnie wraz z wydawaniem nowych wersji systemu. Na przykład Android 13 odpowiada API Level 33, Android 14 — API Level 34, Android 15 — API Level 35.

W przeciwieństwie do Android Studio (IDE), SDK Platform nie zawiera edytora kodu ani debuggera. Jest to warstwa systemowa, która łączy się z kompilatorem i narzędziem budowania. Gdy programista pisze import android.app.Activity, kompilator pobiera tę klasę z android.jar konkretnej SDK Platform. Bez zainstalowanej platformy z wymaganym API Level kod się nie skompiluje.

Google wydaje nową SDK Platform dla każdej stabilnej wersji Android. Historia obejmuje ponad 35 API Level — od Android 1.0 (API 1) do Android 15 (API 35). Każda platforma jest wstecznie zgodna: kod napisany dla API Level 21 będzie działać na API Level 35, ale nie odwrotnie.

Po co osobna SDK Platform dla każdej wersji

Android rozwija się szybko: każda wersja dodaje nowe API, zmienia działanie istniejących i wprowadza ograniczenia. Na przykład Android 10 (API 29) wprowadził Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — obowiązkowe flagi BroadcastReceiver. Programista musi zbudować aplikację dla aktualnej platformy, aby korzystać z tych możliwości.

Jednocześnie aplikacja może działać na starszych wersjach systemu. W tym celu w Gradle określa się minSdk — minimalny API Level, na którym aplikacja jest uruchamiana. Kod wykorzystuje sprawdzanie wersji i warunkowe wywołania API. Takie podejście zapewnia zgodność bez utraty nowych funkcji.

Skład SDK Platform: główne komponenty

SDK Platform — to nie jeden plik, ale zestaw komponentów, które razem zapewniają kompilację, budowanie i testowanie aplikacji. Głównym elementem jest android.jar — archiwum z klasami Android API zawartymi w danej wersji. Ten plik jest podłączany do kompilatora Kotlin lub Java i określa, jakie klasy, metody i adnotacje są dostępne dla programisty.

Obrazy systemowe i emulator

Każda SDK Platform zawiera System Image — obraz systemu operacyjnego dla emulatora Android Virtual Device. Bez odpowiedniego obrazu emulator nie będzie mógł uruchomić wirtualnego urządzenia z wymaganym API Level. System Images występują w różnych typach: Google APIs (z usługami Google), Google Play (z Play Store) i AOSP (czysty Android bez usług Google).

Narzędzia budowania i debugowania

SDK Platform zawiera wersję Build-Tools i Platform-Tools zoptymalizowane dla danego API Level. Build-Tools zawierają aapt2 (Android Asset Packaging Tool), dx/d8 (kompilator Dalvik/ART) i ApkSigner. Platform-Tools dostarczają ADB (Android Debug Bridge), fastboot i SQLite. Te narzędzia aktualizują się niezależnie od SDK Platform przez SDK Manager.

Zasoby platformy

Każda platforma zawiera standardowe zasoby Android — motywy systemowe, style, animacje, kolory i rozmiary. Te zasoby są używane podczas kompilacji: jeśli programista odwołuje się do @android:style/Theme.Material.Light, narzędzie budowania pobiera definicję z zasobów SDK Platform. Gwarantuje to jednolity wygląd komponentów systemowych na wszystkich urządzeniach.

API Level i wersje SDK Platform

API Level — to całkowitoliczbowy identyfikator wersji Android SDK. Każdemu wydaniu Android odpowiada jeden API Level, który monotonicznie wzrasta. Programista określa API Level w trzech kluczowych parametrach build.gradle: compileSdk, minSdk i targetSdk. Od wyboru tych parametrów zależy, które API są dostępne i jak system obsługuje aplikację.

Google zaleca utrzymywanie minSdk na poziomie nie niższym niż obecny próg dystrybucji — według Android Studio Distribution Dashboard (2026), około 95% urządzeń działa na Android 8.0 (API 26) i wyższym. compileSdk powinien być ostatnim stabilnym — daje to dostęp do nowych API i pozwala lint-sprawdzaniu wykrywać przestarzałe metody.

Ewolucja API Level: kluczowe zmiany

Z każdym nowym API Level Google wprowadza istotne zmiany. Android 6.0 (API 23) dodał uprawnienia runtime — aplikacja prosi o uprawnienia podczas działania, a nie przy instalacji. Android 8.0 (API 26) wprowadził autouzupełnianie formularzy i kanały powiadomień. Android 12 (API 31) radykalnie zmienił podejście do intentów — pojawił się SplashScreen API i eksport komponentów przez atrybut exported. Android 14 (API 34) nakazał określanie flag dla BroadcastReceiver i wprowadził ścisłe ograniczenia dla foreground services.

Zrozumienie historii API Level pomaga programiście wybrać właściwą strategię zgodności. Jeśli aplikacja używa compileSdk 35, ale minSdk 26, kod może wywoływać metody API 35 tylko po sprawdzeniu wersji przez Build.VERSION.SDK_INT. Takie podejście nazywa się version-gated development i jest standardem branżowym.

SDK Manager: instalacja i konfiguracja

SDK Manager — to narzędzie do zarządzania komponentami Android SDK: instalacji nowych SDK Platform, aktualizacji istniejących i usuwania przestarzałych. SDK Manager jest dostępny jako interfejs graficzny w Android Studio, a także wiersz poleceń przez sdkmanager. Za pomocą wiersza poleceń SDK Manager jest wygodny w użyciu w pipeline'ach CI/CD, gdzie nie ma interfejsu graficznego.

SDK Manager instaluje platformy w katalogu Android SDK, który domyślnie znajduje się w $HOME/Android/Sdk na Linux i macOS lub %LOCALAPPDATA%\Android\Sdk na Windows. Wewnątrz katalogu platforms znajdują się foldery o nazwie android-{API Level}, z których każdy zawiera pełną SDK Platform.

Instalacja SDK Platform przez sdkmanager

Polecenie sdkmanager przyjmuje identyfikator pakietu w formacie "platforms;android-{API}". Na przykład do instalacji SDK Platform 35 polecenie wygląda następująco:

# Zainstaluj SDK Platform dla API Level 35
sdkmanager "platforms;android-35"

# Zainstaluj wiele platform jednym poleceniem
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Lista zainstalowanych platform
sdkmanager --list_installed | grep platforms

# Usuń przestarzałą platformę
sdkmanager --uninstall "platforms;android-28"

Automatyczna instalacja przez Gradle

Nowoczesne projekty Android używają Gradle Plugin, który może automatycznie instalować SDK Platform przy pierwszym budowaniu. W tym celu należy określić compileSdk w build.gradle i dodać katalog SDK w lokalnej konfiguracji. Android Studio również oferuje instalację brakującej platformy przy otwarciu projektu — wystarczy kliknąć przycisk "Install SDK Platform" w oknie synchronizacji Gradle.

Ważne jest regularne aktualizowanie SDK Platform przez SDK Manager — wraz z platformą aktualizują się Build-Tools i Platform-Tools, co wpływa na wydajność budowania i stabilność debugowania. Google zaleca sprawdzanie aktualizacji SDK co 2–3 tygodnie, szczególnie przed publikacją nowej wersji aplikacji w Google Play.

Konfiguracja obrazu systemowego dla emulatora

Do uruchomienia emulatora z konkretnym API Level należy zainstalować System Image tej samej wersji. SDK Manager umożliwia pobieranie obrazów różnych architektur (x86_64, arm64-v8a) i typów (Google APIs, Google Play, AOSP). Po pobraniu obrazu AVD Manager tworzy wirtualne urządzenie na jego podstawie.

# Zainstaluj System Image z Google APIs dla API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Utwórz AVD przez wiersz poleceń
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Lista utworzonych AVD
avdmanager list avd

compileSdk, targetSdk i minSdk w Gradle

Trzy parametry w build.gradle określają działanie aplikacji z SDK Platform. compileSdk — API Level używany do kompilacji. Ten parametr określa, które klasy Android API są dostępne w kodzie. compileSdk powinien być najnowszym spośród wszystkich trzech i nie wpływa na działanie runtime — aplikacja kompiluje się, ale używa tylko tych API, które są na urządzeniu.

minSdk — minimalny API Level, na którym aplikacja może być zainstalowana. Google Play nie pozwoli zainstalować aplikacji na urządzeniu z wersją niższą niż minSdk. Ten parametr określa próg zgodności i wpływa na zasięg odbiorców. Im niższy minSdk, tym więcej urządzeń jest obsługiwanych, ale tym mniej nowych API można używać bez sprawdzania.

targetSdk — API Level, pod który aplikacja była testowana. System Android używa targetSdk do stosowania zmian behawioralnych: jeśli aplikacja nie została zaktualizowana do nowego API Level, system włącza tryb zgodności dla starszych wersji. Google Play wymaga targetSdk nie niższego niż określony poziom — na 2026 rok jest to API 34 (Android 14).

Przykład konfiguracji 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
    }
}

// Wersja Android SDK musi być zainstalowana przez SDK Manager
// sdkmanager "platforms;android-35"

Jak wybierać compileSdk, minSdk i targetSdk

Strategia wyboru zależy od celów projektu. Dla nowej aplikacji: compileSdk — ostatni stabilny (35 na początek 2026), minSdk — API 26 (Android 8.0, pokrywa 95% urządzeń), targetSdk — ostatni stabilny. Dla aktualizacji istniejącej aplikacji: podnieś compileSdk od razu, targetSdk — po przetestowaniu wszystkich zmian behawioralnych, minSdk — tylko w razie konieczności rezygnacji z przestarzałych urządzeń.

Google wymaga, aby targetSdk był aktualizowany w ciągu roku od wydania nowej wersji Android. Aplikacje niespełniające tego wymogu nie mogą publikować aktualizacji w Google Play. Do śledzenia terminów używaj oficjalnego kalendarza Android OS updates.

Przykłady pracy z SDK Platform w kodzie

Podczas tworzenia aplikacji dla różnych wersji Android należy uwzględniać dostępność API. Jeśli aplikacja używa compileSdk 35, ale działa na urządzeniu z API 31, wywołanie metod dodanych w API 34 spowoduje NoSuchMethodError lub AbstractMethodError. Do bezpiecznego wywoływania nowych API stosuje się sprawdzanie wersji przez Build.VERSION.SDK_INT.

Sprawdzanie API Level w runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Notification channels są dostępne od API 26
            val channel = NotificationChannel(
                "updates",
                "Aktualizacje",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Używanie nowych API z @RequiresApi

Dla metod wywoływanych tylko na określonych wersjach używaj adnotacji @RequiresApi. Informuje to lint-sprawdzanie, że metoda jest bezpieczna, i wyłącza ostrzeżenia. W połączeniu ze sprawdzaniem SDK_INT adnotacja czyni kod czystszym i bardziej zrozumiałym dla recenzentów.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact z flagą SCHEDULE_EXACT_ALARM
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Prosimy o uprawnienie 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 {
        // Stara metoda setExact bez sprawdzania uprawnień
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Określanie zainstalowanej SDK Platform

Czasami trzeba dowiedzieć się, jaka wersja SDK Platform jest zainstalowana na urządzeniu programisty lub w CI. Można to zrobić przez ADB lub programowo w kodzie aplikacji. Znajomość API Level urządzenia pomaga przy testowaniu zachowań zależnych od wersji.

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