Android 17 : Google étend les limites mémoire, les apps trop gourmandes seront tuées

Le 19 août 2026, Blair Harmon, directeur de la gestion produit de la plateforme Android, a publié sur le blog Android Developers un texte au titre volontairement technique : « Preparing your app for broader memory limits ». Ce n’est pas un mémo interne. C’est l’alerte officielle de Google : les plafonds de mémoire par application, introduits avec Android 17 d’abord sur les Pixel, vont être repris, dans l’année qui vient, par un nombre croissant de constructeurs, sur des appareils de 4 Go à plus de 16 Go de RAM.

Si une application dépasse son budget, le système la ralentit. Si elle continue, il peut la tuer. Pour un projet d’app en France, le sujet touche le Play Store, la Play Console, les Android vitals, le calendrier de recette et le risque de désinstallation silencieuse. L’app qui disparaît en cours d’usage se vit comme un plantage, même quand la cause n’est pas une exception Java classique.

Le contexte donné par Google n’est pas cosmétique. De nouveaux appareils maintiennent, voire réduisent, leur quantité de RAM physique, alors que les utilisateurs attendent la même fluidité. Le milieu de gamme vendu en France, souvent chargé d’une surcouche constructeur, est précisément le terrain où un plafond trop serré se voit.

Ce que Google a annoncé le 19 août

Android 17 n’invente pas le sujet. Dès le 2 juin 2026, l’équipe Android Developers expliquait déjà, dans « Prioritizing Memory Efficiency », que la plateforme allait imposer des limites par application selon la RAM totale de l’appareil, pour empêcher « un mauvais élève » de casser le multitâche de tout le téléphone. Les documents de changements de comportement d’Android 17 (API 37) le confirment : ces limites s’appliquent à toutes les apps qui tournent sur Android 17, quel que soit le targetSdkVersion. Google y écrivait aussi, à l’époque, s’attendre à un impact minimal sur la grande majorité des sessions.

Le 19 août, le message change de registre. Blair Harmon ne rediscute pas le principe. Il dit que le déploiement s’élargit. Après les Pixel, un nombre croissant de fabricants va s’appuyer sur ces plafonds, sur tout le spectre des configurations, du téléphone à 4 Go jusqu’aux machines à 16 Go et plus. La phrase à retenir tient en une ligne, et Google la met en gras : si l’app dépasse ces limites, elle sera ralentie et pourra être terminée. Le moment d’auditer n’est plus « plus tard dans l’année », c’est maintenant, avant que le parc constructeur bascule.

Pourquoi maintenant. Google relie l’urgence au prix de la mémoire : de nouveaux appareils n’augmentent plus mécaniquement leur RAM, certains la maintiennent ou la baissent, pendant que les apps, elles, n’ont pas allégé leurs images, leurs WebView, leurs caches et leurs services de premier plan. Le plafond n’est pas un gadget de laboratoire. C’est une réponse à des téléphones qui n’ont plus de marge.

Le mécanisme, décrit dans le billet du 19 août et dans la documentation Android 17, est progressif. Première étape : le système pousse les pages de l’app dans la zRAM, cette RAM compressée. L’app n’est pas encore tuée, mais compresser et décompresser coûte du processeur. L’interface saccade, les animations rament, la batterie suit. Seconde étape : si la consommation continue de monter au-delà du seuil zRAM, le processus est terminé. Pour savoir si une session terrain a été touchée, on interroge ApplicationExitInfo.getDescription(). Quand le limiteur a frappé, la raison d’exit est REASON_OTHER et la description contient la chaîne « MemoryLimiter:AnonSwap ». On peut aussi déclencher un heap dump automatique avec le ProfilingManager et le trigger TRIGGER_TYPE_ANOMALY, introduit avec Android 17.

Ce qui change en pratique pour un projet d’app

La première conséquence n’est pas un nouveau bouton de rejet dans la Play Console. C’est un comportement système. Une app déjà en production, validée, notée, peut se mettre à mourir sur une partie du parc dès que le constructeur active le limiteur. Les Pixel sous Android 17 le font déjà. Le reste du catalogue arrivera au fil de l’année. En France, cela veut dire : ne plus tester uniquement sur un haut de gamme à 12 Go, et regarder ce que la Play Console dit déjà sur les classes de RAM basses.

La Play Console devient l’outil de pilotage, pas un tableau de bord qu’on ouvre après un incident. Google met en avant deux métriques Android vitals. La première, Memory Usage (anonymous RSS + swap), mesure l’empreinte vraiment « inévictable » : tas Java ou Kotlin, tas natif, piles de threads, et la part déjà basculée en swap. La seconde, Bitmap Memory Usage, isole le coût des images, souvent le plus gros poste. Les deux ne se recouvrent pas toujours : une bitmap en mémoire partagée ou en tampon graphique peut gonfler l’une sans l’autre. Il faut lire les deux.

Chaque métrique se découpe par état de processus : premier plan, services perçus par l’utilisateur (foreground service, jobs accélérés, transferts initiés par l’utilisateur), arrière-plan, et processus en cache. Un P99 élevé au premier plan se voit tout de suite (saccades, OOM). Un P99 élevé sur un service perçu est plus pernicieux : le processus est protégé, il fuit pendant des heures, et c’est le reste du téléphone qui trinque. Un processus en cache trop lourd, lui, est le premier candidat à l’éviction. Google donne un seuil de lecture utile : si le rapport entre la queue (P90 ou P99) et la médiane (P50) dépasse 3,5 fois, il faut chercher une fuite plutôt qu’un simple surplus d’assets. Un catalogue d’images trop lourd gonfle tous les percentiles à la fois. Une fuite, elle, n’explose que la queue, au fil des sessions longues.

Côté outillage, Firebase Crashlytics 20.1.0 ajoute des données de debug pour attraper les OOM et les kills du memory limiter, et les corréler aux journaux et aux paires clé-valeur. Le ProfilingManager, disponible depuis Android 15, permet de demander des heap dumps et des profils depuis le terrain ; Android 17 y ajoute les triggers TRIGGER_TYPE_OOM et TRIGGER_TYPE_ANOMALY. En local, les commandes adb am memory-limiter (ignore, manual, status) servent à simuler un plafond, par exemple 30 Mo sur un PID, pour voir comment l’app se comporte avant de la subir en production. Ces commandes n’ont d’effet que sur un appareil qui impose déjà des limites.

Les stacks cross-platform ne sont pas épargnées. Flutter, React Native ou un WebView dans une app native empilent plusieurs tas : le runtime (Dart, JavaScript), le tas natif Android, et les bitmaps décodées. Un fil d’actualité en défilement infini, une galerie, un chat avec aperçus photo, un configurateur 3D léger : ce sont les parcours que Google cite comme à tester en priorité dans les vitals. Si le choix de stack n’est pas encore tranché, le comparatif Flutter ou React Native aide à poser la question mémoire avant de figer l’architecture, pas après la première vague d’avis.

Les pièges qui transforment une app « fluide en recette » en app tuée

Le premier piège est de lire uniquement le taux de sessions sans plantage. Un kill du memory limiter n’est pas un crash Java avec stacktrace. Il arrive en REASON_OTHER. Tant qu’on ne branche pas ApplicationExitInfo, Crashlytics à jour et les vitals mémoire, on a l’impression d’une app saine et des utilisateurs qui « ferment tout seuls ». Le symptôme côté store, ce sont les commentaires « l’app se ferme », pas une alerte rouge dans le tableau des ANR.

Le deuxième piège est le téléphone de recette. Une Pixel 9 Pro ou un haut de gamme Samsung à 12 Go masque tout. Le plafond dépend de la RAM totale. Une app confortable sur le téléphone du CEO peut déjà coller au plafond sur un entrée de gamme à 4 ou 6 Go, largement représenté dans le parc français. Il faut un appareil de la classe RAM où les vitals sont les plus sales, et y forcer un limiteur avec adb, pas se rassurer sur le plus beau device de l’open space.

Le troisième piège, ce sont les images. Google le répète depuis juin : les bitmaps sont en général les plus gros objets du tas. Un JPEG de 100 Ko se décode en plusieurs mégaoctets de pixels. Charger la photo originale dans une miniature, garder des copies identiques, laisser de la transparence inutile en ARGB_8888 alors que RGB_565 suffirait pour une image opaque, coller des marges transparentes dans le fichier au lieu d’un padding : tout cela double ou triple le budget sans qu’on le voie dans le poids de l’APK. Coil (Kotlin, Compose) et Glide (Java) font le downsampling par défaut, encore faut-il s’en servir et vider le cache quand l’UI n’est plus visible.

Le quatrième piège est le service de premier plan. Une app de navigation, de sport, de livraison ou de musique en arrière-plan est d’abord protégée par son importance. Si elle fuit, le Low Memory Killer commence par tuer les autres apps en cache pour lui faire de la place. L’utilisateur ne reproche pas tout de suite « votre service GPS ». Il reproche à tout son téléphone d’être devenu lent. C’est exactement le scénario que Google veut empêcher avec des plafonds par app, y compris pour les processus privilégiés.

Le cinquième piège est R8 laissé en mode prudent. Shrinker et minify désactivés « le temps du debug », règles keep trop larges, proguard-android.txt (obsolète et bloquant) au lieu de proguard-android-optimize.txt : le code résident reste énorme, le tas aussi. Google cite le cas de la banque Monzo, qui a activé R8 à fond et annoncé jusqu’à 35 % d’ANR en moins, 30 % de cold start en mieux et 9 % de poids d’app en moins. Ce n’est pas une promesse transposable telle quelle, c’est le signal que le levier existe et qu’il se mesure.

Dernier piège, le cahier des charges muet. Si les exigences non fonctionnelles s’arrêtent à « l’app doit être fluide », personne ne budgète un audit mémoire, personne n’écrit onTrimMemory, personne ne prévoit un milieu de gamme dans le parc de tests. Mieux vaut figer, dès le cahier des charges d’application mobile, quelques critères vérifiables : R8 activé en release, lecture des vitals mémoire par classe de RAM, implémentation de TRIM_MEMORY_UI_HIDDEN et TRIM_MEMORY_BACKGROUND (les autres constantes onTrimMemory ne sont plus envoyées depuis Android 14, et sont officiellement dépréciées depuis Android 15), et un scénario de recette sur un appareil 4 à 6 Go.

Ce qu’on fait cette semaine

On n’attend pas que « tous les constructeurs » aient basculé. On ouvre la Play Console, Android vitals, Memory Usage puis Bitmap Memory Usage. On note le P50 et le P90 (ou P99) par état de processus et par classe de RAM. Un écart de queue supérieur à 3,5 fois la médiane, surtout au premier plan ou sur un service perçu, est le ticket d’entrée pour un heap dump. On identifie le process name le plus gourmand : parfois ce n’est pas l’activité principale, c’est un SDK ou un service collatéral.

Ensuite, on rejoue en local les parcours que Google liste : WebView, défilement infini d’images, création ou édition de médias. Heap dump dans Android Studio, filtre « Duplicate Bitmaps », LeakCanary (intégré à l’IDE dans les versions récentes). On implémente onTrimMemory : à TRIM_MEMORY_UI_HIDDEN on lâche caches d’images, buffers vidéo, animations lourdes ; à TRIM_MEMORY_BACKGROUND on lâche ce qui se reconstruit à bas coût, pour rester plus longtemps en cache et éviter un cold start à chaque retour.

On vérifie la version de Crashlytics (20.1.0 au minimum pour les OOM et le limiteur), on active R8 en release avec des keep rules étroites, et on teste am memory-limiter manual sur un PID avec un plafond volontairement bas. L’objectif n’est pas de viser 30 Mo en production, c’est de voir l’app se dégrader proprement au lieu de mourir sans log. Les jeux et les apps multimédia suivent en plus le guide mémoire dédié de Google, souvent via le moteur (Unity, etc.) : onTrimMemory n’arrive pas tout seul si le moteur ne le branche pas.

Côté calendrier, la fenêtre est déjà chargée côté Play : l’obligation annuelle de target API, rappelée le 15 juillet 2026, vise le 31 août 2026. Ce n’est pas le même sujet que les plafonds mémoire, mais c’est la même console, la même file de review, le même sprint. Autant traiter les deux dans la même itération plutôt que de livrer un bump de SDK qui ignore les vitals mémoire. Si l’enveloppe globale du projet doit bouger (quelques jours d’audit, un passage R8, une passe images), le guide des prix d’une application mobile aide à replacer ce coût dans le budget, avant qu’il arrive en urgence après une vague de fermetures inexpliquées.

Pour un porteur de projet qui ne lit pas les heap dumps le dimanche, la question à poser au prestataire cette semaine est simple : « Sur quelle classe de RAM nos vitals sont-ils les plus sales, et qu’est-ce qui a déjà été mesuré avec le memory limiter ? » Si la réponse est un silence ou un « ça marche sur le Pixel du bureau », on a le diagnostic.

Questions fréquentes

Est-ce que cela ne concerne que les Pixel ?

Non, et c’est précisément l’objet de l’annonce du 19 août 2026. Les limites existent depuis Android 17, d’abord sur Pixel. Google indique maintenant qu’un nombre croissant de constructeurs va les appliquer, dans l’année, sur des appareils de 4 Go à plus de 16 Go de RAM. Tester uniquement sur Pixel ne suffit plus, et attendre « la fin du déploiement constructeur » pour regarder les vitals revient à découvrir le problème dans les commentaires du Play Store.

Faut-il republier l’application tout de suite ?

Pas par magie, et pas sans mesure. Ce n’est pas une nouvelle guideline de review qu’il suffirait de cocher dans un formulaire. C’est un comportement du système d’exploitation. On republie quand l’audit le justifie : vitals mémoire hors norme, kills MemoryLimiter:AnonSwap déjà visibles, R8 encore éteint, caches d’images jamais vidés. Un build cosmétique sans heap dump ni recette sur milieu de gamme ne change rien au plafond que le téléphone imposera.

Flutter ou React Native est-il plus exposé qu’une app native ?

Pas automatiquement, mais la surface à surveiller est plus large : runtime (Dart ou JavaScript), pont natif, bitmaps décodées, parfois une WebView en plus. Un fil d’images mal recyclé ou un cache sans plafond se paie deux fois. Native n’est pas magique non plus : une app Kotlin qui charge des photos pleine résolution dans une liste a le même rendez-vous avec le limiteur. Dans les deux cas, la vérité est dans la Play Console, par classe de RAM, pas dans le discours de stack.

Quiz : avez-vous tout retenu ?

1. Que se passe-t-il quand une app dépasse le nouveau plafond mémoire d’Android 17 ?

Elle est d’abord ralentie par le système, puis tuée si elle continue de dépasser le plafond.

2. Cette limite concerne-t-elle uniquement les téléphones Pixel ?

Non. C’est justement l’annonce du 19 août : Google étend les limites mémoire d’Android 17 au-delà des Pixel, chez les autres constructeurs.

3. Quel est le premier réflexe pour un projet d’app existant ?

Mesurer la consommation mémoire réelle de l’application sur appareil, avant toute optimisation : on ne corrige que ce qu’on a mesuré.

4. Les fuites mémoire sont-elles tolérées si l’app reste fluide en recette ?

Non. Une app « fluide en recette » peut être tuée en production : la recette ne reproduit pas des heures d’usage réel qui font grossir la mémoire.

Besoin d’un avis technique sur votre projet d’application ?

Derrière ce guide, il y a des développeurs mobiles en exercice. On répond aux questions techniques, on chiffre les projets, et on dit aussi franchement quand une idée n’est pas prête.

Réserver un appel conseil gratuit

Par téléphone : 06 32 64 24 80

Cadre du projet, ensuite

Un tutoriel store ou technique ne remplace pas un cahier des charges. Quand le périmètre existe (deux stores, un back-office, un paiement), ouvrez le modèle de CDC, les fourchettes du guide des prix, et la grille de devis. Les captures annotées de nos articles suivent la même logique que l’analyse d’écrans du CDC : une source réelle, une exigence écrite, pas une moodboard.

Fourchettes HT, France : MVP 15 000 à 40 000 €, ambition moyenne 40 000 à 120 000 €, complexe 120 000 à 300 000 €. Maintenance 15 à 20 % par an. Aucune note d’avis sur les agences : le classement est Sirene, millésimé, déclaré.

Un e-mail par semaine, et rien d’autre

Chaque semaine : un tutoriel mobile, les actualités des stores, les prix constatés qui bougent, et rien à vendre. Désinscription en un clic.

Votre adresse e-mail Je m’abonne

Aucune revente d’adresse. Vos données

Par la rédaction d’Agence Application Mobile. Article publié le 20 août 2026, mis à jour le 21 août 2026.