API cible 36 sur Google Play : prolongation au 1er novembre 2026 et correctif Expo, Flutter, React Native

L'exigence de niveau d'API cible 36 sur Google Play signifie qu'une version compilée pour une cible inférieure à Android 16 ne peut pas être publiée. En octobre 2026, Play refuse toute nouvelle application et toute mise à jour qui cible un niveau inférieur, souvent avec le message Target SDK of artifact is too low. Les applications ayant reçu un avertissement lié aux règles pouvaient demander un délai supplémentaire, mais la prolongation s'arrête le 1er novembre 2026. Ce guide explique ce que la prolongation vous apporte encore, comment passer Expo, Flutter et React Native à l'API 36, et ce qui a tendance à casser ensuite.

Que bloque réellement l'exigence de niveau d'API cible 36 ?

Elle bloque les envois. Depuis le 31 août 2026, vous ne pouvez plus importer une nouvelle application pour téléphone ni une mise à jour si elle ne cible pas l'API 36. Les applications déjà publiées qui ciblent l'API 35 ou plus restent entièrement disponibles, y compris pour les nouveaux utilisateurs.

D'après les exigences de Google concernant le niveau d'API cible, « les nouvelles applications et les mises à jour d'applications doivent cibler Android 16 (niveau d'API 36) ou version ultérieure pour être envoyées sur Google Play ». Les exigences varient selon le format d'appareil, et la seule exception complète concerne les applications définitivement privées destinées à une distribution interne au sein d'une seule organisation.

Une application existante en dessous de ces niveaux « ne sera disponible que sur les appareils équipés d'une version d'Android identique ou inférieure au niveau d'API cible de votre application ». Les personnes qui l'ont déjà installée continuent de l'utiliser comme avant. En revanche, quelqu'un avec un téléphone plus récent voit un message indiquant que l'application « a été conçue pour une ancienne version d'Android ».

Pouvez-vous encore obtenir la prolongation avant le 1er novembre 2026 ?

Seulement si Play a envoyé un avertissement lié aux règles à votre application et que le formulaire de demande y apparaît toujours. Même dans ce cas, la prolongation dure au plus tard jusqu'au 1er novembre 2026 : ce sont quelques jours de plus pour un correctif presque terminé, pas un nouveau plan.

Google indique qu'il envoie « un lien vers un formulaire de demande de prolongation via leurs Notifications » aux applications concernées, et que le formulaire est « disponible sur la page de détails de l'avertissement ou du problème dans la page État des règles ». Google n'affiche aucun formulaire pour les applications déjà conformes.

1. Ouvrez la Play Console et sélectionnez l'application.
2. Cherchez le message sur le niveau d'API cible dans la boîte de réception ou les Notifications. S'il y est, suivez son lien.
3. Sinon, allez dans État des règles, ouvrez l'avertissement ou le problème lié au niveau d'API cible et cherchez le formulaire de demande de prolongation sur sa page de détails.
4. Remplissez le formulaire pour chaque application concernée. Chaque application a son propre avertissement.
5. Que la prolongation soit accordée ou non, prévoyez d'importer un build ciblant l'API 36 avant le 1er novembre 2026. Après cette date, les mises à jour exigent l'API 36.

Comment passer Expo, Flutter et React Native à l'API 36 ?

La voie la plus propre consiste à passer à une version du framework qui cible déjà l'API 36 : Expo SDK 54, React Native 0.81 ou Flutter 3.38. Si vous ne pouvez pas encore mettre à niveau, vous pouvez augmenter le chiffre à la main, mais vous devrez alors gérer vous-même les changements de comportement d'Android 16.

Expo. Le changelog du SDK 54 indique que le SDK 54 et React Native 0.81 « ciblent désormais Android 16 ». Mettez à niveau avec npx expo install expo@^54.0.0 --fix, lancez npx expo-doctor@latest et, si vous utilisez Continuous Native Generation, « supprimez les répertoires android et ios si vous les avez générés pour une version précédente du SDK ». Sur le SDK 53, vous pouvez essayer de définir targetSdkVersion: 36 via le plugin expo-build-properties, mais React Native 0.79 gère toujours le retour via onBackPressed : lisez la section suivante avant de publier.

Flutter. Les notes de version de Flutter 3.38 indiquent comme valeurs par défaut flutter.compileSdkVersion (API 36) et flutter.targetSdkVersion (API 36), et « vous encouragent vivement à utiliser les variables de niveau d'API fournies par le SDK Flutter dans vos fichiers de build ». La version 3.38 exige aussi au minimum Java 17. Si targetSdk = 35 est codé en dur dans le module de votre application, la mise à niveau de Flutter ne le modifiera pas : vérifiez le fichier.

React Native bare. Passez compileSdkVersion et targetSdkVersion à 36 dans android/build.gradle. À partir de la 0.81, l'essentiel est fait. Sur les versions plus anciennes, ajoutez aussi android:enableOnBackInvokedCallback="false" à <application> dans AndroidManifest.xml. Sans cela, le bouton retour physique et le geste de retour contournent votre navigation JavaScript.

Qu'est-ce qui casse quand une application commence à cibler Android 16 ?

Ce sont le plus souvent la navigation retour et les mises en page grand écran qui cassent. Avec l'API 36 comme cible, Android cesse d'appeler onBackPressed, ne vous laisse plus désactiver l'affichage bord à bord et ignore les verrouillages d'orientation et de redimensionnement sur les écrans d'au moins 600dp de large.

Les changements les plus importants pour les applications multiplateformes, d'après les changements de comportement d'Android 16 publiés par Google :

• Retour prédictif : « onBackPressed n'est plus appelé et KeyEvent.KEYCODE_BACK n'est plus distribué. » Définir android:enableOnBackInvokedCallback="false" permet une désactivation temporaire.
• Bord à bord : windowOptOutEdgeToEdgeEnforcement est « obsolète et désactivé », donc un en-tête ou un bouton en bas d'écran peut se retrouver sous la barre d'état ou la barre de gestes.
• Grands écrans : sur les écrans de 600dp de large et plus, screenOrientation, resizableActivity et les limites de format d'image sont ignorés, ce qui peut étirer des mises en page prévues uniquement en portrait. Les jeux sont exemptés. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY est une désactivation temporaire qui « ne s'appliquera plus en ciblant le niveau d'API 37 ».
• Texte : elegantTextHeight est ignoré, ce qui peut modifier la hauteur de ligne pour l'arabe, le thaï, le tamoul et plusieurs autres écritures.
• Capteurs de santé : BODY_SENSORS est remplacé par des autorisations de santé granulaires comme READ_HEART_RATE.

Quels problèmes d'autres développeurs ont-ils rencontrés en passant à l'API 36 ?

Les retours publics recensés jusqu'ici montrent deux types de difficultés : un comportement du bouton retour qui change sans la moindre erreur, et des bibliothèques qui font que le niveau cible du bundle reçu par Play diffère de ce qu'indiquent les fichiers du projet.

Audius (React Native 0.79). Dans la pull request #14635, l'équipe d'Audius explique que Google Play a refusé les deux imports de la version Android 1.5.186 avec Target SDK of artifact is too low. Elle a passé compileSdk et targetSdk de 35 à 36, réglé les build tools sur 36.0.0 et ajouté android.suppressUnsupportedCompileSdk=36, parce que « RN 0.79 fige AGP 8.8 ». Elle a aussi défini enableOnBackInvokedCallback="false", car sans cela le retour « contournerait React Navigation ». Une PR ultérieure a supprimé cette désactivation après le passage à React Native 0.81, qui enregistre lui-même un OnBackPressedCallback.

Une application Flutter 3.35.2. Dans l'issue Flutter #174516, un développeur a défini targetSdk 36 dans Gradle et dans le manifeste, mais la Play Console indiquait toujours « Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version. » La suppression de l'ancienne bibliothèque com.google.android.play:core:1.10.3 a entraîné des erreurs R8 « Missing classes ». Leur correction a conduit à « You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles. » Le bundle a finalement été accepté après l'ajout de règles keep ProGuard, la définition explicite de minSdk et la désactivation des splits par langue, densité et ABI, au prix d'un téléchargement plus lourd.

La leçon commune : changer le chiffre dans Gradle ne suffit pas. Audius a dû corriger le comportement à l'exécution, et le développeur Flutter a dû corriger une dépendance qui modifiait ce que Play lisait dans le bundle. Vérifiez l'artefact compilé et testez sur un appareil Android 16, pas seulement le fichier de configuration.

Comment vérifier un build API 36 avant de l'importer ?

Lisez le niveau cible directement dans le bundle de release, puis placez-le sur un canal de test interne ou fermé et testez la navigation retour, les marges système (insets) et une mise en page tablette sous Android 16. Un refus ou un bug en production coûte bien plus de temps que ces vérifications.

Exemple concret : une application Expo SDK 53 qui cible l'API 35 et a besoin d'une mise à jour de plus.

1. Lancez npx expo install expo@^54.0.0 --fix, puis npx expo-doctor@latest, et corrigez tout ce qui est signalé.
2. Si le projet utilise Continuous Native Generation, supprimez les anciens dossiers android et ios et recompilez. Sinon, appliquez à la main les modifications natives de la mise à niveau.
3. Compilez l'AAB de release, par exemple avec eas build -p android --profile production.
4. Confirmez la cible avec bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. La commande doit afficher 36.
5. Importez le build en test interne. Sur un téléphone Android 16, appuyez sur retour dans chaque écran imbriqué, vérifiez que les en-têtes et les boutons du bas ne sont pas masqués par les barres système, et faites pivoter une tablette ou un émulateur redimensionnable.
6. Passez en production avec des notes de version qui mentionnent les correctifs pour Android 16.

Pour accélérer les tests, reprenez la configuration des testeurs de notre guide sur les tests fermés Google Play, et inspirez-vous de nos exemples de notes de version pour le texte de la mise à jour. Si vous préférez déléguer la publication, notre service de soumission App Store couvre la Play Console et App Store Connect pour 599 $ pour les deux stores. Les frais des comptes développeur sont en sus.