minSdkVersion: Was es ist und wie man die minimale Android-Version wählt

Was ist minSdkVersion in Android?

minSdkVersion ist ein ganzzahliger Parameter in build.gradle, der die minimale Android-API-Ebene für die App-Installation festlegt. Liegt die API-Ebene des Geräts unter dem angegebenen Wert, blockiert der PackageManager die Installation und der Google Play Store blendet die App in den Suchergebnissen für dieses Gerät aus. minSdkVersion wird zur Buildzeit über das Tag <uses-sdk android:minSdkVersion> in AndroidManifest.xml geschrieben und bei jeder Installation überprüft.

Der minSdkVersion-Wert ist ein Kompromiss zwischen Zielgruppenreichweite und Zugang zu neuen APIs. Je niedriger minSdk, desto mehr Geräte können die App installieren, insbesondere in Entwicklungsländern, wo ältere Android-Smartphones beliebt sind. Je höher minSdk, desto weniger Abwärtskompatibilitätscode ist erforderlich und desto mehr moderne APIs sind ohne Laufzeitprüfungen verfügbar. Android Jetpack und AndroidX-Bibliotheken bieten Backports vieler neuer APIs für ältere Android-Versionen, sodass Sie ein niedrigeres minSdk wählen können, ohne Funktionalität zu verlieren.

minSdkVersion beeinflusst alle Entwicklungsphasen: statische Analyse (lint verwendet minSdk für Warnungen), Abhängigkeitskompatibilität (Bibliotheken können ihr eigenes minSdk erfordern), Tests (Tests auf Geräten mit minSdk sind erforderlich) und Google Play Console (die Zielgruppenreichweite wird basierend auf minSdk berechnet). Die Änderung von minSdkVersion ist eine der wichtigsten Entscheidungen bei der Projekteinrichtung, da sie Code, Tests und Benutzerbasis betrifft.

Wo minSdkVersion angegeben wird

Build.gradle.kts (Kotlin DSL) ist der moderne Standard in Android-Projekten. Der minSdk-Parameter wird im defaultConfig-Block auf Modulebene festgelegt. Der Wert kann für verschiedene Build-Typen und Produktvarianten überschrieben werden, was Tests auf niedrigeren APIs ermöglicht, ohne den Hauptwert zu ändern.

// build.gradle.kts — grundlegende minSdk-Konfiguration
android {
    namespace = "com.example.myapp"
    compileSdk = 36

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

    // Überschreiben von minSdk für verschiedene Varianten
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

Im Beispiel entspricht minSdk = 26 Android 8.0 Oreo. Dies ist ein beliebter Wert im Jahr 2026: Laut Android Studio Distribution Dashboard schließt er nur ~15% der Geräte aus. compileSdk = 36 bietet Zugriff auf alle Android 16 APIs, und targetSdk = 36 enthält die Verhaltensänderungen der neuesten Version. Für Debug-Builds kann minSdk für Tests auf älteren Emulatoren gesenkt werden.

Wie wählt man minSdkVersion: Faktoren und Strategie

Die Wahl von minSdkVersion ist eine strategische Entscheidung, die auf der Analyse der Zielgruppe, API-Anforderungen und des Bibliotheks-Ökosystems basiert. Es gibt keinen einzigen richtigen Wert für alle Projekte. Im Jahr 2026 empfiehlt Android Studio minSdk = 26 (Android 8.0) als Baseline für neue Projekte, aber für B2B-Anwendungen oder Unternehmenslösungen können niedrigere oder höhere Werte akzeptabel sein.

Faktoren für die Wahl von minSdkVersion

Der erste Faktor ist das Distribution Dashboard. Android Studio liefert monatlich aktualisierte Statistiken aktiver Geräte nach API-Ebene basierend auf Google Play-Daten. minSdkVersion sollte mindestens 90-95% der aktiven Geräte des Zielmarktes abdecken. Für internationale Apps mit Zielgruppen in Afrika und Südostasien sollte minSdk aufgrund des hohen Anteils älterer Geräte auf 21 (Android 5.0) gesenkt werden.

Der zweite Faktor sind die Abhängigkeitsanforderungen. Jede Bibliothek hat eine eigene minSdkVersion, die in ihrem Manifest angegeben ist. Wenn eine Bibliothek minSdk 29 erfordert und die App minSdk 26 erfordert, schlägt der Build mit einem Manifest-Merger-Fehler fehl. Moderne Google Play Services-Bibliotheken haben minSdk 21, Firebase hat minSdk 21, die meisten Jetpack-Bibliotheken haben minSdk 21 oder 26, und Compose BOM hat minSdk 21. Für Compose beträgt die Mindestschwelle API 21.

Der dritte Faktor sind die erforderlichen APIs. Wenn eine Kernfunktion der App eine API erfordert, die nur ab einer bestimmten Ebene verfügbar ist (z. B. PhotoPicker — API 34, Predicted Navigation — API 35), kann dies eine Erhöhung von minSdk rechtfertigen. Häufiger wird jedoch eine Kombination aus AndroidX-Backports (Activity Result API, NotificationCompat) und Laufzeitprüfungen verwendet, um ein niedriges minSdk beizubehalten.

Schritt-für-Schritt-Auswahlstrategie

Schritt 1: Öffnen Sie Android Studio, File → New Project, und prüfen Sie das empfohlene minSdk im Assistenten. Schritt 2: Prüfen Sie das Distribution Dashboard in Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Schritt 3: Analysieren Sie die Projektabhängigkeiten — führen Sie den Build aus und beheben Sie Manifest-Merger-Konflikte. Schritt 4: Bewerten Sie, welche APIs der Ebene X tatsächlich ohne Backports verwendet werden. Schritt 5: Setzen Sie minSdk auf den Mindestwert, der 90%+ der Zielgruppe abdeckt und mit allen Abhängigkeiten kompatibel ist.

Geräteabdeckung: Verteilung der API-Ebene (2026)

Die Geräteverteilung nach API-Ebene ist eine dynamische Kennzahl, die sich vierteljährlich ändert. Laut Android Studio Distribution Dashboard vom Juni 2026 laufen etwa 85% der aktiven Android-Geräte auf API 26 (Android 8.0) und höher, 72% auf API 29 (Android 10) und höher und 55% auf API 31 (Android 12) und höher. Der chinesische Markt hat aufgrund des Fehlens von Google Play Services auf vielen Huawei-Geräten eigene Statistiken.

GMS-Geräte (Google Mobile Services) aktualisieren schneller: Der Anteil von API 31+ auf ihnen erreicht 68% dank der verbindlichen Google Play-Anforderungen an Hersteller. Nicht-GMS-Geräte (Huawei, Honor, einige chinesische Marken) haben eine ältere Verteilung: Der Anteil von API 31+ auf ihnen beträgt etwa 35%. Wenn Ihre App auf den internationalen Markt abzielt, verlassen Sie sich auf globale Statistiken. Wenn sie auf China abzielt, berücksichtigen Sie das Nicht-GMS-Segment.

Fazit: Für eine internationale App deckt minSdk 26 85% der Geräte mit minimalen Abwärtskompatibilitätskosten ab. Für Apps mit Zielgruppen in Entwicklungsländern ist minSdk 21 (97% Abdeckung) gerechtfertigt, erfordert aber mehr Code für die Arbeit mit Legacy-APIs. Für Unternehmens-Apps mit kontrolliertem Gerätebestand können Sie minSdk 31 setzen und Fallback-Code vollständig eliminieren.

Abwärtskompatibilität: AndroidX, lint und @RequiresApi

Abwärtskompatibilität ist die größte Herausforderung bei einem niedrigen minSdkVersion. AndroidX (ehemals Support Library) bietet Backports moderner APIs für ältere Android-Versionen: AppCompatActivity für Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat und Dutzende anderer Komponenten. Die Verwendung von AndroidX-Äquivalenten anstelle nativer APIs ist der erste Schritt zur Kompatibilität.

lint (der statische Analysator von Android Studio) scannt den Code auf API-Aufrufe oberhalb von minSdkVersion. Wenn eine Methode mit @RequiresApi auf einer höheren API-Ebene als minSdk annotiert und ohne Prüfung aufgerufen wird, markiert lint einen Fehler. Zum Unterdrücken der Warnung verwenden Sie die Annotation @SuppressLint("NewApi") auf der Methode oder @RequiresApi(Build.VERSION_CODES.TIRAMISU) auf der gesamten Funktion. Laufzeitprüfungen über Build.VERSION.SDK_INT sind der Hauptmechanismus, um neue APIs auf älteren Geräten sicher aufzurufen.

// Beispiel für Abwärtskompatibilität: PhotoPicker (API 34+) und Fallback
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import androidx.activity.result.contract.ActivityResultContracts
import androidx.appcompat.app.AppCompatActivity

class ImagePickerActivity : AppCompatActivity() {

    // Activity Result API (AndroidX) — funktioniert auf jeder API-Ebene
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker ist nur ab API 34 verfügbar
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // PhotoPicker verwenden (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Fallback: GetContent (funktioniert auf allen Versionen)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // Diese Methode kann nicht auf API aufgerufen werden < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

Die Klasse ImagePickerActivity demonstriert drei Ebenen der Abwärtskompatibilität. Die Activity Result API von AndroidX funktioniert auf allen API-Ebenen, daher hängt die grundlegende Bildauswahl nicht von minSdk ab. PhotoPicker (ACTION_PICK_IMAGES) ist nur ab API 34 verfügbar und wird unter einer SDK_INT-Prüfung mit Fallback auf GetContent aufgerufen. Die Methode usePhotoPickerOnly ist mit @RequiresApi markiert — lint erlaubt keinen Aufruf ohne Prüfung. AppCompat von AndroidX passt das Theme, Fragmente und Animationen automatisch an die OS-Version an.

minSdkVersion in Bibliotheken und Modulen

Bibliotheken (AAR, JAR) haben ebenfalls eine in ihrem Manifest angegebene minSdkVersion. Beim Anbinden einer Bibliothek prüft Gradle die Kompatibilität: Ist das minSdk der Bibliothek höher als das minSdk der App, schlägt der Build mit einem Fehler fehl. Für öffentliche Bibliotheken wird empfohlen, das niedrigstmögliche minSdk (in den meisten Fällen 21) anzugeben, um Verbraucher nicht einzuschränken. Wenn eine Bibliothek API 29+ erfordert, verliert sie ~28% potenzielle Nutzer.

Multimodul-Projekte können für verschiedene Module unterschiedliche minSdkVersion-Werte haben. Beispielsweise kann das Modul :core:network minSdk 26 haben, während das Modul :feature:camera minSdk 29 haben kann (aufgrund von CameraX mit bestimmten Anforderungen). Google Play verlangt, dass das minSdk des Hauptmoduls :app niedriger oder gleich dem minSdk aller abhängigen Module ist. In der Praxis haben alle Module einer App normalerweise dasselbe minSdk, um die Wartung zu vereinfachen.

// build.gradle.kts — Bibliotheksmodul mit niedrigem minSdk
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.mylibrary"
    compileSdk = 36

    defaultConfig {
        minSdk = 21  // Minimum für maximale Abdeckung
        targetSdk = 36
    }
}

dependencies {
    // AndroidX Core — minSdk 21, fügt Backports hinzu
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

Ein Bibliotheksmodul mit minSdk = 21 ist mit 97% der Geräte kompatibel und schränkt Verbraucher nicht ein. Wenn die Bibliothek APIs über 21 verwendet, muss der Entwickler Laufzeitprüfungen hinzufügen oder @RequiresApi auf den entsprechenden Methoden angeben. AndroidX Core KTX (minSdk 21) bietet Backports für Context, Bundle, Locale und andere Systemklassen, sodass die Bibliothek ein niedriges minSdk beibehalten kann.

Häufige Fehler bei der Wahl von minSdkVersion

Fehler bei der Wahl von minSdk können Tausende von Installationen oder Wochen zusätzlicher Entwicklung kosten. Der erste häufige Fehler ist das Kopieren von minSdk aus einer Projektvorlage ohne Analyse des Distribution Dashboards. Viele Entwickler belassen minSdk = 21 aus der Android Studio-Vorlage, obwohl minSdk 26 für ihre Zielgruppe ausreichen und die Anzahl der SDK_INT-Prüfungen im Code reduzieren würde.

Der zweite Fehler ist ein zu hohes minSdk ohne Berücksichtigung des Marktes. Wenn Sie minSdk = 31 (Android 12) für eine internationale App setzen, verlieren Sie ~45% der Geräte. Für ein Startup oder eine App mit Massenpublikum ist das eine Katastrophe. Überprüfen Sie vor der Erhöhung von minSdk immer das Distribution Dashboard und verwenden Sie A/B-Tests in der Google Play Console, wenn Sie unsicher sind.

Der dritte Fehler ist das Ignorieren des minSdk von Abhängigkeiten. Überprüfen Sie beim Hinzufügen einer neuen Bibliothek deren minSdk in der Dokumentation oder POM-Datei. Firebase ML Kit erfordert minSdk 21, einige benutzerdefinierte Kamerabibliotheken erfordern minSdk 29. Wenn der Manifest-Merger in der Produktion aufgrund einer neuen Bibliothek fehlschlägt, kann die Behebung Tage dauern.

// Beispiel: Laufzeit-API-Kompatibilitätsprüfung
fun checkFeatureAvailability(): Boolean {
    // Typischer Fehler — API-Aufruf ohne SDK_INT-Prüfung
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — PhotoPicker verwenden
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — MediaStore verwenden
            true
        }
        else -> {
            // API < 29 — wir verwenden ACTION_GET_CONTENT
            true
        }
    }
}

Die korrekte Architektur für API-Ebenen-Prüfungen ist ein when-Ausdruck mit Bereichen, die alle möglichen Werte von minSdk bis compileSdk abdecken. Die Hauptregel: Jeder Aufruf einer API der Ebene X muss durch eine VERSION.SDK_INT-Prüfung für alle Geräte mit API-Ebene von minSdk bis X geschützt sein. lint hilft beim Erkennen ungeprüfter Aufrufe, kann aber keine vollständige Abdeckung für dynamischen Code garantieren.