SDK Platform : qu'est-ce que c'est, versions et Android SDK Manager

Qu'est-ce que SDK Platform

SDK Platform est un composant fondamental du SDK Android, représentant un ensemble complet de bibliothèques et d'outils pour développer des applications pour une version spécifique d'Android. Chaque plateforme est identifiée par son API Level — un nombre entier qui augmente avec les nouvelles versions de l'OS. Par exemple, Android 13 correspond à l'API Level 33, Android 14 à l'API Level 34, Android 15 à l'API Level 35.

Contrairement à Android Studio (IDE), SDK Platform ne contient pas d'éditeur de code ni de débogueur. C'est une couche système qui se connecte au compilateur et au système de compilation. Lorsqu'un développeur écrit import android.app.Activity, le compilateur prend cette classe depuis android.jar d'une SDK Platform spécifique. Sans plateforme installée avec l'API Level requis, le code ne sera pas compilé.

Google publie une nouvelle SDK Platform pour chaque version stable d'Android. L'histoire comprend plus de 35 API Levels — d'Android 1.0 (API 1) à Android 15 (API 35). Chaque plateforme est rétrocompatible : le code écrit pour l'API Level 21 fonctionnera sur l'API Level 35, mais pas l'inverse.

Pourquoi une SDK Platform séparée est nécessaire pour chaque version

Android évolue rapidement : chaque version ajoute de nouvelles API, modifie le comportement des existantes et introduit des restrictions. Par exemple, Android 10 (API 29) a introduit Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — les indicateurs obligatoires de BroadcastReceiver. Le développeur doit compiler l'application contre la plateforme actuelle pour utiliser ces capacités.

En même temps, l'application peut fonctionner sur des versions anciennes de l'OS. Pour cela, on spécifie minSdk dans Gradle — l'API Level minimal sur lequel l'application s'exécute. Le code utilise des vérifications de version et des appels d'API conditionnels. Cette approche garantit la compatibilité sans perdre les nouvelles fonctionnalités.

Composition de SDK Platform : composants principaux

SDK Platform n'est pas un fichier unique, mais un ensemble de composants qui ensemble assurent la compilation, la construction et le test de l'application. L'élément principal est android.jar — une archive avec les classes de l'API Android incluses dans cette version. Ce fichier se connecte au compilateur Kotlin ou Java et détermine quelles classes, méthodes et annotations sont disponibles pour le développeur.

Images système et émulateur

Chaque SDK Platform inclut une System Image — une image du système d'exploitation pour l'émulateur Android Virtual Device. Sans l'image correspondante, l'émulateur ne peut pas démarrer un périphérique virtuel avec l'API Level requis. Les System Images existent en différents types : Google APIs (avec les services Google), Google Play (avec Play Store) et AOSP (Android pur sans services Google).

Outils de compilation et de débogage

SDK Platform inclut une version de Build-Tools et Platform-Tools optimisée pour cet API Level. Build-Tools contient aapt2 (Android Asset Packaging Tool), dx/d8 (compilateur Dalvik/ART) et ApkSigner. Platform-Tools fournit ADB (Android Debug Bridge), fastboot et SQLite. Ces outils sont mis à jour indépendamment de SDK Platform via SDK Manager.

Ressources de la plateforme

Chaque plateforme inclut des ressources Android standard — thèmes système, styles, animations, couleurs et dimensions. Ces ressources sont utilisées lors de la compilation : si un développeur fait référence à @android:style/Theme.Material.Light, le système de compilation prend la définition depuis les ressources de SDK Platform. Cela garantit une apparence uniforme des composants système sur tous les appareils.

API Level et versions de SDK Platform

API Level est un identifiant entier de la version du SDK Android. Chaque version d'Android correspond à un API Level qui augmente de façon monotone. Le développeur spécifie l'API Level dans trois paramètres clés de build.gradle : compileSdk, minSdk et targetSdk. Le choix de ces paramètres détermine quelles API sont disponibles et comment le système traite l'application.

Google recommande de maintenir minSdk à un niveau non inférieur au seuil de distribution actuel — selon Android Studio Distribution Dashboard (2026), environ 95 % des appareils fonctionnent sous Android 8.0 (API 26) et supérieur. compileSdk doit être le dernier stable — cela donne accès aux nouvelles API et permet aux vérifications lint de détecter les méthodes obsolètes.

Évolution de l'API Level : changements clés

Avec chaque nouvel API Level, Google introduit des changements significatifs. Android 6.0 (API 23) a ajouté les permissions runtime — l'application demande les permissions pendant l'exécution, pas à l'installation. Android 8.0 (API 26) a introduit l'autocomplétion des formulaires et les canaux de notification. Android 12 (API 31) a radicalement changé l'approche des intents — SplashScreen API est apparu et l'exportation de composants via l'attribut exported. Android 14 (API 34) a rendu obligatoire la spécification des indicateurs pour BroadcastReceiver et a introduit des restrictions strictes sur les services en premier plan.

Comprendre l'histoire des API Levels aide le développeur à choisir la bonne stratégie de compatibilité. Si l'application utilise compileSdk 35 mais minSdk 26, le code ne peut appeler les méthodes de l'API 35 qu'après avoir vérifié la version via Build.VERSION.SDK_INT. Cette approche s'appelle le développement à version contrôlée et est une norme de l'industrie.

SDK Manager : installation et configuration

SDK Manager est un outil de gestion des composants du SDK Android : installer une nouvelle SDK Platform, mettre à jour les existantes et supprimer les obsolètes. SDK Manager est disponible sous forme d'interface graphique dans Android Studio ainsi qu'en outil en ligne de commande via sdkmanager. La ligne de commande de SDK Manager est pratique à utiliser dans les pipelines CI/CD où il n'y a pas d'interface graphique.

SDK Manager installe les plateformes dans le répertoire du SDK Android, qui se trouve par défaut dans $HOME/Android/Sdk sous Linux et macOS ou %LOCALAPPDATA%\Android\Sdk sous Windows. À l'intérieur du répertoire platforms se trouvent des dossiers nommés android-{API Level}, chacun contenant la SDK Platform complète.

Installation de SDK Platform via sdkmanager

La commande sdkmanager accepte un identifiant de paquet au format "platforms;android-{API}". Par exemple, pour installer SDK Platform 35, la commande est :

# Installer SDK Platform pour l'API Level 35
sdkmanager "platforms;android-35"

# Installer plusieurs plateformes avec une seule commande
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Lister les plateformes installées
sdkmanager --list_installed | grep platforms

# Supprimer la plateforme obsolète
sdkmanager --uninstall "platforms;android-28"

Installation automatique via Gradle

Les projets Android modernes utilisent Gradle Plugin, qui peut installer automatiquement SDK Platform lors de la première compilation. Pour ce faire, il faut spécifier compileSdk dans build.gradle et ajouter le répertoire SDK dans la configuration locale. Android Studio propose également d'installer la plateforme manquante lors de l'ouverture d'un projet — il suffit de cliquer sur le bouton "Install SDK Platform" dans la fenêtre de synchronisation Gradle.

Il est important de mettre à jour régulièrement SDK Platform via SDK Manager — avec la plateforme, Build-Tools et Platform-Tools sont mis à jour, ce qui affecte les performances de compilation et la stabilité du débogage. Google recommande de vérifier les mises à jour du SDK toutes les 2 à 3 semaines, surtout avant de publier une nouvelle version de l'application sur Google Play.

Configuration d'une image système pour l'émulateur

Pour exécuter l'émulateur avec un API Level spécifique, il faut installer une System Image de la même version. SDK Manager permet de télécharger des images de différentes architectures (x86_64, arm64-v8a) et types (Google APIs, Google Play, AOSP). Après le téléchargement de l'image, AVD Manager crée un périphérique virtuel basé sur celle-ci.

# Installer System Image avec Google APIs pour l'API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Créer un AVD via la ligne de commande
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Lister les AVD créés
avdmanager list avd

compileSdk, targetSdk et minSdk dans Gradle

Trois paramètres dans build.gradle définissent comment l'application fonctionne avec SDK Platform. compileSdk est l'API Level utilisé pour la compilation. Ce paramètre spécifie quelles classes de l'API Android sont disponibles dans le code. compileSdk doit être le plus récent des trois et n'affecte pas le comportement runtime — l'application compile mais n'utilise que les API disponibles sur l'appareil.

minSdk est l'API Level minimal sur lequel l'application peut être installée. Google Play ne permettra pas d'installer l'application sur un appareil dont la version est inférieure à minSdk. Ce paramètre définit le seuil de compatibilité et affecte la couverture d'audience. Plus minSdk est bas, plus d'appareils sont pris en charge, mais moins de nouvelles API peuvent être utilisées sans vérifications.

targetSdk est l'API Level contre lequel l'application a été testée. Le système Android utilise targetSdk pour appliquer les changements de comportement : si l'application n'est pas mise à jour vers un nouvel API Level, le système active le mode de compatibilité pour les anciennes versions. Google Play exige que targetSdk ne soit pas inférieur à un certain niveau — en 2026, il s'agit de l'API 34 (Android 14).

Exemple de configuration Gradle

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
    }
}

// La version du SDK Android doit être installée via SDK Manager
// sdkmanager "platforms;android-35"

Comment choisir compileSdk, minSdk et targetSdk

La stratégie de sélection dépend des objectifs du projet. Pour une nouvelle application : compileSdk — le dernier stable (35 début 2026), minSdk — API 26 (Android 8.0, couvre 95% des appareils), targetSdk — le dernier stable. Pour mettre à jour une application existante : augmentez compileSdk immédiatement, targetSdk — après avoir testé tous les changements de comportement, minSdk — seulement lorsqu'il est nécessaire d'abandonner les appareils anciens.

Google exige que targetSdk soit mis à jour dans l'année suivant la sortie d'une nouvelle version d'Android. Les applications qui ne respectent pas cette exigence ne peuvent pas publier de mises à jour sur Google Play. Pour suivre les délais, utilisez le calendrier officiel des mises à jour d'Android OS.

Exemples de travail avec SDK Platform dans le code

Lors du développement pour différentes versions d'Android, il faut tenir compte de la disponibilité de l'API. Si l'application utilise compileSdk 35 mais fonctionne sur un appareil avec API 31, l'appel de méthodes ajoutées dans l'API 34 entraînera une NoSuchMethodError ou une AbstractMethodError. Pour appeler de nouvelles API en toute sécurité, des vérifications de version via Build.VERSION.SDK_INT sont utilisées.

Vérification de l'API Level au runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Les canaux de notification sont disponibles depuis l'API 26
            val channel = NotificationChannel(
                "updates",
                "Mises à jour",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Utilisation de nouvelles API avec @RequiresApi

Pour les méthodes qui ne sont appelées que sur des versions spécifiques, utilisez l'annotation @RequiresApi. Cela indique aux vérifications lint que la méthode est sûre et désactive les avertissements. Combinée à la vérification de SDK_INT, l'annotation rend le code plus propre et plus compréhensible pour les relecteurs.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34 : scheduleExact avec l'indicateur SCHEDULE_EXACT_ALARM
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Demander l'autorisation SCHEDULE_EXACT_ALARM
        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 {
        // Ancienne méthode setExact sans vérification d'autorisation
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Détermination de la SDK Platform installée

Il est parfois nécessaire de savoir quelle version de SDK Platform est installée sur l'appareil du développeur ou dans le CI. Cela peut être fait via ADB ou par programmation dans le code de l'application. Connaître l'API Level de l'appareil aide lors du test de comportements spécifiques à une version.

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