Google Play durcit ses règles Android pour 2027

Google Play va relever le niveau d’exigence technique pour les applications Android distribuées sur sa boutique. À partir de février 2027, les applications et les jeux seront évalués selon de nouveaux seuils de « mauvais comportement » portant sur la mémoire dynamique, la mémoire des bitmaps et l’optimisation du code DEX. Les applications qui dépassent durablement ces limites ne seront pas automatiquement supprimées, mais elles pourront perdre en visibilité et voir leurs possibilités de publication réduites.

Une deuxième échéance arrivera en avril 2027 : les applications proposant une connexion devront prendre en charge Zero-Tap Sign-In lors du transfert vers un nouvel appareil, grâce au système Android Restore Credentials. Les jeux ne sont, à ce stade, pas concernés par cette obligation de migration. 17

Trois indicateurs de performance surveillés par Google

La nouvelle politique cible des problèmes susceptibles de ralentir une application, de provoquer des plantages ou de rendre sa distribution moins efficace.

1. La mémoire dynamique

Google mesurera l’anonymous resident-set size, ou RSS, ainsi que la mémoire utilisée par le swap compressé. L’objectif est de mesurer la mémoire privée consommée par l’application pendant son fonctionnement, sans considérer automatiquement comme mémoire applicative chaque fichier de code ou de ressources stocké sur l’appareil.

Pour les jeux, les seuils de mémoire dynamique au premier plan varieront selon la quantité de RAM du téléphone ou de la tablette. La fourchette annoncée va de 2,25 Go sur les appareils dotés de 4 Go de RAM à 5 Go sur ceux qui disposent de 16 Go de RAM. Google Play prévoit donc une évaluation par catégories de capacité matérielle, plutôt qu’une limite unique appliquée à tous les appareils.

2. La mémoire des bitmaps

L’utilisation des bitmaps — les images et ressources visuelles conservées en mémoire — sera mesurée dans trois situations : au premier plan, en arrière-plan et lorsqu’une application est mise en cache.

Les seuils annoncés sont les suivants :

• 200 Mo lorsque l’application est au premier plan ou en arrière-plan ;
• 400 Mo lorsqu’elle se trouve dans le cache.

Cette règle vise notamment à éviter que des ressources graphiques restent inutilement en mémoire alors qu’elles ne sont plus visibles ou nécessaires immédiatement.

3. L’optimisation du code DEX

Les jeux dont le code DEX dépasse 50 Mo devront atteindre au moins 25 % de couverture de l’App Bundle grâce à l’optimisation, à la réduction et à l’obfuscation du code. Les développeurs pourront s’appuyer sur R8 ou sur un autre outil de réduction afin de supprimer le code superflu et d’améliorer l’efficacité du paquet distribué.

Une mesure calculée sur la durée, pas sur une seule session

Google Play ne devrait pas sanctionner une application sur la base d’une unique session particulièrement mauvaise. Les seuils seront calculés au 90e percentile, ou P90, à partir de données recueillies sur une période glissante de 28 jours. En clair, la politique cherche à repérer les problèmes persistants dans les conditions réelles d’utilisation, plutôt qu’un simple pic isolé.

Les applications qui ne respecteront pas les exigences pourront subir une baisse de visibilité et des restrictions sur leurs capacités de publication dans Google Play. Cela ne correspond pas à l’annonce d’une interdiction ou d’un retrait automatique pour chaque application dépassant un seuil.

Google déploiera également dans la Play Console des outils de suivi et de diagnostic permettant aux développeurs d’examiner les indicateurs liés à la mémoire dynamique et aux bitmaps avant le début de l’application des règles.

Les seuils pourraient par ailleurs évoluer à mesure que Google recueillera davantage de données et affinera ses comparaisons entre catégories d’appareils et types d’applications. Les développeurs ont donc intérêt à les considérer comme une base de surveillance continue, et non comme une certification à obtenir une seule fois.

Zero-Tap Sign-In : la connexion restaurée lors du changement de téléphone

La deuxième évolution concerne un autre moment souvent fastidieux de l’expérience Android : la migration vers un nouvel appareil. À partir d’avril 2027, les applications dotées d’un système de connexion devront prendre en charge Zero-Tap Sign-In afin de restaurer automatiquement l’état de connexion de l’utilisateur lors du transfert entre appareils Android, via l’API Restore Credentials.

Cette fonction s’appuie sur Credential Manager. Elle est conçue pour reconnecter discrètement l’utilisateur lorsque l’application est restaurée sur son nouvel appareil, sans modifier nécessairement le parcours de connexion existant. Elle peut fonctionner avec différents modes d’authentification, notamment les mots de passe, les clés d’accès — ou passkeys — et la connexion fédérée. 1719

L’objectif est de supprimer la corvée consistant à se reconnecter manuellement à chaque application après un changement de téléphone. Les jeux sont actuellement exclus de cette obligation, même si cette exemption pourrait évoluer avec la mise en place de la politique.

Quel rapport avec Android 17 ?

Les règles de Google Play complètent les contrôles de mémoire introduits par Android 17, sans les remplacer. Le système d’exploitation met en place des limites par application calculées selon la quantité totale de RAM de l’appareil, d’abord sur les appareils Pixel. Google indique que davantage de fabricants devraient adopter ces limites sur des appareils allant de 4 Go à plus de 16 Go de RAM.

Lorsqu’une application dépasse la limite fixée par Android 17, le système peut la ralentir et, à terme, interrompre son processus. Les règles de Google Play interviennent plus tôt, au niveau de la distribution : elles incitent les développeurs à réduire la consommation excessive de mémoire et à optimiser leur code avant que l’utilisateur ne rencontre les protections du système en situation réelle.

La distinction est importante : Android 17 contrôle le comportement d’une application pendant son exécution sur un appareil donné ; Google Play contrôle sa visibilité et ses possibilités de publication dans la boutique.

Les articles reliant cette évolution à une mémoire vive plus coûteuse ou aux besoins des centres de données dédiés à l’IA fournissent un contexte de marché, mais ne constituent pas, dans les éléments disponibles ici, la justification technique officielle détaillée de Google. De même, les informations évoquant une éventuelle réduction de la RAM de certains futurs modèles Pixel restent des rapports et non des spécifications confirmées.

Ce que les développeurs Android doivent préparer

Les équipes qui gèrent de grosses applications ou des jeux devraient commencer par :

1. Auditer la RSS anonyme et l’utilisation du swap compressé pendant les sessions au premier plan et en arrière-plan.
2. Suivre séparément la mémoire consacrée aux bitmaps, y compris lorsque l’application est conservée en cache.
3. Vérifier la taille du code DEX et mesurer la couverture de l’App Bundle après réduction, optimisation et obfuscation.
4. Tester l’application sur plusieurs catégories d’appareils et de mémoire vive, plutôt que sur les seuls modèles haut de gamme.
5. Surveiller les futurs diagnostics de la Play Console et les indicateurs Android vitals.
6. Examiner le parcours d’authentification et planifier la prise en charge de Restore Credentials avant avril 2027.

Le message de Google est clair : l’efficacité mémoire et l’optimisation du code ne relèvent plus seulement des bonnes pratiques de performance. Elles deviennent aussi des critères de distribution. Une application pourra continuer à fonctionner malgré des dépassements, mais elle s’exposera à une visibilité moindre dans Google Play, à des restrictions de publication et à une intervention plus fréquente des mécanismes de contrôle mémoire d’Android.