Android 17 va TUER vos apps préférées sans prévenir

Fini le temps où une seule application mal optimisée pouvait monopoliser toute la mémoire vive et faire ramer l’ensemble du téléphone. Avec Android 17, Google instaure des quotas stricts par appli pour protéger la fluidité générale. Le système commence par compresser les données excédentaires avant de passer à un arrêt forcé si le dépassement persiste. Cette approche, déjà active sur les Pixel, s’étend maintenant à davantage de constructeurs, dans un contexte où le prix de la RAM explose et où les nouveaux appareils n’en embarquent pas forcément plus.

Un mécanisme progressif qui privilégie la compression avant la coupure

Le nouveau cadre ne tue pas immédiatement une appli qui dépasse son allocation. D’abord, Android bascule une partie de ses données vers la zRAM, une zone de mémoire compressée. Cela libère de la RAM physique tout en maintenant le processus en vie, même si la compression et la décompression sollicitent le processeur et peuvent provoquer des micro-ralentissements ou des saccades à l’écran. Ce n’est que si l’application continue d’augmenter sa consommation au-delà de ce seuil que le système procède à un arrêt forcé. Les limites sont calculées en fonction de la RAM totale de l’appareil, avec des seuils plus généreux pour les processus visibles à l’écran que pour ceux en arrière-plan. Sur un téléphone de 8 Go par exemple, une appli au premier plan peut aller jusqu’à environ 5 Go, contre 3 Go en arrière-plan. Ces plafonds visent surtout les fuites mémoire et les cas extrêmes, pas les usages normaux. Les développeurs peuvent détecter ces arrêts via un code spécifique dans les infos de sortie de l’application, ce qui permet de diagnostiquer le problème après coup.

Un déploiement qui sort des pixel et des aides concrètes pour les créateurs d’applis

Lancée initialement sur les Pixel lors de la sortie d’Android 17 en juin, cette politique s’applique désormais progressivement aux téléphones d’autres marques, sur une large gamme allant de 4 Go à plus de 16 Go de RAM. Google accompagne le mouvement en fournissant de nouveaux outils de suivi et d’optimisation. Les développeurs disposent de métriques avancées dans Android Vitals, d’intégrations dans Crashlytics pour repérer les kills liés à la mémoire, et de commandes ADB pour tester différents scénarios de limites. Ils peuvent aussi activer des profils automatiques qui capturent des dumps mémoire au moment où le plafond est atteint. Cette évolution intervient alors que les prix de la mémoire vive ont fortement augmenté, poussant les fabricants à maintenir ou même réduire les capacités RAM des nouveaux modèles plutôt que de les augmenter comme avant. L’objectif affiché est de garantir une expérience fluide même sur des configurations plus contraintes, sans que tout le système ne souffre d’une seule appli vorace.

Ce que ça change vraiment au quotidien et les points à surveiller

Pour la plupart des utilisateurs, le changement passera inaperçu : les applis bien conçues resteront dans les clous et le téléphone gagnera en réactivité, surtout sur les modèles milieu de gamme ou ceux qu’on garde plusieurs années. On devrait voir moins de cas où une appli lourde (réseau social, navigateur chargé, outil photo ou IA) fait tout ramer ou force le système à tuer d’autres processus en cache. En revanche, les applications qui ont réellement besoin de beaucoup de mémoire, comme certains jeux gourmands, éditeurs d’images ou outils multimédia, risquent de ralentir ou de se fermer si leurs développeurs ne les optimisent pas rapidement. Google a volontairement fixé des limites plutôt conservatrices pour cibler les outliers, mais cela impose une discipline nouvelle. C’est une bonne nouvelle globale : ça pousse tout l’écosystème vers plus d’efficacité, un peu comme si Android passait d’un mode réactif (tuer des applis une fois le mal fait) à un mode préventif. Les geeks qui jonglent avec plusieurs applis ou qui détestent les lags y trouveront leur compte, à condition que les éditeurs jouent le jeu.