Niveau d'API cible sur Google Play : que vise votre bundle ?

Google Play impose un plancher strict au targetSdkVersion, et il monte chaque année. Sous le plancher, la Play Console bloque purement et simplement l'envoi — ce n'est pas l'appréciation d'un testeur, c'est une barrière. Cette page donne le seuil actuel, le calendrier annuel, et comment lire ce que votre .aab ou .apk vise vraiment avant de l'apprendre à la dure.

Dernière vérification le 24 juillet 2026.

Le plancher actuel et le calendrier annuel

La règle de Google est mécanique : votre app doit viser un niveau d'API datant de moins d'un an après la dernière version majeure d'Android. Une version majeure sort chaque automne, donc autour du 31 août de chaque année le plancher exigé monte d'un cran. Cela vaut pour les nouvelles apps et pour chaque mise à jour d'une app existante — impossible de publier un build qui vise sous le plancher.

Les apps existantes que vous ne mettez pas à jour bénéficient d'un délai plus long, mais doivent finir par se conformer pour rester disponibles sur les appareils récents. Voici le calendrier en l'état :

À partir du	Nouvelles apps et mises à jour doivent viser	Apps existantes doivent viser
31 août 2024	API 34 (Android 14)	API 34 pour rester visibles
31 août 2025	API 35 (Android 15)	—
31 août 2026	API 36 (Android 16)	API 35 (Android 15) ou plus

Source : aide de la Play Console — « Exigences relatives au niveau d'API cible pour les applications Google Play ». Les échéances des apps existantes suivent le plancher des nouvelles apps avec environ un an de retard.

targetSdkVersion vs minSdkVersion vs compileSdkVersion

Les développeurs confondent régulièrement ces trois-là, et un seul est ce que Play impose. Ils se règlent indépendamment dans build.gradle :

Propriété	Ce qu'elle contrôle	Règle de Play ?
`targetSdkVersion`	Le niveau d'API pour lequel votre app déclare avoir été conçue et testée. Il active les changements de comportement de cette version. C'est celui que Play contrôle.	Oui — plancher strict.
`minSdkVersion`	La plus ancienne version d'Android sur laquelle l'app s'installe. Plus bas = plus d'anciens appareils, plus de code hérité.	Non.
`compileSdkVersion`	Le niveau d'API contre lequel le code est compilé — les API que voit le compilateur. En général égal ou supérieur à la cible.	Non, mais doit être ≥ à la cible pour compiler.

Vous pouvez (et le faites souvent) garder un minSdkVersion bas pour la couverture tout en visant le dernier niveau d'API pour satisfaire Play — les deux sont indépendants. Monter targetSdkVersion implique de gérer les changements de comportement de la nouvelle version ; cela ne retire pas la prise en charge des vieux appareils (c'est minSdkVersion).

L'erreur exacte de la Play Console

Quand un .aab vise sous le plancher, la Play Console bloque la version avec un message de cette forme :

Your app currently targets API level 34 and must target at
least API level 35 to ensure it is built on the latest APIs
optimized for security and performance. To upload an app
bundle it must target API level 35 or higher.

C'est une erreur bloquante, pas un avertissement — le bundle ne sera pas envoyé. Les deux nombres du message sont votre cible actuelle et le plancher exigé ; la correction consiste à monter targetSdkVersion au niveau requis dans build.gradle et à recompiler.

Lire targetSdkVersion depuis un .aab / .apk sans Android Studio

Pas besoin d'une compilation complète Android Studio pour vérifier ce que vise un bundle. La valeur est dans le manifeste — mais le manifeste d'un artefact compilé est encodé en binaire (AXML dans un APK, protobuf dans un AAB), donc `unzip` + `cat` ne donnera rien. Utilisez plutôt les outils en ligne de commande du SDK.

Pour un .apk

# aapt (ou aapt2) decode le manifeste binaire
aapt dump badging app.apk | grep -o "targetSdkVersion:'[0-9]*'"
#  -> targetSdkVersion:'35'

# ou apkanalyzer (fourni avec les cmdline-tools du SDK Android)
apkanalyzer manifest target-sdk app.apk
#  -> 35

Pour un .aab (App Bundle)

# bundletool lit le manifeste protobuf via XPath
java -jar bundletool.jar dump manifest --bundle=app.aab \
  --xpath=/manifest/uses-sdk/@android:targetSdkVersion
#  -> 35

aapt, aapt2 et apkanalyzer vivent dans les build-tools / cmdline-tools du SDK Android ; bundletool est un jar autonome fourni par Google. Aucun ne compile ni n'exécute l'app — ils décodent juste le manifeste, la vérification prend donc une seconde sur n'importe quelle machine dotée d'un JDK.

La voie de la prolongation d'un an

Si vous ne pouvez vraiment pas tenir l'échéance du 31 août, Google propose une prolongation unique à demander depuis la Play Console — elle repousse votre échéance au 1er novembre de la même année. Elle est prévue pour de vrais blocages techniques, pas pour un retard ordinaire :

Vous la demandez par application dans la Play Console avant l'expiration du délai — un parcours dédié apparaît quand votre app est signalée non conforme.
Elle offre environ deux mois de plus (jusqu'au 1er novembre), pas une année supplémentaire.
Elle sert à garder disponible une app existante ; elle ne permet pas de publier entre-temps des mises à jour visant sous le plancher.
Elle vise des cas légitimes (une dépendance pas encore compatible, une grosse migration). Google peut refuser les demandes qui ressemblent à de l'évitement.

La prolongation est un sursis, pas un correctif — la seule réponse durable est de monter targetSdkVersion et de gérer les changements de comportement de la nouvelle version.

Questions fréquentes

Quel niveau d'API cible Google Play exige-t-il en ce moment ?

Sur la fenêtre 2025-2026, les nouvelles apps et les mises à jour doivent viser au moins le niveau d'API 35 (Android 15). À partir du 31 août 2026, le plancher pour les nouvelles apps et les mises à jour passe à l'API 36 (Android 16), et les apps existantes doivent viser au moins l'API 35 pour rester disponibles sur les appareils récents.

Monter targetSdkVersion fait-il perdre les vieux téléphones ?

Non. La prise en charge des anciens appareils dépend de minSdkVersion, qui est indépendant. Vous pouvez garder un minSdkVersion bas et monter quand même targetSdkVersion pour satisfaire Play. Monter la cible impose en revanche de gérer les changements de comportement de la nouvelle version d'Android.

La Play Console dit que ma cible est trop basse alors qu'Android Studio affiche le bon nombre. Pourquoi ?

Vérifiez la valeur dans l'artefact réellement compilé, pas seulement dans les sources. Une variante de produit, une surcharge du manifeste ou un ancien build peuvent embarquer un targetSdkVersion plus bas que ce que suggère votre build.gradle. Lisez-le directement dans le .aab/.apk avec bundletool ou aapt pour voir ce que vous avez vraiment envoyé.

Puis-je obtenir du temps au-delà du 31 août ?

Oui — la Play Console propose une prolongation unique jusqu'au 1er novembre de la même année pour les apps qui ne peuvent pas tenir l'échéance. Elle vise les blocages techniques légitimes et ne fait que maintenir l'app existante disponible ; elle n'autorise pas de mises à jour sous le plancher.

L'exigence de niveau d'API cible, est-ce la même chose qu'un refus à l'examen ?

Non. C'est une barrière automatique à l'envoi dans la Play Console, appliquée avant tout examen. Aucun testeur n'intervient — le bundle ne part tout simplement pas tant que targetSdkVersion n'atteint pas le plancher.

Sources

Vérifiez votre build avant de soumettre

Passez votre .ipa ou .apk dans App Review Checker et détectez ces problèmes en quelques secondes.

Analyser une app