Échéance API 36 de Google Play: ce qui change le 31 août 2026

Google relève une fois par an le seuil de niveau d’API cible du Play Store, et 2026 est le cycle de l’API 36. Le nombre n’est pas la partie compliquée. La partie compliquée, c’est que "l’exigence de niveau d’API cible" désigne en réalité deux règles sous un seul nom: l’une gouverne ce que vous avez le droit d’importer, l’autre, plus basse, gouverne qui peut encore installer ce qui est déjà publié. Presque toutes les pages positionnées sur cette question mélangent les deux, et c’est ainsi que des développeurs reconstruisent une application qui n’avait pas besoin de l’être, ou ignorent un avertissement de Play Console qui comptait.

Cet article les sépare, vous donne les nombres par format d’appareil, puis répond à la question que notre support reçoit vraiment au mois d’août: qu’est-ce que cela fait à une application au milieu d’un test fermé (closed testing) de 12 testeurs sur 14 jours consécutifs? PrimeTestLab prend en charge cette partie testing pour les développeurs, nous voyons donc la collision de calendrier en permanence, et les conseils de cette section valent que vous passiez par un service ou que vous recrutiez vos testeurs vous-même. Chaque date et chaque niveau ci-dessous ont été vérifiés sur les pages de Google le 9 août 2026, et tout ce que Google n’a pas réellement documenté est signalé comme tel plutôt que comblé par une supposition assurée.

La règle en une phrase

À partir du 31 août 2026, une application ordinaire pour téléphone, tablette, pliable ou Android Auto doit cibler Android 16, niveau d’API 36 ou supérieur pour être envoyée sur Google Play, qu’il s’agisse d’une toute nouvelle application ou de la mise à jour d’une application publiée. Cette seule phrase couvre la majorité des lecteurs. Les exceptions, et le seuil plus bas réservé aux applications auxquelles vous ne touchez pas, occupent le reste de cet article.

Un seul nom, deux règles distinctes

Google emploie l’expression "exigence de niveau d’API cible" pour deux choses qui ne se comportent pas du tout pareil. Les garder séparées est la chose la plus utile que vous puissiez tirer de cette page.

Une application posée tranquillement sur l’API 35, sans mise à jour prévue, est donc conforme au 31 août au titre de la règle 2, et devient non conforme à l’instant où vous tentez de publier quoi que ce soit au titre de la règle 1. Ce n’est pas une contradiction, c’est le principe: Google relève plus vite la barre de ce qui entre dans le magasin que celle de ce qui y reste.

Les trois termes que Google définit précisément

Les règles reposent sur trois termes, et chacun a un sens précis qui décide de la règle dont vous relevez:

• Nouvelle application: une application "non encore publiée sur Google Play". Le premier import d’un nom de package.
• Application existante: une application déjà publiée sur Google Play.
• Mise à jour: une nouvelle version d’une application existante envoyée à l’examen pour remplacer la version en cours. Une mise à jour est jugée par la règle d’envoi, pas par la règle de disponibilité.

Les exigences par format d’appareil

"Application Android" n’est pas une seule ligne. Téléphones, tablettes, pliables et Android Auto passent à l’API 36. Wear OS et Android Automotive OS s’arrêtent à l’API 35. Android TV et Android XR s’arrêtent à l’API 34. Les seuils d’une application que vous ne mettez pas à jour sont encore plus bas, et le sélecteur ci-dessous bascule entre les deux jeux.

Android Auto n’est pas Android Automotive OS

Ces deux noms coûtent du temps aux développeurs chaque année. Android Auto projette une application depuis un téléphone sur l’écran de la voiture: l’application est donc une application pour téléphone et suit la règle du téléphone, API 36. Android Automotive OS est le système d’exploitation qui tourne dans le véhicule lui-même, et il fait partie des exceptions à cible plus basse explicitement citées: API 35. Si vous développez une application multimédia ou de navigation livrée sur les deux, vous devez retenir le plus élevé des deux niveaux.

Êtes-vous concerné? Répondez à trois questions

Savoir si le 31 août est votre problème dépend de trois choses: ce que vous vous apprêtez à faire, le format d’appareil que vous livrez et ce que cible réellement votre version actuelle. L’outil ci-dessous applique les seuils publiés par Google à cette combinaison et vous dit de laquelle des deux règles vous relevez.

Si le verdict vous déclare tranquille, vous voudrez quand même la liste de contrôle finale à la fin, parce que "mes sources indiquent une cible 36" et "l’artefact que Google a évalué déclare 36" ne sont pas la même affirmation. Le faux sentiment de sécurité le plus répandu de tout ce cycle, c’est un développeur qui lit son fichier Gradle au lieu de son bundle importé.

Ce qui se passe vraiment si vous manquez le 31 août

Deux choses différentes, selon la règle dont vous relevez. Si vous tentez d’importer une version sous le seuil, l’envoi ne satisfait pas l’exigence. Si vous vous contentez de laisser une application publiée inchangée sous le seuil de disponibilité, elle cesse d’être visible et installable pour les nouveaux utilisateurs dont l’appareil exécute une version d’Android plus récente que celle qu’elle cible. Aucune de ces deux issues n’est une suppression.

Si vous tentez d’importer

Notez à quoi cette conséquence est attachée: à l’acte d’importer. Le calendrier seul ne fait rien à une version déjà en ligne. C’est ainsi qu’une application peut être parfaitement conforme le 1er septembre et bloquée le 2 septembre, uniquement parce que vous avez décidé de publier une correction de bug.

Si vous laissez une application publiée sous le seuil

C’est le cas que les concurrents décrivent comme "votre application disparaît", ce qui est faux d’une manière qui compte. La formulation de Google est que l’application "ne sera plus visible" pour un groupe précis d’utilisateurs. Concrètement:

• Les nouveaux utilisateurs sur appareils récents perdent l’accès. Si l’appareil d’une personne exécute une version d’Android supérieure à la cible de votre application, Google Play ne la lui montre plus et ne l’installe plus.
• Les nouveaux utilisateurs sur appareils plus anciens ne sont pas touchés. Un appareil dont le niveau d’API est identique ou inférieur à la cible de l’application peut toujours la recevoir.
• Les personnes qui l’ont déjà installée ne sont pas touchées. Quiconque a déjà installé l’application peut encore la retrouver, la réinstaller et l’utiliser sur les versions d’Android compatibles.
• Les liens profonds disent la vérité. Une personne sur un appareil récent non éligible qui ouvre votre lien Play Store se voit annoncer que l’application a été "conçue pour une version antérieure d’Android".

Ce qui n’arrive pas

Chaque mois d’août, cette règle produit les quatre mêmes peurs sur les forums d’assistance de Google. Aucune ne correspond à ce que décrit la page du niveau d’API cible.

Cibler l’API 36 va-t-il tuer la prise en charge des anciens appareils?

Non, pas en soi. targetSdk déclare le niveau de comportement Android pour lequel votre application est construite et testée. minSdk décide de la plus ancienne version d’Android sur laquelle elle peut s’installer. Ce sont deux nombres distincts, et passer la cible à 36 ne relève pas le minimum: votre application peut continuer de prendre en charge des versions plus anciennes jusqu’à ce minimum, à condition que votre code et vos dépendances mises à jour restent compatibles.

C’est le malentendu qui provoque le plus d’inquiétude à chaque cycle. Un développeur lit "doit cibler Android 16", en déduit "ne tourne que sur Android 16", et conclut que Google vient de supprimer la majorité de son parc d’appareils. Faites glisser le minimum ci-dessous et regardez ce qui change réellement.

Les trois nombres, et celui que Google Play contrôle

Ce que cela implique si votre application est en test fermé en ce moment

Si vous êtes un nouveau compte de développeur personnel et que vous faites tourner le test fermé obligatoire de 12 testeurs pendant 14 jours consécutifs, l’échéance tombe au milieu de votre fenêtre. Le geste sûr consiste à faire entrer la version API 36 dans le même canal fermé avant le 31 août, à garder tous vos testeurs inscrits et à ne jamais laisser une échéance vous forcer à changer de canal ou à repartir de zéro avec de nouveaux testeurs.

La page de Google sur le niveau d’API cible et sa page sur le test fermé sont écrites par des équipes différentes, pour des objectifs différents, et aucune des deux ne parle de l’autre. Il reste donc un vrai vide, et l’honnêteté consiste à vous montrer exactement où s’arrête le terrain documenté.

Ce qui est vérifié

• Un nouveau compte personnel concerné "doit exécuter un test fermé" avec au moins 12 testeurs inscrits sans interruption depuis 14 jours avant de pouvoir demander l’accès en production. Cela vaut pour les comptes personnels créés après le 13 novembre 2023. Vérifié
• La documentation destinée aux développeurs indique qu’un APK importé doit respecter les exigences de niveau d’API cible de Play, et ne publie aucune exception pour les canaux de test. Cette formulation est indépendante du canal, elle n’est pas propre au test: une nouvelle importation sur le canal fermé après l’échéance doit donc être planifiée comme exigeant l’API 36. C’est une inférence solide, pas une règle documentée propre aux canaux de test. Partiel
• Google encourage lui-même les développeurs à continuer de mettre à jour l’application en test fermé pendant qu’ils corrigent des problèmes, et définit la période qualifiante autour de la continuité d’inscription des testeurs, pas autour d’un artefact figé. Vérifié
• Le test interne est plafonné à 100 testeurs et ne remplace pas le test fermé qualifiant. Vérifié

Ce que Google n’a pas documenté

Comme la réponse est inconnue, la bonne stratégie n’est pas de la prédire. C’est de rendre la question sans objet en ayant une version conforme dans le canal avant la date, ce qui est sûr quel que soit le dénouement et ne vous coûte rien si l’ancien artefact avait de toute façon continué de tourner.

La séquence sûre dans les deux cas

1. Gardez le même canal fermé et le même groupe de testeurs

   Ne créez pas un canal neuf pour accueillir la version API 36 et ne retirez aucun testeur inscrit. La continuité de 14 jours que Google compte porte sur des testeurs qui restent inscrits: c’est cette inscription qui est l’actif à protéger.

2. Construisez et testez l’API 36 avant l’échéance, pas le jour même

   Traitez la migration comme une tâche à part entière, avec sa propre passe de tests. Découvrir une rupture d’affichage bord à bord le 30 août n’est pas du tout la même journée que la découvrir le 10 août.

3. Importez-la dans le canal fermé existant avec un code de version supérieur

   Chaque bundle de remplacement a besoin d’un code de version incrémenté. Google définit la période qualifiante autour de la continuité d’inscription des testeurs et encourage explicitement les développeurs à continuer de corriger des problèmes pendant le test, mais il ne publie aucune garantie absolue couvrant tous les cas de remplacement de version. Gardez le même canal et les mêmes testeurs inscrits, puis vérifiez ensuite le compteur de Play Console. Toute la mécanique de la mise à jour en cours de test mérite une lecture si c’est votre premier cycle.

4. Vérifiez que la version est réellement arrivée chez les testeurs

   Une version publiée n’est pas une version livrée. Vérifiez que la version fermée est bien en ligne, que le code de version est supérieur et que les testeurs de la liste d’inscription voient la mise à jour.

5. Recontrôlez l’état des règles après traitement

   Laissez le bundle se traiter, puis rouvrez la page d’état des règles de l’application. Si l’avertissement de niveau d’API cible persiste, déroulez la liste de diagnostic plutôt que de supprimer des versions au hasard.

6. Ne demandez la prolongation que si la migration ne peut vraiment pas aboutir à temps

   Elle vous mène jusqu’au 1er novembre 2026 et se demande pour chaque application concernée. Ce n’est pas une raison de suspendre le travail technique.

Comment demander la prolongation jusqu’au 1er novembre 2026

Les développeurs concernés peuvent demander une prolongation qui maintient la distribution jusqu’au 1er novembre 2026. Elle se demande application par application, depuis l’avertissement de règles de cette application dans Play Console. Google ne la décrit ni comme automatique, ni comme garantie, ni comme une exemption permanente: poursuivez donc la migration pendant que la demande est ouverte.

Google Play Console · capture réelle Cliquez pour agrandir

1. Ouvrez l’application concernée dans Play Console

   L’accès à la prolongation est propre à l’application, pas au compte. Si vous publiez plusieurs applications, prévoyez de répéter l’opération pour chacune de celles qui sont concernées.

   Vérifié
2. Allez dans Policy status

   Seules les applications que Google considère non conformes sont censées porter le problème de niveau d’API cible. Si l’application est déjà conforme, il n’y a rien à prolonger ici et aucun formulaire à trouver.

   Vérifié
3. Ouvrez l’avertissement de niveau d’API cible ou les détails du problème

   Le titre du problème visible sur la capture ci-dessus est App must target Android 16 (API level 36) or higher. La formulation peut varier selon l’application et l’état du déploiement: considérez-la comme ce qu’un compte réel a vu, pas comme une chaîne universelle garantie.

   Vérifié
4. Suivez le lien de prolongation dans le problème, ou dans vos notifications

   Google fait passer une partie des développeurs concernés par la notification de l’application plutôt que par le panneau du problème. Regardez les deux avant de conclure que l’option n’existe pas chez vous.

   Vérifié
5. Envoyez les informations demandées

   Google ne publie pas les questions exactes sur sa page d’aide publique: considérez donc toute liste des "questions posées" comme non vérifiée. Répondez à partir de votre véritable plan de migration.

   Partiel
6. Traitez le 1er novembre 2026 comme la butée définitive

   La prolongation déplace la date, elle ne supprime pas l’exigence. Ce que vous n’avez pas pu finir pour le 31 août doit être fini pour le 1er novembre.

   Vérifié
7. Continuez la migration pendant que la demande est ouverte

   Rien dans la formulation de Google ne promet un accord. Planifier autour d’une prolongation que vous n’avez pas reçue est l’hypothèse la plus coûteuse disponible ce cycle-ci.

   Partiel

Une dernière distinction à garder en tête: Google rattache la note de prolongation à l’exigence de l’API 36, et sa prose décrit le plus souvent la prolongation comme préservant la distribution d’une application existante. Elle ne détaille pas avec la même précision toutes les combinaisons de nouvelle application, de mise à jour et d’application existante. Avant de supposer qu’une prolongation couvre tel envoi que vous avez prévu, lisez ce que l’avertissement de votre propre application dit couvrir.

Comment faire passer une application à l’API 36

Quatre étapes: installer le SDK API 36, passer compileSdk et targetSdk à 36, mettre à jour les dépendances qui cassent quand vous le faites, et tester les changements de comportement d’Android 16. Changer le nombre est une modification d’une ligne. Prouver que l’application fonctionne encore, c’est la vraie migration.

Étape 1: installer le SDK Android 16

Ouvrez Android Studio, allez dans le SDK Manager et installez la plateforme SDK Android pour le niveau d’API 36 ainsi que les build tools 36.x.x actuels. Sans la plateforme installée, relever compileSdk ne produit qu’une erreur de compilation qui semble sans rapport avec ce que vous venez de faire.

Étape 2: relever les niveaux dans votre build

Choisissez votre stack. Le chemin du fichier et les lignes exactes changent, la destination non: le manifeste contenu dans le bundle que vous importez doit déclarer la cible 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Étape 3: mettre à jour les dépendances et l’outillage du framework

Relever le niveau de compilation, c’est là que les anciennes dépendances lâchent. Prévoyez de toucher à l’Android Gradle Plugin, à Gradle lui-même, à Kotlin, aux bibliothèques AndroidX, aux services Google Play et à tout SDK publicitaire ou d’analytics qui embarque du code natif. Cet article ne publie volontairement pas "les bonnes versions", parce que les versions compatibles bougent chaque semaine et qu’une liste figée ici induirait en erreur en quinze jours. Prenez-les dans les notes de version à jour de votre propre framework, le jour où vous migrez.

Étape 4: compiler, importer et vérifier l’artefact

• Générez un Android App Bundle signé et incrémentez le code de version.
• Testez l’artefact de version, pas seulement un build de débogage. La minification et la réduction des ressources cassent des choses que les builds de débogage masquent.
• Importez sur le canal visé et vérifiez dans Play Console que l’artefact annonce bien le niveau d’API cible 36.
• Après traitement, passez en revue chaque canal actif et rouvrez l’état des règles.

Les comportements Android 16 à tester avant de publier en API 36

Cibler l’API 36 active les comportements d’Android 16 pour votre application sur les appareils Android 16. Les comportements prioritaires à tester sont l’affichage bord à bord, le retour prédictif, la liberté d’orientation sur grand écran, les autorisations de santé, la planification à fréquence fixe et la mise en page du texte. Cochez ce qui s’applique ci-dessous et vous obtenez la liste de tests de votre application plutôt qu’une liste générique.

Bord à bord et retour prédictif: le plus large rayon d’impact

L’affichage bord à bord a un large rayon d’impact parce qu’il n’exige aucune API exotique de la part de votre application. Sur Android 16, une application qui cible l’API 36 ne peut plus utiliser l’attribut de désactivation précédent: le contenu qui supposait que les barres système lui laisseraient la place passe donc désormais dessous. Le symptôme est cosmétique, jusqu’au moment où un bouton principal se retrouve sous la barre de gestes et cesse d’être cliquable.

Le retour prédictif présente un rayon d’impact tout aussi large. Si votre application enregistre une gestion du retour à l’ancienne, ce chemin peut tout simplement ne plus se déclencher comme avant, une fois le retour prédictif activé par défaut pour la cible 36. Testez le retour depuis chaque profondeur de navigation: fenêtres modales, WebViews, formulaires avec des données non enregistrées, et le dernier écran avant la sortie.

Ce qui n’est pas une rupture universelle de la cible 36

Et l’exigence des pages de 16 KB?

Exigence différente, date différente, mêmes applications. L’échéance du niveau d’API cible porte sur le niveau que déclare votre manifeste. L’exigence des pages de 16 KB porte sur la capacité de vos bibliothèques natives à fonctionner sur des appareils dont les pages mémoire font 16 KB. Les recommandations actuelles de Google nomment le 1er février 2027 comme date à partir de laquelle les mises à jour concernées sans prise en charge des 16 KB ne pourront plus être publiées.

• Qui est concerné: l’exigence de Google vise les applications ciblant l’API 35 ou supérieur sur les appareils Google Play 64 bits. Dans ce groupe, celles qui empaquettent des bibliothèques natives .so, directement ou via un SDK, sont les plus susceptibles de demander un vrai travail de recompilation et d’alignement. Si votre application est uniquement en Kotlin ou en Java, elle est en général déjà compatible, mais mieux vaut le tester que le supposer.
• Ce que ce n’est pas: cela ne fait pas partie de l’échéance du niveau d’API cible du 31 août 2026, et satisfaire l’une ne satisfait pas l’autre.
• Pourquoi les deux tombent ensemble: tout le monde relève son niveau cible ce mois-ci et recompile de toute façon, et c’est précisément là que la vérification des pages remonte à la surface. C’est ce calendrier qui fait qu’on les confond.

Si votre application embarque des bibliothèques natives, traitez la vérification des pages comme une tâche à part entière, avec sa propre passe de tests, plutôt que comme quelque chose à glisser dans la version API 36 à la dernière minute. Les deux changements touchent des parties différentes du build, et les déboguer en même temps est la meilleure façon de transformer une migration d’une semaine en une migration de trois.

Vous avez importé l’API 36 et l’avertissement est toujours là

En général l’une de trois choses: le bundle n’a pas fini d’être traité et l’état des règles ne s’est pas actualisé, un artefact plus ancien est encore posé sur un autre canal actif, ou l’artefact que vous avez importé ne déclare pas réellement 36 même si votre projet le fait. Déroulez la liste, et ne commencez pas à supprimer des versions.

Le titre de problème que les développeurs remontent actuellement est Your app must target Android 16 (API level 36) or higher. Google n’a pas publié de message d’erreur canonique complet pour chaque parcours d’importation: traitez donc toute formulation exacte trouvée en ligne, y compris celle-ci, comme observée plutôt qu’officielle. Elle est laissée en anglais parce que c’est ainsi qu’elle a été relevée.

Une habitude règle définitivement la plupart de ces cas: après chaque import, relisez le niveau d’API cible sur l’artefact dans Play Console et notez-le à côté du code de version. Cela prend dix secondes et cela élimine de votre semaine toute la catégorie du "je suis sûr d’avoir corrigé ça".

La liste de contrôle avant l’échéance

Quatorze points, dans l’ordre où ils arrivent réellement. Les quatre derniers sont ceux que l’on saute, et ce sont eux qui décident si l’avertissement disparaît.

Où PrimeTestLab intervient dans cette échéance

Pour être clair sur la frontière: nous ne migrons pas votre code. Relever targetSdk, mettre à jour les dépendances et corriger les changements de comportement d’Android 16 relèvent de votre build, et cet article est toute notre contribution à cette partie. Ce que nous couvrons, c’est l’autre moitié de la collision: les 12 vrais testeurs, inscrits pendant 14 jours consécutifs dont un nouveau compte personnel a besoin avant de pouvoir seulement atteindre la production.

Le problème, c’est le calendrier. On demande à quelqu’un qui publie pour la première fois en août 2026 de faire deux choses difficiles et sans rapport dans la même fenêtre: livrer une version API 36 et tenir un test fermé qualifiant pendant deux semaines d’affilée. La version est une tâche d’ingénierie soluble. Recruter douze personnes réelles qui restent inscrites pendant quatorze jours, sur de vrais appareils, c’est la partie qui avale discrètement un mois.

Faire le test fermé soi-même ou le confier

L’ordre dans lequel s’y prendre ce mois-ci

Si vous affrontez les deux problèmes en même temps, menez-les en parallèle plutôt qu’à la suite. Lancez le test fermé maintenant, parce que ses 14 jours sont du temps calendaire que vous ne pouvez pas compresser, et faites la migration API 36 à côté. Poussez la version conforme dans le même canal fermé quand elle est prête, avec un code de version supérieur et les mêmes testeurs toujours inscrits. Ainsi, l’échéance et la fenêtre de test cessent de se disputer la même quinzaine.

Questions fréquentes

L’essentiel

Instantané des règles vérifié le 9 août 2026. Google met ces pages à jour sans préavis: consultez les sources primaires ci-dessus avant d’agir sur une date. Cet article est programmé pour une nouvelle vérification juste après le 31 août, puis après le 1er novembre 2026.