API cible 36 sur Google Play : ce que la règle d'août 2026 change pour votre app

Depuis le 31 août 2026, les nouvelles apps et les mises à jour envoyées à Google Play doivent cibler Android 16 (niveau d'API 36) ou plus. Les apps Wear OS et Automotive doivent cibler l'API 35 ; les apps TV et XR, l'API 34. Le délai supplémentaire proposé par Google courait jusqu'au 1er novembre 2026 : il est terminé.

Si vous lancez un test fermé maintenant, votre premier build doit déjà cibler 36.

La règle, mot pour mot

D'après les exigences de Google concernant le niveau d'API cible :

• « Les nouvelles applications et mises à jour d'application doivent cibler Android 16 (niveau d'API 36) ou version ultérieure pour être envoyées à Google Play, à l'exception des applications Wear OS et Android Automotive OS, qui doivent cibler Android 15 (niveau d'API 35) ou version ultérieure, et des applications Android TV et Android XR, qui doivent cibler Android 14 (niveau d'API 34) ou version ultérieure. »
• « Les applications existantes doivent cibler Android 15 (niveau d'API 35) ou version ultérieure pour rester accessibles aux nouveaux utilisateurs se servant d'appareils équipés d'une version de l'OS Android supérieure au niveau d'API cible de votre application. »

Les définitions de Google : une nouvelle application est une app pas encore publiée sur Google Play ; une mise à jour d'application est une nouvelle version envoyée pour remplacer une app existante. La seule exception citée concerne les apps définitivement privées, limitées à une organisation.

Le délai supplémentaire est terminé

Google permettait de demander plus de temps, jusqu'au 1er novembre 2026, via un formulaire dans la Play Console (Aide Play Console). Au 8 novembre 2026, cette date est passée. Partez du principe qu'il n'y a pas de délai.

Pourquoi c'est important pendant le test fermé

Les nouveaux comptes personnels publient leurs premiers builds sur la piste de test fermé, et ces builds doivent respecter les mêmes règles d'envoi. La page de Google n'exempte pas les pistes de test. En pratique :

• Compilez la version du test fermé avec targetSdk = 36. Le même bundle pourra ensuite passer en production une fois l'accès accordé par Google.
• Évitez si possible de changer l'API cible en plein test. Monter la cible change le comportement de l'app (voir plus bas). Mieux vaut livrer ce changement avant le jour 1 que découvrir des problèmes au jour 12.
• Les mises à jour pendant le test ne posent pas de problème. Google encourage à mettre à jour votre app pendant le test fermé (Aide Play Console). Chaque mise à jour doit aussi cibler 36.

Comment définir l'API cible

Dans le fichier Gradle du module de votre app (Android Developers) :

// build.gradle.kts
android {
    compileSdk = 36
    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 36
        versionCode = 12
        versionName = "1.2"
    }
}

// build.gradle (Groovy)
android {
    compileSdkVersion 36
    defaultConfig {
        targetSdkVersion 36
    }
}

Google indique qu'on peut la définir dans le fichier Gradle ou avec l'attribut android:targetSdkVersion de l'élément <uses-sdk> du manifeste (Android Developers). La plupart des projets la définissent dans Gradle : regardez là en premier.

Les frameworks multiplateformes fixent souvent cette valeur via leurs propres variables ou versions de SDK. Voyez les notes par framework pour Flutter et React Native et Expo.

Vérifiez aussi vos SDK et bibliothèques. Le guide de migration de Google demande de vérifier que les SDK tiers sont compatibles avec le niveau d'API que vous ciblez, et de voir avec leur fournisseur s'ils ne le sont pas (Android Developers).

Ce qui change quand vous ciblez Android 16

Cibler 36 active des changements de comportement qui ne s'appliquent qu'aux apps qui le ciblent. D'après les changements de comportement d'Android 16 publiés par Google :

Bord à bord, sans désactivation possible. Android 15 permettait aux apps de désactiver l'affichage bord à bord avec windowOptOutEdgeToEdgeEnforcement. Pour les apps qui ciblent 36 sur Android 16, cet attribut est « obsolète et désactivé ». Vérifiez que barres d'outils, barres du bas et boutons ne passent pas sous la barre d'état ou la barre de navigation.

Retour prédictif. Pour les apps qui ciblent 36 sur un appareil Android 16, les animations de retour prédictif sont activées par défaut, et « onBackPressed n'est pas appelé et KeyEvent.KEYCODE_BACK n'est plus distribué ». Si votre app intercepte le retour, migrez vers les API de retour prises en charge, ou désactivez temporairement la fonction avec android:enableOnBackInvokedCallback="false" dans le manifeste.

Les grands écrans ignorent les verrous d'orientation et de redimensionnement. Sur les écrans dont la plus petite largeur atteint 600 dp ou plus, « les restrictions d'orientation, de redimensionnement et de format ne s'appliquent plus ». Une app verrouillée en portrait remplit une tablette en paysage. Les jeux (déclarés avec android:appCategory) sont exclus de ce changement. Il existe une propriété de désactivation temporaire, android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY, dont Google dit qu'elle ne s'appliquera plus quand vous ciblerez l'API 37.

elegantTextHeight est ignoré. Vérifiez la mise en page du texte si votre app affiche de l'arabe, du lao, du birman, du tamoul, du gujarati, du kannada, du malayalam, de l'odia, du télougou ou du thaï.

Planification à intervalle fixe. Avec scheduleAtFixedRate, une seule exécution manquée au plus est lancée quand l'app revient dans un état de cycle de vie valide, au lieu de toutes.

La page liste d'autres changements, dont les autorisations de santé et de remise en forme, la gestion de l'association Bluetooth et une résolution d'intents plus stricte (sur option). Lisez les sections qui touchent vos fonctionnalités.

Un plan de test pour la montée de cible

Le guide de migration de Google conseille de tester les parcours principaux après le changement de cible, y compris les autorisations refusées, les modes Sommeil (Doze) et App Standby, et le partage de fichiers avec d'autres apps (Android Developers). Pour l'API 36, ajoutez :

1. La navigation arrière sur un appareil ou un émulateur Android 16, avec la navigation par gestes activée.
2. Chaque écran en bord à bord : barre d'état, barre de navigation, clavier ouvert.
3. Un émulateur de tablette ou de pliable dans les deux orientations, si votre app verrouille l'orientation.
4. Le rendu du texte dans les écritures listées plus haut, si vous les prenez en charge.

Votre test fermé est un bon endroit pour attraper le reste. Demandez aux testeurs quel appareil et quelle version d'Android ils utilisent, et cherchez des tendances dans les rapports de bugs venant de tablettes et de téléphones Android 16.

Liste de contrôle

• compileSdk et targetSdk à 36 (35 pour Wear OS et Automotive, 34 pour TV et XR).
• SDK tiers mis à jour vers des versions compatibles avec l'API 36.
• Gestion du retour migrée, ou désactivation temporaire choisie en connaissance de cause.
• Mises en page bord à bord vérifiées sur Android 16.
• Comportement sur grand écran vérifié si vous verrouillez l'orientation.
• versionCode augmenté à chaque nouvel envoi.

Ensuite, configurez la piste : Comment configurer un test fermé. Pour toute la démarche, voyez le guide des tests fermés Google Play.