SDK Manager Basics: Plattformen und Tools sauber verwalten

Bevor du deine erste Compose-App startest, brauchst du eine saubere Werkzeugkiste. Der SDK Manager ist genau dafür da: Er verwaltet die Android-Plattformen, die Kommandozeilen-Tools und die Build-Tools, mit denen Android Studio, Gradle und dein Emulator arbeiten. Wenn du verstehst, was hier installiert ist und warum, sparst du dir später viele rätselhafte Fehlermeldungen und kannst dein Setup gezielt aktuell halten.

Was ist das?

Der SDK Manager ist das Verwaltungswerkzeug für das Android-SDK. Das SDK selbst ist eine Sammlung von Komponenten, die Android Studio und der Build-Prozess brauchen, um Apps zu kompilieren, zu installieren und auf einem Gerät oder Emulator zu starten. Ohne SDK kein adb, kein Compose-Preview, keine APK.

Du findest den SDK Manager an zwei Orten. In Android Studio öffnest du ihn über Settings → Languages & Frameworks → Android SDK oder über das Toolbar-Symbol mit den drei Pfeilen. Auf der Kommandozeile heißt das Werkzeug sdkmanager und liegt im Ordner cmdline-tools/latest/bin/ deines SDK-Verzeichnisses. Beide Varianten greifen auf dasselbe SDK zu, das standardmäßig unter ~/Library/Android/sdk (macOS), ~/Android/Sdk (Linux) oder %LOCALAPPDATA%\Android\Sdk (Windows) liegt.

Im Android-Roadmap-Kontext ist der SDK Manager das Werkzeug, das die Brücke zwischen deinem Quellcode und einem lauffähigen Build schlägt. Während du dich später auf Kotlin, Jetpack und Compose konzentrierst, sorgt der SDK Manager im Hintergrund dafür, dass die richtige Plattform-Version, die passenden Build-Tools und die nötigen Hilfsprogramme verfügbar sind. Das macht ihn zu einem stillen, aber wichtigen Begleiter deiner ganzen Android-Reise.

Wie funktioniert es?

Der SDK Manager arbeitet paketbasiert. Jede Komponente, die du installieren kannst, ist ein eigenes Paket mit einem klaren Namen, zum Beispiel platforms;android-34 oder build-tools;34.0.0. Du wählst Pakete aus einer Liste aus, der Manager lädt sie von Googles SDK-Repository herunter und entpackt sie in dein lokales SDK-Verzeichnis.

Drei Paket-Familien solltest du namentlich kennen, weil sie ständig in Build-Logs und Doku auftauchen.

Platforms

Eine Platform entspricht einer Android-Version, also einem API-Level wie 34 (Android 14) oder 35 (Android 15). Sie enthält die android.jar, gegen die dein Code kompiliert wird. Diese Version steuerst du in Gradle über compileSdk und targetSdk. Hast du compileSdk = 34 in deiner build.gradle.kts, muss platforms;android-34 lokal installiert sein, sonst bricht der Build ab.

Platform-Tools

Die Platform-Tools sind versionsunabhängige Hilfsprogramme. Hier wohnen adb (Android Debug Bridge), fastboot und ein paar weitere CLI-Werkzeuge. adb brauchst du, sobald du Apps auf einem echten Gerät installierst, Logs liest oder Dateien hin- und herschiebst. Diese Tools werden gemeinsam aktualisiert und sollten immer auf dem neuesten Stand sein, weil neue Geräte und Android-Versionen oft neue adb-Funktionen voraussetzen.

Build-Tools

Die Build-Tools enthalten Programme wie aapt2, d8 und zipalign, die Gradle während des Builds aufruft, um Ressourcen zu kompilieren, Bytecode in DEX umzuwandeln und APKs zu signieren. Gradle wählt eine konkrete Version anhand der buildToolsVersion-Einstellung oder nimmt automatisch die passende. Eine veraltete Build-Tools-Version kann dazu führen, dass neue Sprach- oder Compose-Features nicht korrekt verarbeitet werden.

Daneben gibt es weitere optionale Pakete: System-Images für den Emulator (system-images;android-34;google_apis;arm64-v8a), die NDK für nativen Code, Sources zum Hineinschauen in die Plattform und das Google-Play-Services-SDK. Du installierst sie nur, wenn du sie wirklich brauchst, sonst wächst dein SDK-Ordner schnell auf zweistellige Gigabyte-Beträge.

Lizenzen sind ein eigener Schritt. Bevor ein Paket installiert wird, musst du die jeweilige Lizenz akzeptieren. In der GUI passiert das per Klick. Auf der Kommandozeile rufst du einmal sdkmanager --licenses auf, bestätigst alle Einträge und kannst danach unbeobachtet installieren, was wichtig für CI-Server ist.

In der Praxis

Im Alltag wirst du den SDK Manager seltener öffnen, als du denkst. Android Studio fragt dich beim ersten Start, beim Anlegen eines Projekts mit neuer compileSdk oder beim Öffnen eines fremden Projekts oft selbst, ob es fehlende Pakete nachladen darf. Trotzdem lohnt es sich, den Ablauf einmal selbst durchzuspielen.

Variante GUI

In Android Studio öffnest du Settings → Languages & Frameworks → Android SDK. Im Tab SDK Platforms siehst du alle API-Level, im Tab SDK Tools die Werkzeuge. Aktiviere unten Show Package Details, dann erkennst du nicht nur „Android 14 (UpsideDownCake)”, sondern auch die einzelnen System-Images und Quelldateien dahinter. Hake an, was du brauchst, klicke auf Apply und bestätige die Lizenzen.

Variante Kommandozeile

Auf einem CI-Server oder in einem Docker-Image willst du den SDK Manager skripten. Das geht so:

# Installierte Pakete anzeigen
sdkmanager --list_installed

# Plattform 34, aktuelle Platform-Tools und passende Build-Tools installieren
sdkmanager \
  "platforms;android-34" \
  "platform-tools" \
  "build-tools;34.0.0"

# Lizenzen einmalig akzeptieren (wichtig für CI)
yes | sdkmanager --licenses

# Alles aktualisieren
sdkmanager --update

Die Pfade hängen von deinem Setup ab. Setze die Umgebungsvariable ANDROID_HOME (oder ANDROID_SDK_ROOT) auf den SDK-Ordner und ergänze $ANDROID_HOME/platform-tools und $ANDROID_HOME/cmdline-tools/latest/bin in deiner PATH. Danach kannst du adb devices und sdkmanager --list direkt im Terminal ausführen.

Eine konkrete Entscheidungsregel

Halte mindestens drei Dinge synchron: die in build.gradle.kts gesetzte compileSdk-Version, das gleichnamige platforms;android-XX-Paket und eine aktuelle Version der Platform-Tools. Sobald du compileSdk hochziehst, lädst du dasselbe API-Level im SDK Manager nach. Das verhindert Build-Fehler nach einem Upgrade von Android Studio oder einem Wechsel zwischen Geräten.

Typische Stolperfallen

Drei Probleme begegnen dir in der Praxis besonders oft.

Erstens: Akzeptierte Lizenzen fehlen. Auf einem frischen CI-Image scheitert der Build mit der Meldung „You have not accepted the license agreements”. Lösung: einmal yes | sdkmanager --licenses ausführen oder die Datei licenses/ aus einem lokal akzeptierten SDK ins CI kopieren.

Zweitens: Falscher SDK-Pfad. Wenn ANDROID_HOME leer ist oder auf ein altes Verzeichnis zeigt, sucht Android Studio die Pakete am falschen Ort und schlägt vor, sie erneut herunterzuladen. Prüfe in der IDE unter Settings → Android SDK, welcher Ordner als Android SDK Location eingetragen ist, und richte deine Umgebungsvariablen darauf aus.

Drittens: Veraltete Build-Tools. Alte Build-Tools-Versionen kennen neue Kotlin- oder Compose-Features nicht und produzieren kryptische DEX- oder Compiler-Fehler. Wenn du nach einem Plugin-Update merkwürdige Probleme bekommst, ist ein Update der Build-Tools oft die richtige erste Maßnahme.

Fazit

Der SDK Manager ist kein spannendes Thema, aber er entscheidet darüber, ob deine Android-Werkzeuge zueinander passen. Wenn du verstehst, was Plattformen, Platform-Tools und Build-Tools jeweils tun, kannst du gezielt das installieren, was dein Projekt braucht, und unnötigen Ballast vermeiden. Öffne den SDK Manager in Android Studio einmal bewusst, schau dir an, welche Pakete bei dir installiert sind, und vergleiche sie mit deinem compileSdk in der build.gradle.kts. Probiere danach im Terminal sdkmanager --list_installed aus und prüfe, ob adb devices dein Gerät erkennt. Wer sein SDK kennt, debuggt später nicht stundenlang gegen Probleme an, die der SDK Manager in zwei Minuten gelöst hätte.