Android 17 : gros virage pour tablettes, perf et sécurité

Android 17 a une date, 13 février 2026, et Google ne fait pas semblant. La bêta 1 est déjà disponible, la bêta 3 a atteint la Platform Stability et l’API est verrouillée, ce qui met les développeurs face à une réalité simple, il faut tester maintenant. Sur le papier, la liste des nouveautés paraît moins “waouh” que certaines éditions, mais le cur de la mise à jour vise des problèmes concrets, performances, compatibilité et grand écran.

Deux changements dominent l’actualité. D’un côté, une garbage collection générationnelle dans ART pour réduire le coût CPU des nettoyages mémoire, avec un bénéfice attendu sur les saccades et les micro-freezes. De l’autre, une règle plus stricte sur les grands écrans, adaptivité obligatoire dès qu’on dépasse 600 dp, avec des attributs manifest qui ne pourront plus servir de bouclier. Et oui, ça va piquer pour certaines applis.

Google fixe Android 17 au 13 février 2026

La feuille de route est claire, la sortie d’Android 17 est annoncée pour le 13 février 2026. Dans les notes de version, Google associe cette première bêta à un niveau de correctif de sécurité daté 2026-01-05, et à une version de services Google Play indiquée 25.47.33. Ce genre de détails, ça n’intéresse pas que les technophiles, ça donne aussi une idée du socle logiciel sur lequel les tests se font.

Le rythme, lui, est typique d’un cycle moderne, une bêta 1 utilisable pour du développement et des essais “du quotidien”, mais avec une mise en garde, le système reste en chantier, donc des bugs peuvent casser des usages. Si tu installes, tu le fais en connaissance de cause, surtout si ton téléphone sert au boulot. Marc, développeur Android en agence, résume, “je teste sur un Pixel secondaire, pas sur mon appareil principal, sinon je perds une demi-journée dès qu’un truc casse”.

Point important pour l’écosystème, la bêta 3 de mars 2026 marque la stabilité de la plateforme. Concrètement, l’API ne bouge plus, le comportement final se fige, et Google dit aux éditeurs d’apps de lancer les tests de compatibilité finaux, puis de publier des versions ciblant Android 17 sur le Play Store. Pour les SDK et bibliothèques, le message est encore plus direct, si tu traînes, tu bloques les autres.

Ce calendrier a un effet domino. Les équipes QA et les responsables produit doivent caler des campagnes de tests sur plusieurs formats, téléphone, tablette, pliable. Et avec une règle grand écran plus stricte, tu peux te retrouver à corriger des écrans entiers, pas juste une poignée de bugs. C’est là que la promesse de “moins de nouveautés visibles” peut être trompeuse, parce que les changements structurels coûtent cher en temps, même quand l’utilisateur final ne voit qu’un résultat, une appli qui s’affiche enfin correctement.

ART adopte une garbage collection générationnelle pour réduire le coût CPU

La nouveauté performance la plus commentée tient en trois mots, generational garbage collection. Android 17 l’introduit dans le collecteur Concurrent Mark-Compact d’ART. L’idée est classique dans le monde des runtimes, séparer les objets jeunes, souvent éphémères, des objets plus anciens, pour faire des collectes plus fréquentes mais plus légères sur la “jeune génération”, tout en gardant des collectes complètes quand c’est nécessaire.

Ce que Google vise est très concret, réduire le coût CPU et la durée des phases de nettoyage mémoire. Dans la vraie vie, ça se traduit par moins de micro-coupures lors d’un scroll lourd, moins de latence quand une appli enchaîne des allocations, et potentiellement moins de drops d’input dans des scénarios où le système est sous pression. Un exemple simple, une appli de réseau social qui charge des images en continu, si la mémoire se fragmente et que le GC fait une pause coûteuse, tu le sens immédiatement.

Le point qui change la donne, c’est la diffusion. Les améliorations ART ne sont pas confinées à Android 17, Google précise qu’elles peuvent arriver sur plus d’un milliard d’appareils sous Android 12 et plus, via les mises à jour système distribuées par Google Play. Donc même si tu n’installes pas Android 17, tu peux bénéficier d’une partie de l’optimisation, à condition que ton appareil reçoive ces composants.

Il faut quand même garder une nuance, “moins de coût CPU” ne veut pas dire “magie”. Si une appli fuit de la mémoire, si elle fait des allocations inutiles, ou si elle abuse d’objets temporaires, la collecte générationnelle limite la casse, mais ne remplace pas un profilage sérieux. Marc, côté dev, le dit sans détour, “ça aide, mais si ton code est sale, tu vas juste planter un peu plus tard”. Pour les utilisateurs, l’effet sera surtout visible sur les appareils milieu de gamme, là où chaque pic CPU se paie en fluidité.

Android 17 impose l’adaptivité grand écran dès 600 dp

Le changement qui fâche certains studios est net, pour les applis qui ciblent Android 17 et tournent sur des grands écrans à partir de sw 600dp, il n’est plus possible de refuser le redimensionnement ou les changements d’orientation. Google parle de Mandatory Large Screen Adaptivity, et ça veut dire qu’une série d’attributs manifest sont ignorés sur ces appareils, dont screenOrientation, resizeableActivity, minAspectRatio et maxAspectRatio.

Si tu as déjà vu une appli “téléphone” étirée sur tablette, avec des bandes noires, des boutons perdus, ou un écran figé en portrait alors que tu as un clavier, tu vois l’objectif. Les tablettes et les pliables sont redevenus stratégiques, et Google veut arrêter l’expérience bancale. Exemple concret, une app de gestion de notes qui refusait le paysage, sur une tablette avec clavier, c’est une aberration, tu payes un grand écran pour travailler moins bien.

Il y a des exemptions, et elles comptent. Les appareils plus petits que 600 dp ne sont pas concernés, et les applis catégorisées en Games via android: appCategory peuvent échapper à la règle. C’est logique, beaucoup de jeux verrouillent orientation et ratio pour des raisons de gameplay et de performance. Mais pour les autres, ça pousse à adopter des layouts réactifs, des fragments, des grilles, des panneaux latéraux, bref, à faire un vrai travail d’UX.

La critique, c’est que Google impose une contrainte sans fournir une baguette magique. Les petites équipes vont devoir investir, et certaines applis “utilitaires” risquent de livrer une adaptivité minimale, juste pour passer, sans vraie optimisation. Néanmoins, sur le long terme, ça peut assainir l’écosystème, parce que les fabricants de tablettes Android traînent ce problème depuis des années, “trop d’applis sont des applis téléphone agrandies”. Là, Google met une règle, et le marché s’adapte, ou disparaît des usages grands écrans.

Google change la recréation d’Activity pour limiter les pertes d’état

Autre évolution moins visible mais très sensible, Android 17 modifie le comportement par défaut de la recréation des Activity lors de certains changements de configuration. Jusqu’ici, des événements comme un changement de clavier, de navigation, de mode UI, de type d’écran tactile, ou de mode couleur pouvaient déclencher un restart automatique, avec à la clé des pertes d’état, des interruptions vidéo, ou des saisies perdues.

À partir d’Android 17, pour une liste précise de configurations, le système ne redémarre plus l’Activity par défaut. À la place, l’Activity reçoit l’événement via onConfigurationChanged. Google cite explicitement CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE quand seul UI_MODE_TYPE_DESK change, CONFIG_TOUCHSCREEN et CONFIG_COLOR_MODE. Dit autrement, moins de resets, plus de continuité, surtout quand tu branches des périphériques.

Prends un scénario banal, tu regardes une vidéo, tu connectes un clavier Bluetooth, ou tu passes en mode “bureau” sur un appareil compatible, si l’app se relance, tu perds parfois la lecture ou la position. Google veut réduire ces “state loss” qui donnent l’impression que le système est fragile. Pour les applis de productivité, c’est pareil, un champ de formulaire qui se vide parce que le clavier change, c’est le genre de bug qui fait désinstaller.

Mais il y a un revers, si ton appli comptait sur un restart complet pour recharger des ressources, il faut maintenant s’adapter. Google prévoit un opt-in via un nouvel attribut manifest, android: recreateOnConfigChanges, pour forcer la recréation quand tu en as besoin. Ça met la responsabilité côté développeur, et ça va révéler les applis qui n’ont jamais vraiment géré onConfigurationChanged proprement. Marc prévient, “les vieux projets vont souffrir, parce que personne n’a envie de toucher à ces couches”.

Desktop Mode, Live Updates et Factory Reset Protection se renforcent

Android 17 arrive aussi avec des fonctions orientées usage, surtout pour l’écosystème Pixel selon les informations disponibles. Le Desktop Mode est cité avec une barre des tâches et une barre d’état, plus des raccourcis clavier personnalisables. L’objectif est évident, rendre l’expérience plus proche d’un environnement de bureau quand tu branches un écran, un clavier et une souris, et arrêter le mode “grand téléphone” qui ne tient pas la route pour bosser.

Dans le même esprit, Android 17 met en avant de meilleures prises en charge des souris et touchpads, avec des gestes à trois doigts, des “action corners” façon coins actifs, des améliorations d’autoclick, une accélération plus fine, et un curseur universel. Ce sont des détails, mais cumulés, ça change l’usage. Exemple, sur tablette, un curseur cohérent et une accélération bien réglée, ça fait la différence entre “je dépanne” et “je travaille deux heures”.

Autre nouveauté attendue, les Live Updates, capables d’afficher des mises à jour liées à des événements en temps réel, comme l’arrivée d’un VTC ou une livraison de repas. C’est un terrain délicat, parce que ça peut vite devenir du bruit dans l’interface si chaque service pousse ses infos. Mais bien utilisé, c’est utile, tu n’ouvres pas l’app toutes les trois minutes. Les éditeurs vont devoir arbitrer, fréquence, priorité, et respect de l’attention.

Côté sécurité, Google annonce des améliorations de la Factory Reset Protection, avec une restriction de fonctionnalité sur les téléphones et tablettes réinitialisés sans autorisation du propriétaire. C’est une réponse directe au vol et à la revente, et ça s’inscrit dans une tendance du secteur, rendre l’appareil moins intéressant à écouler. La nuance, c’est l’équilibre, il faut éviter de piéger un utilisateur légitime qui a perdu ses identifiants, sinon le support client devient un cauchemar, et la confiance en prend un coup.