SDK Platform: Was es ist, Versionen und Android SDK Manager

Was ist SDK Platform

SDK Platform ist eine grundlegende Komponente des Android SDK, die eine vollständige Sammlung von Bibliotheken und Werkzeugen zum Entwickeln von Anwendungen für eine bestimmte Android-Version darstellt. Jede Plattform wird durch ihren API Level identifiziert — eine Ganzzahl, die mit neuen OS-Versionen steigt. Zum Beispiel entspricht Android 13 API Level 33, Android 14 API Level 34, Android 15 API Level 35.

Im Gegensatz zu Android Studio (IDE) enthält SDK Platform keinen Code-Editor oder Debugger. Es ist eine Systemebene, die sich mit dem Compiler und Build-System verbindet. Wenn ein Entwickler import android.app.Activity schreibt, holt der Compiler diese Klasse aus der android.jar einer bestimmten SDK Platform. Ohne eine installierte Plattform mit dem erforderlichen API Level wird der Code nicht kompiliert.

Google veröffentlicht eine neue SDK Platform für jede stabile Android-Version. Die Geschichte umfasst mehr als 35 API Levels — von Android 1.0 (API 1) bis Android 15 (API 35). Jede Plattform ist abwärtskompatibel: Code, der für API Level 21 geschrieben wurde, funktioniert auf API Level 35, aber nicht umgekehrt.

Warum eine separate SDK Platform für jede Version benötigt wird

Android entwickelt sich schnell weiter: Jede Version fügt neue APIs hinzu, ändert das Verhalten bestehender und führt Einschränkungen ein. Zum Beispiel führte Android 10 (API 29) Scoped Storage ein, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — verbindliche BroadcastReceiver-Flags. Ein Entwickler muss die Anwendung gegen die aktuelle Plattform kompilieren, um diese Funktionen nutzen zu können.

Gleichzeitig kann die Anwendung auf älteren OS-Versionen ausgeführt werden. Dafür wird in Gradle minSdk angegeben — der minimale API Level, auf dem die Anwendung läuft. Der Code verwendet Versionsprüfungen und bedingte API-Aufrufe. Dieser Ansatz gewährleistet Kompatibilität ohne Verlust neuer Funktionen.

Zusammensetzung der SDK Platform: Hauptkomponenten

Die SDK Platform ist keine einzelne Datei, sondern eine Sammlung von Komponenten, die gemeinsam die Kompilierung, Erstellung und das Testen der Anwendung sicherstellen. Das Hauptelement ist android.jar — ein Archiv mit den Android-API-Klassen dieser Version. Diese Datei verbindet sich mit dem Kotlin- oder Java-Compiler und bestimmt, welche Klassen, Methoden und Annotationen dem Entwickler zur Verfügung stehen.

Systemabbilder und Emulator

Jede SDK Platform enthält ein Systemabbild (System Image) — ein Betriebssystemabbild für den Android Virtual Device Emulator. Ohne das entsprechende Abbild kann der Emulator kein virtuelles Gerät mit dem erforderlichen API Level starten. Systemabbilder gibt es in verschiedenen Typen: Google APIs (mit Google-Diensten), Google Play (mit Play Store) und AOSP (reines Android ohne Google-Dienste).

Build- und Debug-Tools

Die SDK Platform enthält eine für diesen API Level optimierte Version von Build-Tools und Platform-Tools. Build-Tools enthält aapt2 (Android Asset Packaging Tool), dx/d8 (Dalvik/ART Compiler) und ApkSigner. Platform-Tools bietet ADB (Android Debug Bridge), fastboot und SQLite. Diese Tools werden unabhängig von der SDK Platform über den SDK Manager aktualisiert.

Plattformressourcen

Jede Plattform enthält Standard-Android-Ressourcen — Systemdesigns, Stile, Animationen, Farben und Abmessungen. Diese Ressourcen werden während der Kompilierung verwendet: Wenn ein Entwickler auf @android:style/Theme.Material.Light verweist, holt das Build-System die Definition aus den SDK Platform Ressourcen. Dies gewährleistet ein einheitliches Erscheinungsbild der Systemkomponenten auf allen Geräten.

API Level und SDK Platform Versionen

API Level ist eine ganzzahlige Kennung der Android SDK Version. Jede Android-Version entspricht einem API Level, der monoton steigt. Der Entwickler gibt den API Level in drei Schlüsselparametern von build.gradle an: compileSdk, minSdk und targetSdk. Die Wahl dieser Parameter bestimmt, welche APIs verfügbar sind und wie das System die Anwendung behandelt.

Google empfiehlt, minSdk nicht unter der aktuellen Verteilungsschwelle zu halten — laut Android Studio Distribution Dashboard (2026) laufen etwa 95 % der Geräte mit Android 8.0 (API 26) und höher. compileSdk sollte die neueste stabile Version sein — dies ermöglicht Zugriff auf neue APIs und erlaubt lint-Prüfungen, veraltete Methoden zu erkennen.

Entwicklung des API Level: Wichtige Änderungen

Mit jedem neuen API Level führt Google bedeutende Änderungen ein. Android 6.0 (API 23) führte Laufzeitberechtigungen ein — die Anwendung fordert Berechtigungen während der Ausführung an, nicht bei der Installation. Android 8.0 (API 26) führte AutoVervollständigen von Formularen und Benachrichtigungskanäle ein. Android 12 (API 31) änderte den Ansatz für Intents grundlegend — SplashScreen API und der Export von Komponenten über das exported-Attribut kamen hinzu. Android 14 (API 34) machte die Angabe von Flags für BroadcastReceiver verpflichtend und führte strenge Einschränkungen für Vordergrunddienste ein.

Das Verständnis der Geschichte der API Levels hilft dem Entwickler, die richtige Kompatibilitätsstrategie zu wählen. Wenn die Anwendung compileSdk 35 verwendet, aber minSdk 26, kann der Code API 35-Methoden nur nach einer Versionsprüfung über Build.VERSION.SDK_INT aufrufen. Dieser Ansatz wird als version-gated Development bezeichnet und ist ein Industriestandard.

SDK Manager: Installation und Einrichtung

SDK Manager ist ein Werkzeug zur Verwaltung von Android SDK Komponenten: Installieren neuer SDK Platform, Aktualisieren vorhandener und Entfernen veralteter. Der SDK Manager ist sowohl als grafische Oberfläche in Android Studio als auch als Kommandozeilenwerkzeug über sdkmanager verfügbar. Die Kommandozeile des SDK Managers ist praktisch für CI/CD-Pipelines, in denen keine grafische Oberfläche vorhanden ist.

Der SDK Manager installiert Plattformen in das Android SDK Verzeichnis, das sich standardmäßig unter $HOME/Android/Sdk auf Linux und macOS oder %LOCALAPPDATA%\Android\Sdk auf Windows befindet. Im platforms-Verzeichnis befinden sich Ordner mit Namen wie android-{API Level}, die jeweils die vollständige SDK Platform enthalten.

Installieren der SDK Platform über sdkmanager

Der sdkmanager-Befehl akzeptiert eine Paketkennung im Format "platforms;android-{API}". Zum Beispiel lautet der Befehl zum Installieren von SDK Platform 35:

# SDK Platform für API Level 35 installieren
sdkmanager "platforms;android-35"

# Mehrere Plattformen mit einem Befehl installieren
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Installierte Plattformen auflisten
sdkmanager --list_installed | grep platforms

# Veraltete Plattform entfernen
sdkmanager --uninstall "platforms;android-28"

Automatische Installation über Gradle

Moderne Android-Projekte verwenden das Gradle Plugin, das beim ersten Build automatisch die SDK Platform installieren kann. Dazu muss compileSdk in build.gradle angegeben und das SDK Verzeichnis in der lokalen Konfiguration hinzugefügt werden. Android Studio bietet auch an, die fehlende Plattform beim Öffnen eines Projekts zu installieren — klicken Sie einfach auf die Schaltfläche "Install SDK Platform" im Gradle-Synchronisationsfenster.

Es ist wichtig, die SDK Platform regelmäßig über den SDK Manager zu aktualisieren — zusammen mit der Plattform werden Build-Tools und Platform-Tools aktualisiert, was die Build-Leistung und Debug-Stabilität beeinflusst. Google empfiehlt, SDK-Updates alle 2–3 Wochen zu überprüfen, insbesondere vor der Veröffentlichung einer neuen App-Version im Google Play Store.

Einrichten eines Systemabbilds für den Emulator

Um den Emulator mit einem bestimmten API Level auszuführen, muss ein Systemabbild (System Image) derselben Version installiert werden. Der SDK Manager ermöglicht das Herunterladen von Abbildern verschiedener Architekturen (x86_64, arm64-v8a) und Typen (Google APIs, Google Play, AOSP). Nach dem Herunterladen des Abbilds erstellt der AVD Manager ein virtuelles Gerät auf dessen Basis.

# System Image mit Google APIs für API 35 installieren
sdkmanager "system-images;android-35;google_apis;x86_64"

# AVD über die Befehlszeile erstellen
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Erstellte AVDs auflisten
avdmanager list avd

compileSdk, targetSdk und minSdk in Gradle

Drei Parameter in build.gradle definieren, wie die Anwendung mit der SDK Platform arbeitet. compileSdk ist der API Level, der für die Kompilierung verwendet wird. Dieser Parameter gibt an, welche Android-API-Klassen im Code verfügbar sind. compileSdk sollte der neueste der drei sein und beeinflusst nicht das Laufzeitverhalten — die Anwendung wird kompiliert, verwendet aber nur die auf dem Gerät verfügbaren APIs.

minSdk ist der minimale API Level, auf dem die Anwendung installiert werden kann. Google Play erlaubt nicht die Installation der Anwendung auf einem Gerät mit einer Version unterhalb von minSdk. Dieser Parameter definiert die Kompatibilitätsschwelle und beeinflusst die Zielgruppenabdeckung. Je niedriger minSdk, desto mehr Geräte werden unterstützt, aber desto weniger neue APIs können ohne Prüfungen verwendet werden.

targetSdk ist der API Level, gegen den die Anwendung getestet wurde. Das Android-System verwendet targetSdk, um Verhaltensänderungen anzuwenden: Wenn die Anwendung nicht auf einen neuen API Level aktualisiert wurde, aktiviert das System den Kompatibilitätsmodus für ältere Versionen. Google Play verlangt, dass targetSdk nicht unter einem bestimmten Level liegt — Stand 2026 ist dies API 34 (Android 14).

Beispiel einer Gradle-Konfiguration

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 muss über den SDK Manager installiert werden
// sdkmanager "platforms;android-35"

Wie man compileSdk, minSdk und targetSdk wählt

Die Auswahlstrategie hängt von den Projektzielen ab. Für eine neue Anwendung: compileSdk — neueste stabile (35 Anfang 2026), minSdk — API 26 (Android 8.0, deckt 95% der Geräte ab), targetSdk — neueste stabile. Für die Aktualisierung einer bestehenden Anwendung: compileSdk sofort erhöhen, targetSdk — nach dem Testen aller Verhaltensänderungen, minSdk — nur wenn die Unterstützung für alte Geräte aufgegeben werden muss.

Google verlangt, dass targetSdk innerhalb eines Jahres nach Veröffentlichung einer neuen Android-Version aktualisiert wird. Anwendungen, die diese Anforderung nicht erfüllen, können keine Updates im Google Play Store veröffentlichen. Verwenden Sie den offiziellen Android OS Update-Kalender, um Fristen zu verfolgen.

Beispiele für die Arbeit mit SDK Platform im Code

Bei der Entwicklung für verschiedene Android-Versionen muss die API-Verfügbarkeit berücksichtigt werden. Wenn die Anwendung compileSdk 35 verwendet, aber auf einem Gerät mit API 31 läuft, führen Aufrufe von Methoden, die in API 34 hinzugefügt wurden, zu NoSuchMethodError oder AbstractMethodError. Für sichere Aufrufe neuer APIs werden Versionsprüfungen über Build.VERSION.SDK_INT verwendet.

API Level zur Laufzeit prüfen

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Benachrichtigungskanäle sind ab API 26 verfügbar
            val channel = NotificationChannel(
                "updates",
                "Updates",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Verwendung neuer APIs mit @RequiresApi

Für Methoden, die nur auf bestimmten Versionen aufgerufen werden, verwenden Sie die @RequiresApi-Annotation. Dies teilt lint-Prüfungen mit, dass die Methode sicher ist, und deaktiviert Warnungen. In Kombination mit der SDK_INT-Prüfung macht die Annotation den Code sauberer und für Prüfer verständlicher.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact mit SCHEDULE_EXACT_ALARM-Flag
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // SCHEDULE_EXACT_ALARM-Berechtigung anfordern
        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 {
        // Alte setExact-Methode ohne Berechtigungsprüfung
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Ermitteln der installierten SDK Platform

Manchmal muss man wissen, welche SDK Platform Version auf dem Entwicklergerät oder im CI installiert ist. Dies kann über ADB oder programmatisch im Anwendungscode erfolgen. Die Kenntnis des API Levels des Geräts hilft beim Testen versionsspezifischen Verhaltens.

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