Google Play ajoute deux nouvelles catégories à ses exigences de qualité technique.

La première concerne directement la quantité de mémoire consommée par une application et entrera en application en février 2027.

La seconde impose une restauration automatique de la connexion lors du passage à un nouveau téléphone Android à partir d’avril 2027.

Google a annoncé les deux mesures le 26 août, en laissant plusieurs mois aux développeurs pour adapter leurs applications.

Google Play va regarder combien de RAM une app utilise réellement

La nouvelle mesure principale s’appelle Memory usage, ou Anonymous RSS + Swap.

Elle représente essentiellement la mémoire privée utilisée par l’application, qu’elle soit active en RAM ou compressée et placée dans le swap ou la zRAM.

Les fichiers présents sur le stockage, comme le code ou les ressources qui ne sont pas chargées en mémoire privée, ne sont pas comptés de la même manière.

Google évaluera cette consommation selon plusieurs états : application au premier plan, service perceptible par l’utilisateur, arrière-plan et cache.

Le seuil dépend également de la quantité de RAM physique disponible sur le terminal.

Une app sur un téléphone de 4 Go ne devra pas dépasser 2 Go au premier plan

Google a déjà publié des valeurs précises.

Pour les applications classiques sur un appareil appartenant au niveau 4 Go de RAM, le seuil au 90e percentile est de 2 Go lorsque l’app se trouve au premier plan.

Pour les services perceptibles par l’utilisateur et les tâches en arrière-plan, il tombe à 1 Go.

Sur un appareil de catégorie 6 Go, Google autorise 2,25 Go au premier plan et 1,25 Go en arrière-plan.

Sur 8 Go, les valeurs publiées sont 2,25 Go et 1,5 Go.

À 12 Go, elles passent à 3,25 Go au premier plan et 1,75 Go en arrière-plan.

Et sur les appareils de catégorie 16 Go, une application peut atteindre 4,25 Go au premier plan, mais seulement 2 Go pour un service ou une tâche en arrière-plan.

Les appareils contenant moins d’environ 3,2 Go ou plus de 18 Go ne disposent pas encore de seuils chiffrés dans le tableau publié.

Le 90e percentile évite de sanctionner une pointe isolée

Google ne jugera pas une application sur le pire instant observé sur un seul téléphone.

Les nouvelles métriques de Google Play utilisent une fenêtre de 28 jours, comme les autres Android vitals.

L’évaluation se fait au 90e percentile.

Cela signifie qu’un développeur doit surtout éviter qu’une part importante des sessions présente durablement une consommation trop élevée, plutôt que supprimer chaque pic exceptionnel.

Les données seront consultables dans Android vitals et via l’API Google Play Developer Reporting.

Les bitmaps deviennent une métrique séparée

Google isole aussi la mémoire consommée par les images bitmap.

Qu’une application conserve des images lourdes en mémoire lorsqu’elles sont visibles peut être normal.

Le problème apparaît lorsqu’elle continue à garder ces mêmes bitmaps longtemps après être passée en arrière-plan ou dans l’état cached.

Google veut donc mesurer séparément cette consommation afin d’identifier les applications qui gardent des ressources graphiques inutilement.

Le Play Console doit signaler les bitmaps non optimisés afin d’aider les développeurs à retrouver ces cas.

Google veut aussi forcer davantage d’optimisation du code

La RAM n’est pas le seul critère.

Les Android App Bundles publiés sur Google Play devront atteindre au minimum 25 % de couverture dans trois catégories : optimisation, shrinking et obfuscation du code DEX.

R8 est l’outil mis en avant par Google, mais un autre shrinker peut être utilisé.

Le shrinking supprime notamment du code et des ressources inutilisés, tandis que l’optimisation réécrit certaines parties afin de réduire le coût à l’exécution.

Google affirme qu’un bundle mieux optimisé utilise moins de mémoire, démarre plus rapidement, réduit les ANR et améliore le rendu et les performances générales.

Une mauvaise note pourra réduire la visibilité sur le Play Store

À partir de février, dépasser les seuils ne sera plus seulement une information affichée au développeur.

Google indique que les apps et jeux non conformes pourront subir une réduction de visibilité et de capacités de publication sur Google Play.

Les conséquences exactes seront détaillées plus tard dans l’année.

La formulation laisse donc encore une marge sur la manière dont une violation sera appliquée : baisse de distribution, restrictions lors d’une mise à jour ou autres mécanismes.

Ce qui est déjà clair est que la consommation mémoire rejoint les crashs et ANR parmi les signaux de qualité qui peuvent avoir un impact commercial sur une application.

Play Console va montrer où l’application gonfle

Google a commencé à déployer de nouveaux outils avant l’entrée en vigueur des sanctions.

Android vitals affiche désormais la mémoire dynamique et les bitmaps selon différents percentiles et catégories de RAM.

Un nouveau filtre permet également de repérer les crashs provoqués lorsque le système ferme une application à cause d’une pression mémoire trop forte.

Pour chaque nouveau bundle envoyé sur Play Console, Google affiche en parallèle des informations sur l’optimisation DEX lorsque l’outil de compilation fournit les métadonnées nécessaires.

Des alertes doivent prévenir lorsqu’une application dépasse les seuils, utilise des bitmaps mal optimisés ou présente trop peu de shrinking et d’optimisation.

Ce durcissement arrive parce que la quantité de RAM ne progresse plus forcément

Google donne une raison inhabituelle et très matérielle à cette nouvelle politique.

L’industrie traverse selon lui des contraintes d’approvisionnement et des hausses de prix de la mémoire.

De nouveaux appareils conservent donc parfois la même quantité de RAM que leurs prédécesseurs, voire en embarquent moins.

Dans le même temps, les applications continuent à s’alourdir.

Le résultat potentiel est évident : plusieurs apps gourmandes peuvent ralentir l’ensemble du téléphone même lorsque chacune semble fonctionner correctement prise isolément.

Android 17 limite déjà directement certaines applications

Google Play n’agit pas seul.

Android 17 a introduit des limites mémoire par application, initialement sur les Pixel.

Google prévoit leur adoption sur davantage de smartphones et de catégories de RAM au cours de l’année suivante.

Si une application dépasse ces limites système, Android peut d’abord réduire ses performances puis finir par la fermer.

Le Play Store ajoute donc un mécanisme de pression en amont : identifier et pénaliser les applications qui risquent régulièrement d’atteindre le point où Android doit lui-même intervenir.

En avril, une autre exigence concernera tous les utilisateurs qui changent de téléphone

Le deuxième volet de l’annonce n’a presque aucun rapport avec la RAM.

À partir d’avril 2027, une application disposant d’un système de connexion utilisateur devra prendre en charge le nouveau standard Zero-Tap Sign-In.

Cette obligation vaut que la connexion soit indispensable ou seulement facultative.

Lorsqu’un utilisateur restaure ses applications sur un nouveau téléphone, l’app devra pouvoir retrouver son état d’authentification dès le premier lancement.

L’objectif de Google est qu’elle puisse afficher directement quelque chose comme « Bon retour, Alex » plutôt qu’un écran réclamant adresse e-mail, mot de passe et plusieurs étapes de récupération.

Restore Credentials transporte l’identité pendant la migration

La mécanique repose principalement sur l’Android Restore Credentials API.

Lorsqu’une session est créée sur l’ancien appareil, l’application peut générer un credential de restauration lié au compte.

Ce credential est transféré avec les données de migration appareil-vers-appareil ou via la sauvegarde cloud.

Au premier lancement sur le nouveau smartphone, l’application récupère ce contexte et restaure la session sans interaction supplémentaire.

Google considère qu’une migration directe entre deux appareils fournit une preuve de possession suffisamment forte pour que l’application ne réclame normalement pas une nouvelle étape MFA uniquement à cause du transfert.

Google présente aussi cette mesure comme une protection anti-phishing

Le bénéfice n’est pas uniquement ergonomique.

Google affirme que demander à des utilisateurs de ressaisir leurs identifiants pendant la configuration d’un nouveau téléphone augmente l’exposition au phishing et au vol de credentials.

Restaurer un contexte d’identité déjà établi évite de demander à l’utilisateur de retrouver ou retaper un mot de passe au moment où il installe potentiellement des dizaines d’applications.

Pour les services disposant d’authentifications complexes, cette automatisation devra néanmoins être implémentée sans affaiblir les protections liées aux actions réellement sensibles.

Les jeux obtiennent pour l’instant une exemption

Google ne leur appliquera pas l’obligation Zero-Tap en avril 2027.

La société explique que les jeux présentent des scénarios d’authentification plus complexes et promet des solutions spécifiques dans le courant de 2027.

Elle recommande malgré tout aux jeux utilisant un compte unique d’adopter Restore Credentials dès maintenant.

L’exemption concerne uniquement le transfert de connexion.

Les jeux restent soumis aux nouvelles exigences de mémoire et d’optimisation prévues pour février.

Block Store bénéficie d’une clause transitoire très précise

Certaines applications utilisaient déjà Block Store pour restaurer des données de connexion.

Google acceptera cette implémentation comme conforme si elle était déployée en production au plus tard le 30 septembre 2026 et si elle restaure correctement l’état de connexion.

Les nouvelles intégrations réalisées après cette date ne pourront pas utiliser cette exception et devront suivre le nouveau standard.

C’est une manière d’éviter de forcer les applications déjà équipées d’une solution fonctionnelle à réécrire immédiatement leur mécanisme tout en convergeant progressivement vers Restore Credentials.

Google Play devient de plus en plus un outil de contrôle de la qualité d’Android

Le changement dépasse finalement deux nouvelles règles isolées.

Google utilisait déjà le Play Store pour imposer des versions minimales d’API, le support 64 bits, les tailles de page mémoire de 16 Ko et des seuils sur les crashs ou les ANR.

La RAM et la migration de compte rejoignent maintenant ce système.

Une application peut donc être techniquement compatible avec Android et fonctionner lorsqu’elle est installée manuellement, tout en devenant moins visible ou plus difficile à publier sur Google Play si elle ne respecte pas les critères de qualité fixés par la boutique.

À partir de 2027, le développeur Android devra ainsi optimiser non seulement pour que son application fonctionne, mais aussi pour que Google considère qu’elle utilise correctement le téléphone — et qu’elle sache reconnaître son propriétaire lorsque celui-ci en achète un nouveau.