Et si les constructeurs pouvaient mettre à jour Android sans l'adapter à chaque appareil ? C'est ce que propose Google avec son Project Treble, censé séparer le système mobile des couches bas niveau spécifiques à chaque terminal. De quoi accélérer, en théorie, l'expansion des nouvelles versions à partir d'Android O.
La promesse est presque aussi vieille qu'Android. Google a publié un billet de blog pour présenter Project Treble, une initiative pour (encore) accélérer les mises à jour d'Android. Introduit avec Android O, prévu pour cet été, le projet consiste à séparer le système Android des modifications propres à chaque appareil, pour améliorer le système sans le réadapter systématiquement aux terminaux.
Disponible depuis août 2016, Android Nougat n'est présent que sur 7,1 % des terminaux Android. La raison ? Google considère que le passage d'un appareil à chaque version majeure est « très coûteux et chronophage » pour les constructeurs. Pour remédier à cette situation, Project Treble est présenté comme la modification du fonctionnement bas niveau d'Android « la plus important jamais réalisée ». Pourtant, le système s'est déjà bien modularisé au fil des années.
Une interface pour les lier tous
Le cycle de mise à jour d'un appareil sous Android est long, de l'aveu même de Google. Pour référence, certains constructeurs promettent une transposition des nouvelles versions sous trois mois, ce qui est présenté comme un cycle rapide. Il faut dire que les étapes sont nombreuses : une fois la version open source d'Android (AOSP) diffusée, les fabricants de puces l'adaptent à leur matériel, avant de transmettre la version revue aux fabricants de terminaux.
Ceux-ci modifient cette version pour chaque terminal, notamment pour intégrer les fonctions maison. Elles les testent ensuite avec les opérateurs, ajoutant éventuellement des applications, avant de diffuser la mise à jour. Une tanée pour toute la filière, censée répéter l'opération au moins tous les ans.
Google veut donc reprendre le modèle des applications, compatibles avec l'ensemble des appareils via une base de code unique. L'idée : séparer l'implémentation du fabricant (ce qui est conçu spécifiquement pour les puces) du framework système d'Android. Pour cela, l'entreprise introduit une « interface constructeur » pour lier les deux, avec une Vendor Test Suite (VTS).
Cela doit permettre de mettre à jour le système sans toucher à l'implémentation spécifique à chaque constructeur. La partie propre à chaque objet, qui ne bouge pas, interagit avec la nouvelle version du système via « l'interface constructeur », qui s'arrange pour assurer la compatibilité avec la nouvelle version d'Android.
Un système déjà modularisé
Il ne s'agit pas du premier effort de Google en termes de modularité. Une part importante des composants étant déjà mis à jour sans changer de version du système. Les applications (propriétaires) de Google, l'écran d'accueil, la WebView système ou encore l'application SMS évoluent de leur côté, sans requérir de modification du système.
Malgré le Project Treble, il reste une épine importante dans le pied de Google : les modifications spécifiques à Android pour chaque appareil ou opérateur. Le groupe de Mountain View envisage d'intégrer ces modifications directement dans l'Android Open Source Project, travaillant sur la question avec les acteurs du marché.
En novembre, la documentation pour constructeurs faisait déjà mention d'Android Extensions. Celles-ci pourraient permettre de mettre à jour individuellement certaines briques du système, sans passer par une révision complète d'Android.
Le groupe prend l'exemple de Qualcomm et Sony qui ont intégré directement des patchs maison à l'AOSP, pour ne pas avoir à les adapter à chaque nouvelle version du système. Il publie déjà les préversions de l'OS avec plusieurs mois d'avance, pour accélérer le travail des partenaires.
Project Treble doit apparaître sur les futurs appareils, livrés sous Android O. Il est déjà en place sur les téléphones Pixel disposant de la nouvelle version du système. La documentation complète doit être publiée à la sortie de la prochaine version majeure, prévue sur l'été.
Espérons maintenant que ce projet aboutisse sur du concret, pas comme les (nombreuses) tentatives passées.
Commentaires (25)
#1
Je ne suis pas très au fait des tentatives passées, qui plus est si elles ont été nombreuses. Il s’agissait de quoi ?
#2
Si les constructeurs n’avaient pas chacun leur surcouche en carton pour leurs mobiles, l’expansion d’Android suivrait déjà plus le modèle d’Apple… (même si les disparités en terme de hardware rendent l’exercice plus difficile, ça serait déjà un bon pas)…
#3
Ah… le mythe de la fameuse “interface qui ne bouge pas”.
" />
C’est un corolaire du non moins fameux “on a pensé à tout, y aura pas besoin de modifier”.
C’est beau l’espoir.
#4
Tu peux très bien avoir une interface qui évolue sans avoir de régression
" />
" />
Bon par contre, c’est ultra chiant dès que tu veux la moderniser
#5
Clairement, les mises à jour devrait être en overhead de leurs applicatifs alakon.
Sinon, @guenaël : le sous-titre => tu sors !
Sur le slide, suis-je le seul à avoir pensé à Terrence et Philipp dans le design des “End users” ??
#6
Tout a fait.
Si l’interface immuable est trop spécifique, ca entraine des limitations dans les évolutions (genre POSIX ou FAT)
Si l’interface immuable est trop générique, ca entraine des ambiguités qui mènent à des problèmes d’interopérabilité (genre HTML/CSS).
#7
Cette fois-ci, cela concerne tous les modèles anciens comme nouveau ? Car la nouveauté de nougat ne concernait que les appareils avec 2 partitions. Sinon c’est aussi une bonne nouvelle pour les roms alternatives
#8
J’allais poser une question mais j’ai ma réponse
" />
In addition to the architectural changes, we’re working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android..
We plan to publish the full documentation for Project Treble on source.android.com with the launch of O later this summer.
\o/
#9
Sous titre en mousse.
Sinon, l’idée est évidemment bonne, mais le diable se cache dans les détails. A voir
#10
Project Treble will be coming to all new devices launched with Android O and beyond. In fact, the new Project Treble architecture is already running on the Developer Preview of O for Pixel phones
Ok cela répond à ma question. Seul les nouveaux téléphone auront cette fonctionnalité. Mais comment les pixels l’ont? L’image DP formate le téléphone est permet l’intégration de la fonctionnalité ? Ce qui confirmerai que cela ne sera pas disponible par une mise à jour vers Android O
#11
Je ne vois pas pourquoi cela ne serait pas disponible par mise à jour vers O.
Je vois mal Google gérer deux versions de Android O avec et sans Treble.
Comme toujours, le problème avec les upgrades c’est la migration des DATA (settings, comptes etc.), qui est traitée par les ROM officielles mais rarement (jamais ?) par les ROM alternatives.
Sinon rien n’empêche l’implémentation de quoique ce soit.
#12
Souhaitons que ça prenne enfin !
Avec ça, Android se rapprochera du fonctionnement d’un OS pour PC, et ça sera bon pour tout le monde. A suivre de près !
#13
#14
Ça a commencé avec Android 6.0 et les Nexus : les blobs propriétaires (drivers) sont sur une partition différente (/vendor)
Dedans on y trouve tout le code proprio de l’appareil ainsi que des overlays pour changer l’interface.
C’est bien de voir qu’ils vont”ouvrir” ça aux oem
#15
#16
#17
#18
#19
Ben ils sont bien obligés de mettre des limites, sinon les Sud-Coréen se mettent à coder…
#20
Pas de mise à jours de l’OS signifie aussi souvent pas de Patches de sécurité Google, malheureusement le minimum vital …
Si se système est limité qu’a Android O, alors une base massive de smartphones qui n’évolueront pas en ayant cette MAJ resteront encore sur le carreau de la fragmentation …
#21
Disponible depuis août 2016, Android Nougat n’est présent que sur 7,1 % des terminaux Android. La raison ? Google considère que le passage d’un appareil à chaque version majeure est « très coûteux et chronophage » pour les constructeurs.
Si ma Nexus 7 de 2012 ne tourne pas en Nougat, c’est parce que Google a arrêté d’assurer son support depuis environ 2 ans. Il n’y aurait donc pas que pour les constructeurs que c’est « très coûteux et chronophage »;
#22
Chronophage peut être, bien que ces boites aient sûrement les moyens de faire leur job correctement.
Une bonne façon de pratiquer l’obsolescence programmée, ça, c’est une certitude.
#23
Google devrait resserer les étaux comme Apple et restreindre encore plus le processus de mise à jour. Ce qui obligerait les fabricants à suivre un protocole précis. Apple maîtrise par exemple, okay y a que quelques terminaux à suivre mais c’est impeccable. Une bonne avancée est faite avec ceci. Mais tous ceux qui me bénéficierons pas ce ça, et autant dire des centaines de millions de devices resteront sur le carreau…
#24
Il a fallu attendre la 8ème version d’Android pour avoir un système de mises à jour convenable… chapeau!
#25
Ce sera probablement Android 8.0 mais il n’y a pas eu que 7 versions majeures depuis les débuts d’Android ^^