Android a depuis longtemps un problème de fragmentation. Depuis de nombreuses années, les constructeurs de smartphones prennent peu au sérieux la longévité de leurs produits, n’offrant que peu de mises à jour. L’exception se trouvait dans les modèles haut de gamme, qui pouvaient recevoir des versions majeures d’Android plus longtemps. Au-delà de ces dernières, il était surtout question des mises à jour de sécurité mensuelles, abandonnées trop vite sur de nombreux modèles d’entrée de gamme. Or, un smartphone ou une tablette sans mises à jour de sécurité représente un trop grand danger pour être encore utilisé.

La situation change progressivement. On l’a vu avec les Pixel et le haut de gamme de Samsung, des modèles commencent à être livrés avec sept ans de mises à jour mineures et majeures. Google veut inspirer le marché, d’autant que les lois s’apprêtent à se durcir, notamment en Europe.

• Mise à jour des smartphones : Apple s’engage sur cinq ans, Google se moque

Ces dernières années, Google a également beaucoup travaillé à rendre la maintenance des appareils plus simple pour les constructeurs. Une conséquence directe de la stratégie Android pratiquée jusque-là, qui donne de nombreuses libertés aux constructeurs dans le choix des composants et de l’utilisation d’Android. Plus il y a de modèles, plus il faut dépenser de ressources pour entretenir des configurations très différentes.

Une première étape avec le projet Treble

Face à ce constat, Google avait présenté le projet Treble. Il s’agissait alors de simplifier la chaine logistique allant de la disponibilité d’une mise à jour Android à son installation concrète par l’utilisateur. Et pour cause : il fallait que des fabricants de puces testent la compatibilité du nouveau code avec leurs produits, que les constructeurs de smartphones en fassent autant avec leurs appareils, voire que les opérateurs mettent leur grain de sel.

Treble a marqué une importante rupture dans ce modèle. Pour la première fois, Google séparait le système d’exploitation proprement dit de ses Play Services. Cette séparation devait permettre aux constructeurs de ne vérifier la compatibilité de code mis à jour que sur les composants strictement nécessaires du système, sans toucher à l’implémentation d’origine par le constructeur.

Ce fut un premier changement salvateur, car Google a déplacé petit à petit un nombre croissant de composants logiciels cruciaux dans ses Services. Aussi, sur les appareils ne pouvant plus prétendre aux versions annuelles d’Android, les Play Services continuaient à se mettre à jour pendant plusieurs années, limitant un peu le problème de fragmentation.

Un déplacement de la complexité

Si cela a l’air simple en apparence, la réalité est tout autre. Non seulement le projet Treble est complexe dans ses objectifs, mais il l’a aussi été dans sa mise en application. Il a fallu également que Google puisse maintenir une compatibilité ascendante pour toutes ses versions Android. Pas question en effet qu’une nouvelle mouture du système vienne réduire à néant les implémentations réalisées par les constructeurs sur la version précédente.

Toute la complexité du processus de suivi des mises à jour s’est en fait déplacée. Les constructeurs se sont surtout mis à attendre les retours des fournisseurs de composants. Ces derniers doivent en effet fournir une implémentation compatible pour chaque version d’Android en circulation sur chaque appareil. Ce qui inclut à la fois les versions majeures (quand le noyau Linux change par exemple) ou les versions intermédiaires, par exemple quand Google modifie une couche d’abstraction matérielle (HAL) pour introduire une nouveauté.

Si Treble a simplifié le processus pour les constructeurs, il l’a donc rendu plus complexe pour les fournisseurs de composants… dont dépendent les constructeurs. À moins d’être dans le cas de Google et de fournir directement ses propres composants, comme l’entreprise l’a fait en introduisant sa série Tensor. Une maitrise du matériel et du logiciel qui a valu pendant de longues années la palme de la longévité aux iPhone, maintenus pendant au moins cinq ans pour les versions majeures d’iOS, ainsi qu’une année supplémentaire pour les correctifs de sécurité. Apple s'est depuis fait voler la vedette.

Google Requirements Freeze, la deuxième moitié du puzzle

Google s’est rapidement aperçue du problème. L’entreprise a donc introduit fin 2020 un autre projet. Baptisé Google Requirements Freeze (GRF), il a étendu les grands principes de Treble aux SoC des appareils mobiles. GRF a introduit un très gros changement dans Android : les changements opérés dans le noyau Linux et/ou les couches d’abstraction matérielle ne peuvent plus être répercutés sur d'anciennes implémentations. Il n’y a plus de rétroactivité, alors qu’elle était obligatoire avec Treble.

Voici un exemple, pour mieux comprendre. Un fournisseur de composant propose un nouveau SoC prenant en charge Android 12. Avec GRF, l’implémentation réalisée par le fournisseur est garantie jusqu’à N+3, donc Android 15. Dans cet intervalle, toutes les mises à jour Android proposées, même les plus importantes dans les versions majeures, peuvent se faire en réutilisant l’implémentation initiale faite pour Android 12. D’où le nom de « Freeze », Google gelant littéralement ses exigences.

Le programme GRF a permis de simplifier le passage à trois ans de mises à jour d’Android, puis autant de correctifs de sécurité seuls. Il était possible d’étendre le support à sept ans, mais à la condition de payer le fournisseur de SoC pour un travail supplémentaire de prise en charge. C’est ce qu’explique Android Authority, donnant l’exemple de Samsung avec sa ligne Galaxy S24 lancée en début d’année.

Un director’s cut de GRF

Désormais, il faut parler de Longevity GRF. Une version longue du programme initial qui propose directement sept années de mises à jour. Plus spécifiquement, il autorise la réutilisation du logiciel d’un SoC pour sept évolutions majeures d’Android, au lieu des trois actuelles. Un changement majeur, car cela permet à un smartphone lancé sous Android 15 de pouvoir être mis à jour jusqu’à Android 22.

Il ne s’agit donc plus d’exceptions comme les Pixel 8/9 ou encore les Samsung Galaxy S24, mais d’une règle commune, applicable par l’ensemble des constructeurs. Il y a cependant une condition importante : il faut que la société proposant le SoC accompagne ce dernier de cette « garantie ». Or, à l’heure actuelle, seul le Snapdragon 8 Elite, présenté la semaine dernière par Qualcomm, est compatible. En théorie, tout appareil qui en sera équipé pourra recevoir les précieuses nouvelles versions d’Android.

• Snapdragon 8 Elite : le premier SoC Qualcomm pour smartphones avec des cœurs CPU Oryon

Une condition, une limite et un problème

Si ce gel prolongé est un énorme progrès en matière de longévité des appareils, il y a cependant une grosse condition à respecter : mettre à jour la version du noyau Linux après trois ans, car les versions fournies par Android ne sont supportées que quatre ans. Le décompte commence à partir de la version 6.6 fournie avec Android 15. Si les constructeurs ne le font pas, ils devront s’occuper eux-mêmes de porter les modifications de sécurité sur l’ancienne version utilisée par leurs appareils.

Il y a une autre limitation : Google interdit qu’une implémentation pour un SoC soit utilisée au-delà de sa quatrième année pour équiper un nouvel appareil avec le dernier Android. En 2028, par exemple, il ne sera pas possible d’utiliser l’implémentation actuelle du Snapdragon 8 faite pour Android 15 dans un nouvel appareil conçu autour d’Android 19. Ceci pour éviter que l’ancienne implémentation ne soit pas sans cesse reprise par un constructeur. Sur Android Authority, Mishael Rahman a résumé les informations dans le tableau suivant :

Cette longévité simplifiée, qui demandera tout de même quelques travaux, surtout en milieu de cycle de vie, s’accompagne également d’un problème. Les constructeurs vont en effet pouvoir proposer des mises à jour sur 7 à 8 ans, sans plus devoir payer de support allongé aux fournisseurs de SoC. Cependant, cela se fait au détriment d’un gel des couches d’abstraction matérielle. Si Google introduit des nouveautés ayant besoin d’une telle modification, elles ne seront répercutées qu’au bon vouloir des fournisseurs de composants et des constructeurs. Par exemple, Android 13 a ajouté une API permettant de modifier la luminosité de la fonction lampe de torche.

Rahman ajoute que ces informations ne sont pas publiques, qu’elles lui ont été communiquées par une source anonyme et que certains détails pourraient donc lui avoir échappé. Cependant, elles sont en phase avec les mouvements de l’industrie observés depuis l’automne 2023, jusqu’à la présentation du Snapdragon 8 Elite. La longévité des appareils devrait donc bien devenir un argument de vente, mais il n’est pas certain qu’il le soit pour toutes les gammes. D’autant que seul le dernier fleuron de Qualcomm est pour l’instant compatible. Mais cette permissivité semble bien être l'aboutissement des objectifs fixés par Treble il y a six ans.