L’échéance annuelle de Google Play est arrivée.

Depuis le 31 août 2026, une nouvelle application Android classique doit cibler Android 16, soit le niveau d’API 36, pour être soumise à Google Play.

La même exigence s’applique aux mises à jour d’applications existantes.

Un développeur qui possède encore une application ciblant Android 15 peut donc continuer à la laisser disponible dans certaines conditions, mais il ne peut plus publier normalement une nouvelle version mobile sans passer à l’API 36.

Cibler Android 16 ne signifie pas abandonner les anciens téléphones

Le niveau d’API cible est souvent confondu avec la version minimale d’Android requise par une application.

Ce sont deux paramètres différents.

targetSdkVersion indique à Android la génération de comportement et de règles avec laquelle l’application est censée fonctionner.

minSdkVersion détermine jusqu’à quelle ancienne version du système elle peut être installée.

Une app peut donc cibler Android 16 tout en continuant à prendre en charge des téléphones utilisant des versions Android beaucoup plus anciennes, si son développeur conserve une minSdkVersion compatible.

Google impose désormais une règle à un an pour les nouvelles versions

La politique générale de Google Play exige que les nouvelles applications et leurs mises à jour ciblent une API située dans l’année suivant la dernière grande version d’Android.

Le passage obligatoire à l’API 36 constitue l’application 2026 de cette politique.

L’objectif affiché par Google est de faire bénéficier les utilisateurs des améliorations récentes de sécurité, de confidentialité et de performances au lieu de laisser les développeurs contourner indéfiniment les nouveaux comportements du système en conservant une ancienne targetSdkVersion.

Une application abandonnée à Android 14 n’est pas supprimée du Store

Le traitement des applications déjà disponibles est plus subtil.

Une application mobile existante doit désormais cibler au minimum Android 15, soit l’API 35, pour rester pleinement accessible aux nouveaux utilisateurs sur les systèmes plus récents.

Si elle cible Android 14/API 34 ou une version antérieure, Google ne la retire pas nécessairement de la boutique.

Sa distribution est limitée.

Elle reste accessible aux utilisateurs dont l’appareil fonctionne avec une version d’Android égale ou inférieure à la cible de l’application.

Elle cesse en revanche d’être proposée aux nouveaux utilisateurs dont Android est plus récent que cette cible.

Un téléphone Android 16 peut donc ne plus voir certaines vieilles applications

Prenons une application qui n’a plus été mise à jour et cible toujours Android 13.

Google Play peut continuer à la distribuer à de nouveaux utilisateurs dont le téléphone fonctionne sous Android 13 ou une version antérieure.

Un nouvel utilisateur sous Android 16 ne doit en revanche plus la trouver normalement disponible dans le Store.

Cette politique n’implique pas nécessairement que l’application soit techniquement incapable de fonctionner sur Android 16.

Google choisit de restreindre sa distribution parce qu’elle n’a pas adopté les standards de sécurité et de qualité associés aux générations plus récentes du système.

Les utilisateurs qui possèdent déjà l’app ne sont pas la cible principale de la mesure

La documentation parle explicitement de disponibilité pour les nouveaux utilisateurs.

Le but n’est donc pas de désinstaller automatiquement les applications anciennes déjà présentes sur des appareils.

Google réduit surtout leur capacité à acquérir de nouveaux utilisateurs sur les nouvelles versions d’Android.

Pour une application encore exploitée commercialement, cette différence peut être décisive.

Un développeur peut laisser une ancienne version en ligne, mais son audience potentielle se réduit progressivement à mesure que les utilisateurs changent de téléphone ou mettent Android à jour.

Google laisse une porte ouverte jusqu’au 1er novembre

Les développeurs qui ne sont pas prêts le 31 août peuvent demander une extension.

Google fixe la nouvelle échéance au 1er novembre 2026.

Les applications concernées doivent recevoir dans Play Console une notification donnant accès au formulaire correspondant.

L’extension ne constitue pas un abandon de la politique.

Elle offre deux mois supplémentaires pour migrer la cible de l’application et effectuer les tests nécessaires.

Wear OS ne doit pas encore passer à l’API 36

La date du 31 août est commune, mais le niveau exigé varie selon le type d’appareil.

Les nouvelles apps Wear OS et leurs mises à jour doivent cibler Android 15/API 35 ou une version ultérieure.

Pour qu’une app Wear existante reste visible sur les nouvelles versions du système, Android 14/API 34 constitue le seuil de conformité indiqué par Google.

La montre connectée conserve donc une génération de décalage avec l’exigence appliquée aux applications mobiles principales.

Android Automotive reste lui aussi à Android 15

Les applications destinées à Android Automotive OS doivent également cibler au moins Android 15/API 35 lorsqu’elles sont nouvelles ou mises à jour.

Pour les applications Automotive déjà publiées, le seuil de disponibilité est plus bas : Android 12L/API 32 ou supérieur.

Google prévoit par ailleurs une exception spécifique pour certaines applications ciblant le facteur de forme Automotive et regroupées au sein du même package.

Android TV et Android XR conservent l’API 34

Les exigences sont encore différentes pour la télévision et la réalité étendue.

Les nouvelles applications Android TV et Android XR doivent cibler Android 14/API 34 ou supérieur.

Android TV utilisait déjà ce seuil pour les nouvelles soumissions depuis 2025.

Pour les applications TV existantes, Android 13/API 33 suffit actuellement pour conserver la disponibilité élargie.

Pour Android XR, Google demande Android 14/API 34 aux applications existantes comme aux nouvelles soumissions.

Passer à targetSdk 36 peut réellement changer le comportement d’une application

Modifier targetSdkVersion dans un fichier de configuration ne constitue que le début de la migration.

Android utilise précisément ce paramètre pour décider quand activer certains changements de comportement susceptibles de casser une application ancienne.

Une app qui passe à l’API 36 doit donc être testée avec les règles propres à Android 16.

Google publie une liste spécifique de changements appliqués aux applications ciblant Android 16 ou une version ultérieure.

L’edge-to-edge ne peut plus être désactivé sur Android 16

Un exemple concerne l’affichage bord à bord.

Android 15 l’avait déjà imposé aux applications ciblant l’API 35, mais proposait encore un mécanisme permettant à certains développeurs de désactiver cette contrainte.

Pour une application ciblant Android 16 et fonctionnant sur Android 16, cet opt-out est désactivé.

Les développeurs doivent donc gérer correctement les insets système afin que boutons, textes et autres éléments interactifs ne se retrouvent pas sous les barres du système.

Le bouton Retour change aussi de comportement

Android 16 active par défaut les animations du Predictive Back pour les applications ciblant l’API 36.

Les applications utilisant d’anciennes méthodes pour intercepter le bouton Retour doivent migrer vers les APIs modernes ou utiliser l’opt-out temporaire encore prévu pour cette fonctionnalité.

Google indique notamment que certains anciens mécanismes comme onBackPressed ou la récupération directe de KEYCODE_BACK ne fonctionnent plus de la même manière dans ce contexte.

Une application qui modifie simplement son numéro d’API sans tester sa navigation peut donc rencontrer de vrais bugs.

Android 16 apporte aussi des changements de confidentialité et de sécurité

La nouvelle cible modifie plusieurs autres comportements.

Google renforce notamment les protections autour de certains Intents et réduit certaines possibilités d’utiliser des informations de MediaStore pour réaliser du fingerprinting.

La gestion des photos appartenant à l’application évolue également lorsque l’utilisateur accorde seulement un accès limité à sa bibliothèque.

Toutes les nouveautés d’Android 16 ne sont pas conditionnées par targetSdkVersion, mais celles qui le sont constituent précisément la raison pour laquelle Google impose régulièrement une cible plus récente.

Les applications privées d’entreprise bénéficient d’une exception

La politique ne couvre pas absolument toutes les applications distribuées par Google Play.

Google cite notamment une exception pour les applications définitivement privées, limitées aux utilisateurs d’une organisation déterminée et distribuées exclusivement en interne.

Ces cas ne sont pas traités comme une application grand public devant suivre exactement le même cycle de visibilité.

Google réduit progressivement l’intérêt de rester sur une vieille API

Pendant longtemps, cibler une ancienne version d’Android permettait à une application d’éviter certaines règles introduites dans les générations récentes du système.

Le mécanisme reste utile pour préserver la compatibilité lors d’une transition.

Mais Google Play lui impose désormais une durée de vie commerciale limitée.

Une application encore mise à jour doit rester à environ un an de la dernière grande version d’Android.

Une application abandonnée bénéficie d’un peu plus de marge, mais perd progressivement l’accès aux nouveaux utilisateurs si elle reste trop loin derrière.

Le 31 août 2026 ne rend donc pas soudainement toutes les anciennes apps incompatibles.

Il fait quelque chose de plus efficace : il rend leur vieillissement de plus en plus visible directement dans la boutique.