targetSdkVersion: Schlüsselkonzepte, Behavioural Changes und Google Play

Was ist targetSdkVersion in Android?

targetSdkVersion ist ein ganzzahliger Parameter in build.gradle, der den API Level deklariert, gegen den die App getestet wurde. Das Android-System verwendet diesen Parameter, um zu entscheiden, welche behavioural changes zur Laufzeit auf die App angewendet werden. Wenn targetSdkVersion = 33 ist, wendet Android alle bis einschließlich API 33 eingeführten behavioural changes an, aber nicht die Änderungen von API 34+. Wenn targetSdkVersion = 34 ist — werden Änderungen bis API 34 angewendet, und so weiter.

Der Hauptunterschied zwischen targetSdkVersion und minSdkVersion ist der Wirkmechanismus. minSdk wird einmalig bei der Installation geprüft und blockiert die Installation, wenn die Bedingung nicht erfüllt ist. targetSdkVersion beeinflusst das Laufzeitverhalten des Systems auf jedem Gerät, unabhängig davon, auf welcher Android-Version die App läuft. Dieselbe App mit targetSdk 31 verhält sich auf Android 13, 14 und 15 unterschiedlich, weil behavioural changes oberhalb von 31 deaktiviert sind.

Der targetSdkVersion-Mechanismus ist ein in Android eingebautes Abwärtskompatibilitätswerkzeug. Ohne ihn würde jedes OS-Update tausende alte Apps zerstören. Google führte diesen Mechanismus in Android 2.1 (API Level 7) ein und verwendet ihn seither als Standardmethode, um neue Sicherheits-, Datenschutz- und Ressourcenverwaltungsregeln einzuführen, ohne bestehende Anwendungen zu beschädigen.

// build.gradle.kts — targetSdkVersion in defaultConfig
android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Getestet unter Android 16
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Aktuellen targetSdk im Code überprüfen
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion enthält targetSdk der App
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Im Beispiel aktiviert targetSdk = 36 alle behavioural changes von Android 16. Der Code prüft targetSdkVersion über context.applicationInfo.targetSdkVersion — dies ermöglicht die dynamische Bestimmung, welcher Kompatibilitätsmodus aktiviert ist. Die Hilfsfunktion ist nützlich für Bibliotheken, die sich an den targetSdk der aufrufenden Anwendung anpassen müssen.

Behavioural Changes: Wie targetSdk die App beeinflusst

Behavioural changes sind Änderungen des Android-Systemverhaltens, die nur auf Apps mit targetSdkVersion >= einem bestimmten API Level angewendet werden. Jedes neue Haupt-Android-Release führt behavioural changes ein, und wenn eine App targetSdk nicht aktualisiert, treten diese Änderungen nicht in Kraft. Dieser Mechanismus ermöglicht es Entwicklern, ihre App in ihrem eigenen Tempo zu aktualisieren, anstatt synchron mit einem neuen OS-Release.

Scoped Storage (API 29) ist eine der bedeutendsten behavioural changes. Apps mit targetSdk 29+ können keinen direkten Dateizugriff auf die gemeinsamen Verzeichnisse Pictures, Downloads, Music, Documents erhalten. Stattdessen wird MediaStore für Medien, SAF (Storage Access Framework) für beliebige Dateien und getExternalFilesDir() für privaten Speicher verwendet. Alte Apps mit targetSdk 28 und niedriger arbeiten weiterhin mit dem Legacy Full Storage Access, was jedoch ein Sicherheitsrisiko darstellt.

POST_NOTIFICATIONS (API 33) ist eine Laufzeitberechtigung zum Senden von Benachrichtigungen. Apps mit targetSdk 33+ müssen die Berechtigung Manifest.permission.POST_NOTIFICATIONS vom Benutzer über den Standarddialog anfordern. Wird die Berechtigung nicht erteilt, zeigt NotificationManager.silent() dem Benutzer keine Benachrichtigungen an. Auf Android 13+ werden ohne diese Berechtigung Push-Benachrichtigungen und lokale Benachrichtigungen einfach nicht angezeigt, was das Nutzerengagement erheblich reduzieren kann.

So überprüfen Sie den aktuellen targetSdk

Der Wert von targetSdkVersion kann über ADB ermittelt werden: Der Befehl adb shell dumpsys package com.example.myapp | grep targetSdk gibt targetSdk=34 aus. Im Code gibt context.getApplicationInfo().targetSdkVersion eine ganze Zahl zurück. Für Analysen ist es nützlich, targetSdk zusammen mit android.os.Build.VERSION.SDK_INT zu protokollieren, um zu verstehen, welche behavioural changes in jeder Sitzung tatsächlich aktiv sind.

Google Play-Anforderungen für targetSdkVersion (2026)

Google Play legt verbindliche targetSdkVersion-Anforderungen für alle veröffentlichten Apps fest. Seit August 2024 beträgt der Mindest-targetSdk = 33 (Android 13). Seit August 2025 beträgt targetSdk = 34. Es wird erwartet, dass Google ab August 2026 targetSdk = 35 (Android 15) verlangt. Neue Apps und Updates bestehender Apps müssen diese Anforderungen erfüllen, andernfalls blockiert die Konsole die Veröffentlichung. Dies ist eine Google Play-Richtlinie, keine Android Runtime-Einschränkung: Eine App mit targetSdk 34 kann auf Android 16 laufen, aber nicht im Play Store veröffentlicht werden.

Android App Bundle (AAB) ist seit August 2021 das obligatorische Veröffentlichungsformat. APK wird in Google Play nicht mehr akzeptiert (außer für Apps größer als 150 MB und einige Legacy-Projekte). Das AAB-Format ermöglicht es Google, optimierte APKs für jeden API Level und jede Bildschirmdichte zu generieren, wodurch die Downloadgröße um 15-30% reduziert wird. Zur Überprüfung von targetSdk analysiert Google Play das AAB-Manifest und gibt bei Nichteinhaltung einen Fehler mit dem erforderlichen Mindestwert aus.

Die Google Play Console prüft targetSdkVersion nicht nur beim Hochladen eines neuen AAB, sondern auch beim Aktualisieren einer bestehenden App. Wenn Ihre App targetSdk 33 hat und Google die Mindestschwelle auf 34 erhöht — können Sie keine Updates veröffentlichen, bis Sie targetSdk erhöhen. Bei Apps, die lange nicht aktualisiert wurden, kann Google Play sie automatisch aus der Veröffentlichung nehmen (unpublish).

So aktualisieren Sie targetSdkVersion fehlerfrei

targetSdkVersion aktualisieren ist nicht nur das Ändern einer Zahl in build.gradle. Jede behavioural change kann bestehende Funktionalität zerstören, wenn der Code nicht vorbereitet ist. Es wird empfohlen, 3-6 Monate vor der Google Play-Frist mit der Vorbereitung zu beginnen, insbesondere wenn die App groß ist und viele System-APIs verwendet.

Schritt-für-Schritt-Prozess: Schritt 1 — Studieren Sie die behavioural changes für den neuen API Level in der Android Developers-Dokumentation (Seite "Behavioural Changes by API Level"). Schritt 2 — Erstellen Sie einen targetSdk-update-Branch und ändern Sie targetSdk auf den neuen Wert. Schritt 3 — Führen Sie die App auf einem Emulator oder Gerät mit dem neuen API Level aus und überprüfen Sie jede mit den Änderungen verbundene Funktion. Schritt 4 — Beheben Sie Fehler: Fügen Sie Berechtigungen hinzu, ändern Sie die Dateibehandlung, aktualisieren Sie das Manifest.

Schritt 5 — Testen Sie auf alten Geräten. Die Erhöhung von targetSdk beeinflusst keine Geräte mit API Level unterhalb des neuen targetSdk, aber behavioural changes gelten für alle Geräte mit API Level >= targetSdk. Wenn Sie targetSdk von 33 auf 34 erhöht haben, werden auf Geräten mit API 34+ die behavioural changes von API 34 aktiviert. Auf Geräten mit API 33 ändert sich nichts.

// Vorbereitung auf targetSdk 35: Privacy Sandbox
import android.os.Build
import android.os.Build.VERSION_CODES
import com.google.android.gms.ads.identifier.AdvertisingIdClient

class AdsManager {

    fun getAdvertisingId(context: android.content.Context): String? {
        // Privacy Sandbox schränkt Advertising ID ab API 35 ein
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — Identifikator nicht verfügbar, MeasurementManager verwenden
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Prüfung: welche behavioural changes aktiv sind
    fun getActiveChanges(context: android.content.Context): List<String> {
        val sdkInt = Build.VERSION.SDK_INT
        val targetSdk = context.applicationInfo.targetSdkVersion
        return buildList {
            if (sdkInt >= VERSION_CODES.Q && targetSdk >= VERSION_CODES.Q)
                add("ScopedStorage")
            if (sdkInt >= VERSION_CODES.TIRAMISU && targetSdk >= VERSION_CODES.TIRAMISU)
                add("PostNotifications")
            if (sdkInt >= VERSION_CODES.UPSIDE_DOWN_CAKE && targetSdk >= VERSION_CODES.UPSIDE_DOWN_CAKE)
                add("FgsTypes")
        }
    }
}

Die Klasse AdsManager zeigt die Vorbereitung auf Privacy Sandbox (API 35). Advertising ID wird ab API 35 mit targetSdk 35+ nicht mehr verfügbar. Die Funktion getActiveChanges zeigt das korrekte Muster zur Überprüfung von behavioural changes: Es müssen sowohl SDK_INT des Geräts als auch targetSdk der App geprüft werden. Nur wenn beide Bedingungen übereinstimmen, ist die Änderung tatsächlich aktiv.

Android 15 (API 35): Wichtige behavioural changes

Android 15 (API 35, Vanilla Ice Cream) führt mehrere kritische behavioural changes ein, die Entwickler bei der Aktualisierung von targetSdk auf 35 berücksichtigen müssen. Erstens — Privacy Sandbox for Android. Dies ist Googles Initiative zur Ersetzung von Advertising ID durch privatere APIs: Topics API (Benutzerinteressen), Protected Audience (Retargeting) und Attribution Reporting (Conversions). Ab API 35 ist Advertising ID kein stabiler Identifikator mehr und kann einen Nullwert zurückgeben.

Die zweite Änderung — Foreground Service Types (API 34, fortgesetzt in API 35). Ab API 34 muss jede App mit targetSdk 34+ den Vordergrunddiensttyp im Manifest angeben: dataSync, systemExempted, shortService, location, mediaPlayback und andere. Ohne dies löst das System eine ForegroundServiceTypeNotAllowedException aus. In API 35 wurde ein neuer Typ health hinzugefügt und die Validierung bestehender Typen verschärft. Alle Vordergrunddienste müssen überprüft werden.

Die dritte Änderung — Einschränkung von SCHEDULE_EXACT_ALARM. Ab API 35 können Apps mit targetSdk 35+ SCHEDULE_EXACT_ALARM nicht ohne explizite Benutzererlaubnis verwenden. Das System zeigt einen Dialog an, und der Benutzer muss die genaue Planung genehmigen. Für Alarme und Timer bedeutet dies einen zusätzlichen UX-Schritt. Eine Alternative ist die Verwendung von ungenauen Alarmen mit einem Puffer von 10 Minuten.

// Android 15 (API 35): SCHEDULE_EXACT_ALARM-Prüfung
import android.app.AlarmManager
import android.os.Build
import android.provider.Settings

class AlarmScheduler {

    fun canScheduleExactAlarms(context: android.content.Context): Boolean {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+: Benutzerberechtigung erforderlich
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Unter API 35 — genaue Alarme ohne Berechtigung verfügbar
        return true
    }

    fun requestExactAlarmPermission(activity: android.app.Activity) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            val intent = android.content.Intent(
                Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
            ).apply {
                data = android.net.Uri.fromParts(
                    "package", activity.packageName, null
                )
            }
            activity.startActivity(intent)
        }
    }
}

Privacy Sandbox und die Alarmbeschränkung sind die beiden kritischsten behavioural changes von API 35. Werbe-SDKs müssen auf Topics API und Attribution Reporting migrieren. Für Apps mit Alarmen und Erinnerungen — UX-Anpassung für den Berechtigungsdialog. Das Ignorieren dieser Änderungen führt zu Laufzeitabstürzen der App auf Android 15 oder zu defekter Werbemonetarisierung.

Unterschied zwischen targetSdk und compileSdk

Der Unterschied zwischen targetSdkVersion und compileSdkVersion ist eine der häufigsten Verwechslungsquellen unter Android-Entwicklern. compileSdkVersion ist die Version des SDK, gegen die der Code kompiliert wird. Sie bestimmt, welche APIs zur Kompilierungszeit verfügbar sind, beeinflusst aber nicht das Laufzeitverhalten. targetSdkVersion ist die Version, gegen die die App getestet wurde — sie bestimmt, welche behavioural changes zur Laufzeit angewendet werden. compileSdk kann und sollte höher oder gleich targetSdk sein.

Die Regel ist einfach: compileSdk >= targetSdk >= minSdk. compileSdk ist normalerweise gleich dem neuesten stabilen API Level (2026 — 36). targetSdk sollte so hoch wie möglich unter den getesteten Versionen sein. minSdk sollte für maximale Reichweite so niedrig wie möglich sein. Die Erhöhung von compileSdk erfordert keine Tests von behavioural changes — sie öffnet nur den Zugriff auf neue APIs für den Compiler. Die Erhöhung von targetSdk erfordert einen vollständigen Testzyklus aller behavioural changes.

In der Praxis: Wenn Sie eine neue API von Android 16 (API 36) verwenden möchten, aber die behavioural changes von API 36 noch nicht getestet haben, setzen Sie compileSdk = 36, targetSdk = 35. Der Code wird mit den neuen APIs kompiliert, aber die behavioural changes von API 36 werden nicht angewendet. Sobald Sie alle Änderungen getestet haben — erhöhen Sie targetSdk auf 36.