Tensor est-il à blâmer pour les problèmes logiciels et les mises à jour retardées du Pixel 6 ?
Le Pixel 6 de Google est un triomphe, livrant le premier chipset interne de l’entreprise. Mais il prend également du retard, avec de multiples mises à jour sautées ou retardées, une retirée, et des bêtas pour Android 12L manquant entièrement. Ce n’est pas seulement une question de bugs – bien que nous ayons gardé une trace. En fouillant dans les pilotes et les détails, en parlant aux développeurs, il n’y a pas de pistolet fumant. Mais tous les signes indiquent que la plus grande force du Pixel 6 est aussi son plus grand problème : Tensor.
Le Pixel 6 marque la première fois que Google a choisi de ne pas utiliser le matériel Qualcomm dans ses téléphones Pixel. Ici, au pays d’Android, Qualcomm est à peu près en situation de monopole dans l’espace des smartphones phares (bien que cela puisse commencer à changer), et chaque Pixel à ce jour a utilisé les puces de la société, tout comme tous ses téléphones Nexus précédents depuis le Galaxy Nexus. Avec l’essor de la 5G, cependant, nous avons entendu que les prix de Qualcomm augmentent, et cette décision auparavant facile à prendre s’avère maintenant plus difficile à justifier – bien que je soupçonne que les plans de Google pour déployer son propre chipset remontent à plus loin que cela.
La puce dans les Pixel 6 et 6 Pro porte le nom de « Tensor », et Google l’a conçue en collaboration avec Samsung. Compte tenu de tout ce qu’elle semble partager avec les produits Exynos existants de Samsung, il serait plus juste de dire que Google a eu une certaine contribution, ajoutant quelques unités de traitement personnalisées (pour les charges de travail d’IA et les photos) sur ce qui semblait être un design de référence et un modem Exynos – « semi-custom », comme le dit Anandtech. Et l’implication de Samsung pourrait avoir un impact.
Les difficultés des puces de Samsung
Les conceptions de cœurs de processeurs personnalisés sont un sujet brûlant, et à un moment donné, elles étaient liées à de « meilleurs » produits, mais aujourd’hui, même les puces Kryo de Qualcomm ne sont que des conceptions de référence ARM légèrement modifiées. (Qualcomm les marque toujours avec des noms personnalisés, mais lorsque j’ai discuté avec des ingénieurs en matériel lors du récent Snapdragon Summit, les seuls numéros de modèles qui sortaient des bouches étaient des cœurs de référence ARM). Samsung System LSI, la division de l’entreprise derrière les efforts de Samsung en matière de silicium, a essayé de s’attaquer à Apple et à Qualcomm avec ses cœurs personnalisés « Mongoose » qui ont alimenté les chipsets Exynos pendant des années. Mais en 2019, l’entreprise a réduit la taille de sa branche CPU, abandonnant les conceptions de processeurs personnalisés.
La société a déclaré par euphémisme qu’il s’agissait d’un changement effectué pour rester « compétitif » sur le marché mondial, mais la simple vérité est qu’en 2019, les conceptions de noyau de référence ARM étaient plutôt bonnes, et le développement d’un bon silicium personnalisé devient beaucoup plus difficile. Samsung n’était tout simplement pas à la hauteur du défi : ses puces Exynos étaient lentes, chaudes et inefficaces par rapport à celles de Qualcomm. C’était peut-être un jour triste pour ceux qui espéraient que Samsung pourrait changer les choses, mais rien de précieux n’a été perdu. Les rumeurs prétendent que Samsung pourrait à nouveau essayer les processeurs personnalisés à l’avenir, mais elle a utilisé des conceptions de référence ARM au cours des dernières années, qui seront bientôt complétées par les fruits d’un partenariat avec AMD dans le domaine des GPU.
Maintenant, être mauvais en matériel ne signifie pas que Samsung System LSI était également mauvais en logiciel, mais étant donné ses difficultés, je parierais que si Samsung n’a pas pu concevoir de bons noyaux pour ses propres chipsets, elle a probablement eu des difficultés à les supporter au niveau des pilotes également.
Tout est question d’architecture
Si vous ne savez pas comment fonctionne la pile Android, la version simplifiée est qu’il y a une sorte de gâteau en couches entre les cerises d’application au sommet et la plaque matérielle du téléphone, traduisant tout de haut en bas plusieurs pipelines différents pour vous montrer des vidéos TikTok de chats qui éternuent.
L’architecture d’Android fonctionne comme illustré ici. Les éléments que l’utilisateur voit, fait défiler et touche sont tous situés au-dessus de la couche supérieure du cadre d’application. En bas, on trouve les pilotes matériels et les HAL (couche d’abstraction matérielle) qui permettent à vos applications et aux composants du système de communiquer avec le matériel. Ces pilotes (et parfois les HAL) font généralement partie de ce que l’on appelle le BSP, ou board support package, qu’un fabricant de chipsets fournit au fabricant de téléphones.
Tous les éléments intermédiaires permettent d’abstraire cette relation, de la rendre plus sûre et de l’optimiser, afin que les bonnes instructions soient envoyées aux bons endroits. Ces pilotes sont généralement fournis par le fournisseur de matériel et, bien que les éléments les plus importants soient presque toujours fermés et propriétaires (c’est-à-dire non documentés publiquement au niveau du code source), les partenaires ont parfois accès à la source pour les aider à résoudre les problèmes qu’ils rencontrent.
Dans le cas de Tensor, il est probable que la plupart de ces pilotes en bas de page soient fournis par Samsung. Nolen Johnson, DirectDefense inc. consultant en sécurité matérielle et responsable des relations avec les développeurs de Lineage OS, nous dit que dans une « analyse diff » des pilotes de modem (comparaison du code entre deux versions), le Tensor du Pixel 6 est presque 1:1 identique aux autres pilotes de modem Exynos 5123. Andrei Frumusanu, anciennement d’Anandtech, a confirmé publiquement que fondamentalement tout dans Tensor, à l’exception du TPU (l' » unité de traitement Tensor » qui gère les charges de travail d’IA) et de l’ISP (Image Signal Processor, utilisé pour la vidéo et les photos), est une conception matérielle de Samsung. (Cela n’a pas vraiment d’importance pour cette discussion, mais il se peut que Google utilise également un accélérateur matériel pour le zram swap que Samsung laisse désactivé).
Rien de tout cela ne prouve que Samsung est en charge des pilotes pour Tensor, mais la relation antérieure de Google avec Qualcomm pourrait être un indicateur de sa relation avec Samsung pour la nouvelle puce.
Pour situer le contexte, Johnson m’a dit que Google avait un accord spécifique avec Qualcomm : Google disait à Qualcomm ce dont il avait besoin dans un BSP, puis il y ajoutait ses propres éléments secrets, comme un Power HAL personnalisé (qui gère les états d’alimentation et les performances) et quelques autres détails. Cela simplifie le développement, puisque Qualcomm fournit la plupart des pilotes, à l’exception de quelques ajustements. Je dois souligner que Samsung Systems LSI a vendu ses produits de type Qualcomm à d’autres fournisseurs par le passé, comme Motorola, mais qu’elle a certainement moins d’expérience en la matière, étant donné la différence de volume et de partenaires.
En fin de compte, il n’est pas clair si Google a la même relation avec Samsung pour le Pixel 6 qu’avec Qualcomm sur les Pixel précédents, et si Samsung fournit à Google un BSP qui répond à ses exigences pour le Pixel 6, ou si Google gère les pilotes non modem de manière indépendante (et si c’est le cas, il pourrait être à court de personnel – plus à ce sujet plus tard). Google a été fier de sa marque Tensor dans les communications publiques, minimisant l’implication indéniable de Samsung au niveau matériel, et cela pourrait être une indication que cette relation fonctionne différemment quand il s’agit de logiciels.
Que se passe-t-il dans ces mises à jour logicielles retardées ?
Tout comme la pile Android elle-même, beaucoup de bits et de pièces entrent dans les mises à jour logicielles, et c’est un endroit où Google reconnaît ouvertement l’impact que les fournisseurs de matériel tiers ont. Après tout, beaucoup de problèmes de sécurité se produisent dans l’interface entre le matériel et le logiciel – et parfois même purement dans le matériel lui-même, contourné plus tard par le logiciel, comme avec les vulnérabilités Meltdown Spectre qui ont dominé l’actualité du matériel en 2018.
Il est compréhensible que la plupart d’entre vous n’aient pas lu tous les détails publiés par Google sur les bulletins de sécurité d’un patch mensuel, mais les bulletins de mise à jour Pixel et les bulletins de sécurité Android notent en détail les CVE (une façon élégante de dire les vulnérabilités de sécurité) corrigées dans une version donnée. En fait, les bulletins Pixel comportent généralement une section entière (ou deux !) consacrée aux corrections spécifiques à Qualcomm. Cela signifie qu’en plus des correctifs fonctionnels qui modifient les fonctionnalités ou corrigent les bogues de l’utilisateur, Google prend explicitement note des vulnérabilités logicielles et matérielles corrigées dans cette mise à jour.
Il est pratiquement impossible d’obtenir des fabricants de matériel informatique qu’ils s’expriment officiellement sur leurs contrats et arrangements avec les fournisseurs. Google, bien entendu, n’a fourni aucune information pour cet article. Mais les ingénieurs d’autres entreprises au fil des ans m’ont dit officieusement que le support logiciel et le développement de pilotes de Qualcomm sont excessivement bons, et maintenant qu’il a sa « propre » puce, Google ne peut plus compter sur cela en ce qui concerne le Pixel 6. Encore une fois, Samsung a vendu des puces Exynos à certaines autres entreprises, et je parierais qu’elle fait tout ce qu’elle peut pour fournir des pilotes de puces aux clients, mais Qualcomm opère à un autre niveau. Je pourrais facilement voir Samsung trébucher d’une manière à laquelle Google n’était peut-être pas préparé et prendre plus de temps pour résoudre les problèmes.
Maintenant, il est curieux que Google n’ait pas encore mentionné Samsung une seule fois dans ses Bulletins de mise à jour Pixel – le faire serait une reconnaissance tacite des pilotes et logiciels Samsung assurément à l’œuvre à l’intérieur du Pixel 6. Mais ces mises à jour mensuelles contiennent absolument des correctifs pour les pilotes matériels et les composants binaires à code fermé. Google et Qualcomm en prennent note, et les problèmes liés à ces composants logiciels pourraient avoir un impact sur la rapidité des mises à jour. S’il y a un bug critique ou une vulnérabilité dans le matériel qui doit être corrigé et que, pour une raison quelconque, il ne peut pas être abordé à temps pour le déploiement habituel du patch de sécurité du premier lundi du mois, je pourrais voir Google retenir une mise à jour pour les Pixel affectés pendant une courte période pour l’inclure plutôt que d’attendre – et, apparemment, c’est exactement ce qu’il a fait.
La mise à jour de décembre 2021 du Pixel 6 a été retirée en raison d’un problème de connectivité des appels. Eh bien, le Pixel utilise de manière vérifiable un modem Samsung Exynos et les appels et la connectivité mobile sont du ressort du modem sur une base matérielle. Un tel problème n’est peut-être pas une vulnérabilité de sécurité, et n’aurait donc pas été mentionné dans le bulletin de sécurité du Pixel de janvier (c’est le travail des notes de correctifs fonctionnels moins détaillées, qui le mentionnent), mais il aurait pu nécessiter l’aide de Samsung pour le résoudre, et je doute que Samsung ait autant d’expérience en tant que fournisseur de puces pour smartphones que Qualcomm, donc tout changement lié au modem aurait pu prendre plus de temps à livrer.
Sur cette note, examinons la chronologie complète des problèmes de mise à jour du Pixel 6.
Trois mois de galère
La série Pixel 6 a été annoncée le 19 octobre et s’est retrouvée dans les mains des clients à partir de la fin du mois. À sa sortie de la boîte, elle exécutait un niveau de patch de novembre 2021 (lorsque nous l’avons examinée initialement, elle était sur celui d’octobre). Ensuite, il a reçu une mise à jour bonus surprise à la mi-novembre pour traiter les performances du capteur d’empreintes digitales – un problème que la série Pixel 6 a depuis son lancement, et dont certains affirment qu’elle souffre toujours. Une mise à jour de mi-cycle comme celle-ci était un peu inhabituelle, mais les Pixel ont une histoire de lancements buggés, et nous n’étions pas sur le point de nous opposer à des corrections plus rapides.
Puis la mise à jour de décembre a débarqué – ou, plus précisément, n’a pas débarqué pour la plupart des gens. Alors qu’elle a été déployée pour les autres Pixel au bon moment, elle a été retardée pour le Pixel 6 pendant des semaines, pour arriver le 13 décembre, et même alors, elle ne semblait pas être déployée à grande échelle. Certains pensaient qu’un déploiement plus large était simplement retardé (en plus de ce retard initial) ou faisait partie d’une mise à jour échelonnée, tandis que d’autres spéculaient qu’il pourrait avoir été secrètement retiré. Finalement, elle a été retirée. Google a déclaré que des problèmes d’appels interrompus et déconnectés étaient à blâmer (comme nous l’avons déjà évoqué), et a même retiré de son site les images OTA et d’usine téléchargeables.
Une nouvelle mise à jour a été promise « d’ici la fin janvier » – ce qui a signalé un autre retard pour le calendrier normal du premier lundi du mois. Puis, le 14 janvier, elle a atterri, livrant enfin à la fois un correctif pour le problème d’appel et les changements tant attendus de décembre Feature Drop pour la série Pixel 6.
Je couvre les nouvelles de Pixel depuis 2017 ici à Android Police, et je ne peux pas penser à une seule fois où un snafu comme celui-ci a été aggravé par autant de retards et de problèmes. La période post-lancement du Pixel 6 a été unique pour ses problèmes de mise à jour et la gravité perçue de ses problèmes.
Alors, qu’est-ce qui a changé ? Selon Nolen Johnson, pas mal de choses.
Rattraper le retard avec Tensor
De par sa position au sein de Lineage OS, Johnson en sait long sur le fonctionnement des pilotes dans Android et sur le processus de développement d’Android. Après tout, la ROM Lineage OS doit modifier et pirater les nouvelles versions d’Android pour qu’elles fonctionnent sur des téléphones plus anciens et non pris en charge. Les développeurs impliqués apportent même des modifications en retour, en suivant le processus de développement d’Android. Et, d’après ce qu’il m’a dit, le Pixel 6 marque une rupture avec la routine.
Pour un peu de contexte supplémentaire, dans une certaine ligne de temps alternative, le Pixel 6 aurait été le deuxième téléphone alimenté par le Tensor de Google. Le Pixel 5 de 2020 était en fait censé être le premier. Bien que cette année supplémentaire de polissage ait pu produire un meilleur téléphone, Google est toujours en retard sur le calendrier à d’autres égards.
Habituellement, à cette époque de l’année, Android est revenu à une base de code unifiée pour tous les chipsets et appareils. Cependant, après la sortie d’Android 12, Johnson nous dit que les choses sont encore divisées, et Google maintient essentiellement une piste distincte juste pour Tensor, même si une unification aurait dû se produire maintenant. Android 12L pourrait encore compliquer les choses, avec ce problème de pistes multiples expliquant pourquoi il n’y a pas de version d’Android 12L pour le Pixel 6 : puisque Google maintient déjà effectivement trois versions d’Android 12 en ce moment, cela ne ferait qu’en ajouter une quatrième. Cette division dans le développement du code pourrait être responsable des mises à jour retardées.
« Le cycle de développement normal a été perturbé par la conversion de Whitechapel, et à cause de cela, nous voyons ces délais prolongés pour les [mises à jour]. Je parie que même le mois de février sera retardé, et qu’en mars nous pourrions voir un tag unifié avec 12L et Whitechapel. «
Google recrute également activement des développeurs ayant de l’expérience dans le domaine des microprogrammes de bas niveau pour les puces ARM. Cela pourrait indiquer qu’il ne dispose pas actuellement des ressources nécessaires pour gérer la pile complète dans Tensor, en supposant qu’il soit responsable d’un plus grand nombre de pilotes qu’il ne l’était auparavant sous Qualcomm.
Une théorie que seul Google peut confirmer
Une partie de moi a l’impression que je devrais avoir un chapeau en fer-blanc en écrivant le reste de ceci, car il n’y a pas beaucoup de preuves concluantes, juste beaucoup de preuves circonstancielles. Quelque chose au sujet du Pixel 6 semble avoir provoqué la rupture du processus de développement et de mise à jour du logiciel habituellement prévisible de Google, et le changement le plus évident est Tensor.
Si plus d’appareils étaient concernés, je dirais que cela pourrait être un Android 12, mais le Pixel 6 est spécial : il a été retardé quand d’autres téléphones ne l’ont pas été, et il manque les builds Android 12L quand d’autres Pixel ne le sont pas. Google n’a pas fait quelque chose de sournois comme pousser un noyau Linux mainline sur lui (bien que nous devions souligner qu’il exécute une version beaucoup plus récente du noyau Linux que presque tous les autres téléphones Android, ce qui aidera à la longévité des mises à jour). Mais, pour autant que nous puissions dire, si les problèmes et les retards sont dus au logiciel, ils sont liés à un logiciel unique au Pixel 6.
Je ne sais pas si ces problèmes sont imputables à Samsung en tant que fournisseur quasi certain de logiciels au niveau du pilote pour le matériel quasi Exynos de Tensor, ou à Google qui apprend à gérer la pile logicielle complète jusqu’au niveau du silicium pour la toute première fois, comme l’indiquent les récentes offres d’emploi. Seul Google peut le confirmer – et, jusqu’à présent, l’entreprise est restée silencieuse sur le sujet. Mais je pense qu’il y a suffisamment de preuves pour considérer Tensor comme un coupable probable pour les mises à jour retardées et les malheurs logiciels généraux du Pixel 6, même si je suis convaincu que Google peut et va corriger cela à long terme alors qu’il trébuche sur son premier bébé puce.
Je ne critique pas Google pour avoir adopté un chipset « maison » (même s’il ne s’agit que de 90 % de pièces Samsung Exynos et que ce n’est pas le niveau de progrès que certains d’entre nous avaient espéré). Je pense que la généralisation du silicium personnalisé est inévitable pour le marché, car les coûts de différenciation et de développement de solutions personnalisées diminuent inévitablement, en particulier lorsque des sociétés comme Samsung et MediaTek commencent à offrir ce service.
Google fait sagement un investissement précoce, alors qu’il est généralement en retard sur les tendances du marché. Dans cinq ans, je suis persuadé que le Tensor 2021 aura donné à Google un avantage dans l’espace Android s’il continue sur la voie de la personnalisation – avec, je l’espère, des changements plus profonds et moins de pièces détachées Samsung médiocres. Mais pour l’instant, nous voyons les douleurs de croissance qui viennent du fait que Google gère finalement la pile logicielle complète jusqu’au silicium lui-même (ou avec l’aide moins expérimentée de Samsung), et cela va prendre un peu de temps pour que la situation logicielle s’installe dans ce changement. Et si vous n’êtes pas d’accord avec cela, vous n’êtes pas obligé d’acheter un Pixel 6, même si nous pensons toujours que c’est le meilleur téléphone Android.
Comment numériser des documents et des photos en PDF sur Android
Votre téléphone est plus que capable, et nous avons la meilleure application pour ce travail.
Ryne Hager
(2898 articles publiés)
Ostensiblement rédacteur en chef, en réalité juste un mec verbeux qui creuse sur la tech, aime Android, et déteste les pratiques anticoncurrentielles. Son seul regret est de ne pas avoir acheté un Nokia N9 en 2012. Envoyez vos conseils ou corrections à ryne at androidpolice dot com.
