targetSdkVersion : concepts clés, behavioural changes et Google Play

Qu'est-ce que targetSdkVersion dans Android ?

targetSdkVersion est un paramètre entier dans build.gradle qui déclare l'API Level contre lequel l'application a été testée. Le système Android utilise ce paramètre pour décider quels behavioural changes appliquer à l'application lors de l'exécution. Si targetSdkVersion = 33, Android applique tous les behavioural changes introduits jusqu'à API 33 inclus, mais n'applique pas les modifications d'API 34+. Si targetSdkVersion = 34 — les modifications jusqu'à API 34 sont appliquées, et ainsi de suite.

La différence clé entre targetSdkVersion et minSdkVersion réside dans le mécanisme d'action. minSdk est vérifié une fois lors de l'installation et bloque l'installation si la condition n'est pas remplie. targetSdkVersion affecte le comportement runtime du système sur chaque appareil, indépendamment de la version d'Android sur laquelle l'application s'exécute. La même application avec targetSdk 31 se comportera différemment sur Android 13, 14 et 15, car les behavioural changes au-dessus de 31 sont désactivés.

Le mécanisme de targetSdkVersion est un outil de rétrocompatibilité intégré à Android. Sans lui, chaque mise à jour de l'OS casserait des milliers d'anciennes applications. Google a introduit ce mécanisme dans Android 2.1 (API Level 7) et l'utilise depuis comme méthode standard pour introduire de nouvelles règles de sécurité, de confidentialité et de gestion des ressources sans casser les applications existantes.

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

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

// Vérification du targetSdk actuel dans le code
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion contient le targetSdk de l'application
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Dans l'exemple, targetSdk = 36 active tous les behavioural changes d'Android 16. Le code vérifie targetSdkVersion via context.applicationInfo.targetSdkVersion — cela permet de déterminer dynamiquement quel mode de compatibilité est activé. La fonction d'assistance est utile pour les bibliothèques qui doivent s'adapter au targetSdk de l'application appelante.

Behavioural Changes : comment targetSdk affecte l'application

Les behavioural changes sont des modifications du comportement du système Android qui ne s'appliquent qu'aux applications avec targetSdkVersion >= un certain API Level. Chaque nouvelle version majeure d'Android introduit des behavioural changes, et si une application ne met pas à jour targetSdk, ces modifications ne prennent pas effet. Ce mécanisme permet aux développeurs de mettre à jour leur application à leur propre rythme, plutôt que de manière synchrone avec une nouvelle version de l'OS.

Scoped Storage (API 29) est l'un des behavioural changes les plus significatifs. Les applications avec targetSdk 29+ ne peuvent pas obtenir un accès File direct aux répertoires partagés Pictures, Downloads, Music, Documents. À la place, MediaStore est utilisé pour les médias, SAF (Storage Access Framework) pour les fichiers arbitraires et getExternalFilesDir() pour le stockage privé. Les anciennes applications avec targetSdk 28 et inférieur continuent de fonctionner avec l'ancien Full Storage Access, mais cela crée un risque de sécurité.

POST_NOTIFICATIONS (API 33) est une permission runtime pour envoyer des notifications. Les applications avec targetSdk 33+ doivent demander la permission Manifest.permission.POST_NOTIFICATIONS à l'utilisateur via la boîte de dialogue standard. Si la permission n'est pas accordée, NotificationManager.silent() n'affiche pas les notifications à l'utilisateur. Sur Android 13+ sans cette permission, les notifications push et les notifications locales ne s'affichent tout simplement pas, ce qui peut réduire considérablement l'engagement des utilisateurs.

Comment vérifier le targetSdk actuel

La valeur de targetSdkVersion peut être obtenue via ADB : la commande adb shell dumpsys package com.example.myapp | grep targetSdk affiche targetSdk=34. Dans le code, context.getApplicationInfo().targetSdkVersion retourne un entier. Pour l'analyse, il est utile de journaliser targetSdk avec android.os.Build.VERSION.SDK_INT pour comprendre quels behavioural changes sont réellement actifs dans chaque session.

Exigences de Google Play pour targetSdkVersion (2026)

Google Play établit des exigences obligatoires de targetSdkVersion pour toutes les applications publiées. Depuis août 2024, le targetSdk minimum = 33 (Android 13). Depuis août 2025, targetSdk = 34. On s'attend à ce qu'à partir d'août 2026, Google exige targetSdk = 35 (Android 15). Les nouvelles applications et les mises à jour des applications existantes doivent se conformer à ces exigences, sinon la console bloque la publication. C'est une politique de Google Play, pas une restriction d'Android Runtime : une application avec targetSdk 34 peut fonctionner sur Android 16, mais ne peut pas être publiée sur le Play Store.

Android App Bundle (AAB) est le format de publication obligatoire depuis août 2021. L'APK n'est plus accepté dans Google Play (sauf pour les applications de plus de 150 Mo et certains projets legacy). Le format AAB permet à Google de générer des APK optimisés pour chaque API Level et densité d'écran, réduisant la taille de téléchargement de 15 à 30 %. Pour vérifier targetSdk, Google Play analyse le manifeste AAB et émet une erreur avec la valeur minimale requise s'il n'est pas conforme.

La Google Play Console vérifie targetSdkVersion non seulement lors du téléchargement d'un nouvel AAB, mais aussi lors de la mise à jour d'une application existante. Si votre application a targetSdk 33 et que Google élève le seuil minimum à 34 — vous ne pourrez publier aucune mise à jour tant que vous n'aurez pas augmenté targetSdk. Pour les applications qui n'ont pas été mises à jour depuis longtemps, Google Play peut les retirer automatiquement de la publication (unpublish).

Comment mettre à jour targetSdkVersion sans erreurs

Mettre à jour targetSdkVersion ne consiste pas seulement à changer un nombre dans build.gradle. Chaque behavioural change peut casser une fonctionnalité existante si le code n'est pas préparé à l'avance. Il est recommandé de commencer la préparation 3 à 6 mois avant la date limite de Google Play, surtout si l'application est grande et utilise de nombreuses API système.

Processus étape par étape : Étape 1 — étudiez les behavioural changes pour le nouvel API Level dans la documentation Android Developers (page "Behavioural Changes by API Level"). Étape 2 — créez une branche targetSdk-update et modifiez targetSdk à la nouvelle valeur. Étape 3 — exécutez l'application sur un émulateur ou un appareil avec le nouvel API Level et vérifiez chaque fonctionnalité liée aux changements. Étape 4 — corrigez les erreurs : ajoutez des permissions, modifiez la gestion des fichiers, mettez à jour le manifeste.

Étape 5 — testez sur les anciens appareils. Augmenter targetSdk n'affecte pas les appareils avec un API Level inférieur au nouveau targetSdk, mais les behavioural changes s'appliquent à tous les appareils avec API Level >= targetSdk. Si vous avez augmenté targetSdk de 33 à 34, sur les appareils avec API 34+ les behavioural changes de l'API 34 seront activés. Sur les appareils avec API 33, rien ne changera.

// Préparation pour 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 limite l'Advertising ID à partir de l'API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — identifiant indisponible, utilisez MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Vérification : quels behavioural changes sont actifs
    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")
        }
    }
}

La classe AdsManager montre la préparation à Privacy Sandbox (API 35). L'Advertising ID devient indisponible à partir de l'API 35 avec targetSdk 35+. La fonction getActiveChanges démontre le modèle correct pour vérifier les behavioural changes : il faut vérifier à la fois SDK_INT de l'appareil et targetSdk de l'application. Ce n'est que lorsque les deux conditions correspondent que le changement est réellement actif.

Android 15 (API 35) : principaux behavioural changes

Android 15 (API 35, Vanilla Ice Cream) introduit plusieurs behavioural changes critiques que les développeurs doivent prendre en compte lors de la mise à jour de targetSdk vers 35. Premièrement — Privacy Sandbox for Android. C'est l'initiative de Google pour remplacer l'Advertising ID par des API plus privées : Topics API (intérêts de l'utilisateur), Protected Audience (reciblage) et Attribution Reporting (conversions). À partir de l'API 35, l'Advertising ID cesse d'être un identifiant stable et peut retourner une valeur nulle.

Le deuxième changement — Foreground Service Types (API 34, continué dans API 35). À partir de l'API 34, chaque application avec targetSdk 34+ doit spécifier le type de service au premier plan dans le manifeste : dataSync, systemExempted, shortService, location, mediaPlayback et autres. Sans cela, le système génère une ForegroundServiceTypeNotAllowedException. Dans l'API 35, un nouveau type health a été ajouté et la validation des types existants a été renforcée. Tous les services au premier plan doivent être révisés.

Le troisième changement — restriction sur SCHEDULE_EXACT_ALARM. À partir de l'API 35, les applications avec targetSdk 35+ ne peuvent pas utiliser SCHEDULE_EXACT_ALARM sans autorisation explicite de l'utilisateur. Le système affiche une boîte de dialogue et l'utilisateur doit approuver la planification exacte. Pour les alarmes et les minuteurs, cela signifie une étape UX supplémentaire. Une alternative est d'utiliser des alarmes inexactes avec une marge de 10 minutes.

// Android 15 (API 35) : vérification de SCHEDULE_EXACT_ALARM
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+ : autorisation de l'utilisateur requise
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Sous API 35 — alarmes exactes disponibles sans autorisation
        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 et la restriction des alarmes sont les deux behavioural changes les plus critiques de l'API 35. Les SDK publicitaires devront migrer vers Topics API et Attribution Reporting. Pour les applications avec alarmes et rappels — adaptation de l'UX pour la boîte de dialogue d'autorisation. Ignorer ces changements entraînera des plantages de l'application au runtime sur Android 15 ou une monétisation publicitaire cassée.

Différence entre targetSdk et compileSdk

La différence entre targetSdkVersion et compileSdkVersion est l'une des sources de confusion les plus courantes parmi les développeurs Android. compileSdkVersion est la version du SDK contre laquelle le code est compilé. Elle détermine quelles API sont disponibles au moment de la compilation, mais n'affecte pas le comportement runtime. targetSdkVersion est la version contre laquelle l'application est testée — elle détermine quels behavioural changes s'appliquent au runtime. compileSdk peut et doit être supérieur ou égal à targetSdk.

La règle est simple : compileSdk >= targetSdk >= minSdk. compileSdk est généralement égal au dernier API Level stable (en 2026 — 36). targetSdk doit être aussi élevé que possible parmi les versions que vous avez testées. minSdk doit être aussi bas que possible pour une couverture maximale. Augmenter compileSdk ne nécessite pas de tester les behavioural changes — cela ouvre seulement l'accès aux nouvelles API pour le compilateur. Augmenter targetSdk nécessite un cycle complet de test de tous les behavioural changes.

En pratique : si vous souhaitez utiliser une nouvelle API d'Android 16 (API 36) mais n'avez pas encore testé les behavioural changes de l'API 36, définissez compileSdk = 36, targetSdk = 35. Le code sera compilé avec les nouvelles API, mais les behavioural changes de l'API 36 ne seront pas appliqués. Une fois que vous avez testé tous les changements — augmentez targetSdk à 36.