minSdkVersion : ce que c'est et comment choisir la version minimale d'Android

Qu'est-ce que minSdkVersion dans Android ?

minSdkVersion est un paramètre entier dans build.gradle qui spécifie le niveau d'API Android minimum pour l'installation de l'application. Si le niveau d'API de l'appareil est inférieur à la valeur spécifiée, le PackageManager bloque l'installation et le Google Play Store masque l'application des résultats de recherche pour cet appareil. minSdkVersion est écrit dans AndroidManifest.xml lors de la compilation via la balise <uses-sdk android:minSdkVersion> et est vérifié à chaque installation.

La valeur de minSdkVersion est un compromis entre la portée de l'audience et l'accès aux nouvelles API. Plus minSdk est bas, plus d'appareils peuvent installer l'application, en particulier dans les régions en développement où les smartphones Android anciens sont populaires. Plus minSdk est élevé, moins de code de rétrocompatibilité est nécessaire et plus d'API modernes sont disponibles sans vérifications à l'exécution. Android Jetpack et les bibliothèques AndroidX fournissent des backports de nombreuses nouvelles API vers les anciennes versions d'Android, permettant de choisir un minSdk plus bas sans perdre de fonctionnalités.

minSdkVersion affecte toutes les étapes du développement : analyse statique (lint utilise minSdk pour les avertissements), compatibilité des dépendances (les bibliothèques peuvent nécessiter leur propre minSdk), tests (il faut tester sur des appareils avec minSdk) et Google Play Console (la portée de l'audience est calculée en fonction de minSdk). Changer minSdkVersion est l'une des décisions les plus importantes dans la configuration du projet, car elle affecte le code, les tests et la base d'utilisateurs.

Où minSdkVersion est spécifié

Build.gradle.kts (Kotlin DSL) est la norme moderne dans les projets Android. Le paramètre minSdk est défini dans le bloc defaultConfig au niveau du module. La valeur peut être remplacée pour différents types de compilation et variantes de produit, permettant de tester sur des API plus basses sans modifier la valeur principale.

// build.gradle.kts — configuration de base de minSdk
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"
    }

    // Remplacement de minSdk pour différentes variantes
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

Dans l'exemple, minSdk = 26 correspond à Android 8.0 Oreo. C'est une valeur populaire en 2026 : elle n'exclut qu'environ ~15% des appareils selon le Distribution Dashboard d'Android Studio. compileSdk = 36 donne accès à toutes les API d'Android 16, et targetSdk = 36 inclut les changements de comportement de la dernière version. Pour les compilations de débogage, minSdk peut être abaissé pour les tests sur des émulateurs anciens.

Comment choisir minSdkVersion : facteurs et stratégie

Choisir minSdkVersion est une décision stratégique basée sur l'analyse du public cible, des exigences d'API et de l'écosystème des bibliothèques. Il n'existe pas de valeur unique correcte pour tous les projets. En 2026, Android Studio recommande minSdk = 26 (Android 8.0) comme niveau de base pour les nouveaux projets, mais pour les applications B2B ou les solutions d'entreprise, des valeurs plus basses ou plus élevées peuvent être acceptables.

Facteurs pour choisir minSdkVersion

Le premier facteur est le Distribution Dashboard. Android Studio fournit des statistiques d'appareils actifs par niveau d'API basées sur les données de Google Play, mises à jour mensuellement. minSdkVersion doit couvrir au moins 90 à 95 % des appareils actifs du marché cible. Pour les applications internationales avec un public en Afrique et en Asie du Sud-Est, minSdk doit être abaissé à 21 (Android 5.0) en raison de la forte proportion d'appareils anciens.

Le deuxième facteur sont les exigences des dépendances. Chaque bibliothèque a sa propre minSdkVersion spécifiée dans son manifeste. Si une bibliothèque nécessite minSdk 29 et l'application nécessite minSdk 26, la compilation échouera avec une erreur de fusion de manifeste. Les bibliothèques modernes de Google Play Services ont minSdk 21, Firebase a minSdk 21, la plupart des bibliothèques Jetpack ont minSdk 21 ou 26, et Compose BOM a minSdk 21. Pour Compose, le seuil minimum est API 21.

Le troisième facteur sont les API requises. Si une fonctionnalité clé de l'application nécessite une API disponible uniquement à partir d'un certain niveau (par exemple, PhotoPicker — API 34, Predicted Navigation — API 35), cela peut justifier l'augmentation de minSdk. Cependant, une combinaison de backports AndroidX (Activity Result API, NotificationCompat) et de vérifications à l'exécution est plus souvent utilisée pour maintenir un minSdk bas.

Stratégie de sélection étape par étape

Étape 1 : ouvrez Android Studio, File → New Project, et vérifiez le minSdk recommandé dans l'assistant. Étape 2 : vérifiez le Distribution Dashboard dans Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Étape 3 : analysez les dépendances du projet — exécutez la compilation et corrigez les conflits de fusion de manifeste. Étape 4 : évaluez quelles API de niveau X sont réellement utilisées sans backports. Étape 5 : définissez minSdk comme la valeur minimale couvrant 90 %+ du public cible et compatible avec toutes les dépendances.

Couverture des appareils : répartition des niveaux d'API (2026)

La répartition des appareils par niveau d'API est une mesure dynamique qui change chaque trimestre. Selon le Distribution Dashboard d'Android Studio de juin 2026, environ 85 % des appareils Android actifs fonctionnent sous API 26 (Android 8.0) et plus, 72 % sous API 29 (Android 10) et plus, et 55 % sous API 31 (Android 12) et plus. Le marché chinois a ses propres statistiques en raison de l'absence de Google Play Services sur de nombreux appareils Huawei.

Les appareils GMS (Google Mobile Services) se mettent à jour plus rapidement : la part d'API 31+ sur eux atteint 68 % grâce aux exigences obligatoires de Google Play pour les fabricants. Les appareils non GMS (Huawei, Honor, certaines marques chinoises) ont une répartition plus ancienne : la part d'API 31+ sur eux est d'environ 35 %. Si votre application cible le marché international, fiez-vous aux statistiques mondiales. Si elle cible la Chine, tenez compte du segment non GMS.

Conclusion : pour une application internationale, minSdk 26 couvre 85 % des appareils avec des coûts de rétrocompatibilité minimaux. Pour les applications avec un public dans les régions en développement, minSdk 21 (97 % de couverture) est justifié mais nécessitera plus de code pour fonctionner avec les API héritées. Pour les applications d'entreprise avec un parc d'appareils contrôlé, vous pouvez définir minSdk 31 et éliminer complètement le code de repli.

Rétrocompatibilité : AndroidX, lint et @RequiresApi

La rétrocompatibilité est le principal défi avec un minSdkVersion bas. AndroidX (anciennement Support Library) fournit des backports d'API modernes vers les anciennes versions d'Android : AppCompatActivity pour Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat et des dizaines d'autres composants. Utiliser des équivalents AndroidX au lieu des API natives est la première étape vers la compatibilité.

lint (l'analyseur statique d'Android Studio) scanne le code à la recherche d'appels d'API au-dessus de minSdkVersion. Si une méthode est annotée avec @RequiresApi à un niveau d'API supérieur à minSdk et est appelée sans vérification, lint signale une erreur. Pour supprimer l'avertissement, utilisez l'annotation @SuppressLint("NewApi") sur la méthode ou @RequiresApi(Build.VERSION_CODES.TIRAMISU) sur toute la fonction. Les vérifications à l'exécution via Build.VERSION.SDK_INT sont le mécanisme principal pour appeler en toute sécurité de nouvelles API sur des appareils anciens.

// Exemple de rétrocompatibilité : PhotoPicker (API 34+) et repli
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) — fonctionne à tout niveau d'API
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker n'est disponible qu'à partir de l'API 34
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // Utilisation de PhotoPicker (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Repli : GetContent (fonctionne sur toutes les versions)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // Cette méthode ne peut pas être appelée sur API < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

La classe ImagePickerActivity démontre trois niveaux de rétrocompatibilité. L'Activity Result API d'AndroidX fonctionne à tous les niveaux d'API, donc la sélection d'image de base ne dépend pas de minSdk. PhotoPicker (ACTION_PICK_IMAGES) n'est disponible qu'à partir de l'API 34 et est appelé sous une vérification SDK_INT avec un repli vers GetContent. La méthode usePhotoPickerOnly est marquée avec @RequiresApi — lint n'autorisera pas son appel sans vérification. AppCompat d'AndroidX adapte automatiquement le thème, les fragments et les animations à la version de l'OS.

minSdkVersion dans les bibliothèques et modules

Les bibliothèques (AAR, JAR) ont également une minSdkVersion spécifiée dans leur manifeste. Lors de la connexion d'une bibliothèque, Gradle vérifie la compatibilité : si le minSdk de la bibliothèque est supérieur au minSdk de l'application, la compilation échoue avec une erreur. Pour les bibliothèques publiques, il est recommandé de spécifier le minSdk le plus bas possible (21 dans la plupart des cas) afin de ne pas limiter les consommateurs. Si une bibliothèque nécessite API 29+, elle perd ~28 % d'utilisateurs potentiels.

Les projets multi-modules peuvent avoir différentes valeurs de minSdkVersion pour différents modules. Par exemple, le module :core:network peut avoir minSdk 26, tandis que le module :feature:camera peut avoir minSdk 29 (en raison de CameraX avec des exigences spécifiques). Google Play exige que le minSdk du module principal :app soit inférieur ou égal au minSdk de tous les modules dépendants. En pratique, tous les modules d'une même application ont généralement le même minSdk pour faciliter la maintenance.

// build.gradle.kts — module de bibliothèque avec minSdk bas
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

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

    defaultConfig {
        minSdk = 21  // Minimum pour une couverture maximale
        targetSdk = 36
    }
}

dependencies {
    // AndroidX Core — minSdk 21, ajoute des backports
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

Un module de bibliothèque avec minSdk = 21 est compatible avec 97 % des appareils et ne limite pas les consommateurs. Si la bibliothèque utilise des API supérieures à 21, le développeur doit ajouter des vérifications à l'exécution ou spécifier @RequiresApi sur les méthodes pertinentes. AndroidX Core KTX (minSdk 21) fournit des backports pour Context, Bundle, Locale et d'autres classes système, permettant à la bibliothèque de conserver un minSdk bas.

Erreurs courantes lors du choix de minSdkVersion

Les erreurs lors du choix de minSdk peuvent coûter des milliers d'installations ou des semaines de développement supplémentaire. La première erreur courante est de copier minSdk à partir d'un modèle de projet sans analyser le Distribution Dashboard. De nombreux développeurs laissent minSdk = 21 du modèle Android Studio, alors que minSdk 26 serait suffisant pour leur public et réduirait le nombre de vérifications SDK_INT dans le code.

La deuxième erreur est un minSdk trop élevé sans tenir compte du marché. Si vous définissez minSdk = 31 (Android 12) pour une application internationale, vous perdez ~45 % des appareils. Pour une startup ou une application grand public, c'est une catastrophe. Vérifiez toujours le Distribution Dashboard avant d'augmenter minSdk et utilisez des tests A/B dans Google Play Console si vous n'êtes pas sûr.

La troisième erreur est d'ignorer le minSdk des dépendances. Lors de l'ajout d'une nouvelle bibliothèque, vérifiez son minSdk dans la documentation ou le fichier POM. Firebase ML Kit nécessite minSdk 21, certaines bibliothèques d'appareil photo personnalisées nécessitent minSdk 29. Si la fusion de manifeste échoue en production à cause d'une nouvelle bibliothèque, la correction peut prendre des jours.

// Exemple : vérification de compatibilité d'API à l'exécution
fun checkFeatureAvailability(): Boolean {
    // Erreur typique — appeler une API sans vérifier SDK_INT
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — utilisez PhotoPicker
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — utilisez MediaStore
            true
        }
        else -> {
            // API < 29 — nous utilisons ACTION_GET_CONTENT
            true
        }
    }
}

L'architecture correcte pour les vérifications de niveau d'API est une expression when avec des plages couvrant toutes les valeurs possibles de minSdk à compileSdk. La règle clé : tout appel à une API de niveau X doit être protégé par une vérification VERSION.SDK_INT pour tous les appareils avec un niveau d'API de minSdk à X. lint aide à détecter les appels non vérifiés, mais ne peut pas garantir une couverture complète pour le code dynamique.