Dans cet article, nous explorons la vérité sur les raisons pour lesquelles les appareils Snapdragon 801 ne reçoivent pas Android Nougat. Des fabricants de chipsets aux fournisseurs, les problèmes sont nombreux !
Mis à jour pour refléter l'exigence soit de Vulkan soit d'OpenGL ES 3.1 pour Android 7.0
Récemment, de nombreux articles ont été écrits sur les mises à jour de versions, les interactions entre le fournisseur et le fabricant de chipsets, et ce que cela signifie pour les appareils à l'avenir. Pourquoi cela a-t-il augmenté cette semaine ?
Eh bien, cela est apparu cette semaine étant donné que le vénérable Nexus 5 ne recevra pas la mise à jour vers Android 7.0 (Nougat), et Qualcomm a annoncé qu'elle ne le serait pas. fournissant la prise en charge du MSM8974 (plus communément appelé Snapdragon 801) sur 7.0. Cet article a été rédigé en collaboration avec XDA Recognized Développeur bourdon.
Le sujet a suscité beaucoup d'intérêt de la part de divers sites d'information, mais beaucoup passent à côté des nuances subtiles de ce qui se passe réellement dans les coulisses
La première étape dans la vie d’une mise à jour du firmware Android est la mise à jour en amont. C’est sur cela que Google travaille en interne. Contrairement aux « workflows ouverts », Android est développé à l'aide d'un workflow fermé, avec le code source jeté par-dessus le mur chaque année environ, lorsqu'une nouvelle version sort. À l'origine, Google avait déclaré que cela visait à empêcher la fragmentation par les personnes exécutant des versions de pointe. alors que les choses évoluaient rapidement au début, mais ils semblent avoir gardé cette politique en lieu.
À un moment donné, généralement avant l'annonce publique d'une mise à jour (bien qu'avec l'introduction récente des versions bêta publiques, ces délais changent), Les OEM seront informés d'une mise à jour à venir. Ils recevront ensuite le code source à un deuxième moment pour la mise à jour finale (auparavant, c'était parfois un peu avant le lancement, même si nous connaissons également des cas où il n'y a pas d'annonce anticipée libérer).
Les référentiels AOSP en amont contiennent la prise en charge des appareils pour un nombre limité d'appareils uniquement. Il s'agit généralement de vos appareils Nexus. Cependant, pour des raisons qui apparaîtront clairement sous peu, il est important de noter que Google n'a pas un contrôle matériel complet sur ces appareils; les appareils sont fabriqués par un OEM, et cet OEM achètera un système sur puce (SoC) auprès d'un fabricant de chipsets.
Une fois le code source publié, l'équipe du firmware de l'OEM va (au sens figuré) s'asseoir et se lever. L'arborescence source principale d'Android ne prend pas en charge matériellement la myriade de chipsets utilisés dans les appareils d'expédition. Votre chipset Qualcomm n'est probablement pas pris en charge dans AOSP, par exemple. Votre Exynos ne l’est certainement pas. Mediatek ou HiSilicon? Oublie ça!
Le BSP contient les pilotes et les couches d'abstraction matérielle (HAL) nécessaires au fonctionnement d'Android.
Ce qu'il faut maintenant, c'est un Package de support du conseil d'administration (BSP). Il s’agit d’un ensemble ultra-confidentiel de composants propriétaires, livré par un fabricant de chipsets à un OEM. Le BSP contient le code source nécessaire pour permettre aux OEM de créer Android ainsi que les pilotes nécessaires pour leur appareil.
Il convient de noter ici que les OEM comme Qualcomm ne font pas nécessairement entièrement confiance à leurs partenaires OEM: le BSP est mis à disposition sur la base du « besoin de savoir ». Les constructeurs OEM n'ont généralement pas accès au code source de certaines parties ultra-secrètes de l'appareil (comme le logiciel exécuté sur la bande de base). La fermeture de cette partie présente certainement également des problèmes potentiels, comme le montre le plan proche. copieux et récurrent ASN.1 analyse des vulnérabilités.
Le BSP contient les pilotes et les couches d'abstraction matérielle (HAL) nécessaires pour faire fonctionner Android sur votre appareil. AOSP contient un ensemble de HAL, qui servent de définitions de ce que le système d'exploitation attend de vos pilotes qu'ils implémentent. Pour utiliser un exemple ridiculement simplifié (et inventé, à des fins de démonstration), imaginons la lampe de poche sur votre téléphone.
Un exemple HAL - Votre lampe de poche
Imaginons que votre appareil soit équipé d'une lampe de poche à l'arrière (si vous possédez un Nexus 7 2013, vous devrez faire un peu plus d'imagination que tout le monde - désolé !). Ceci est contrôlé par un chauffeur. Pour notre exemple incroyablement simple, supposons que le HAL v1 indique que vous devriez avoir une fonction appelée "setLED" prenant un seul paramètre, l'état de la lumière. C'est un booléen - vrai ou faux. En C, cela ressemblerait à ceci :
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Cette fonction est définie dans le code source BSP. Le BSP est ensuite compilé par l'OEM lors de la création de la ROM, et cela devient l'une des bibliothèques propriétaires « .so » sur la partition ou la zone du fournisseur de votre appareil. Cela permet à un OEM de garder secrètes certaines parties du fonctionnement de son appareil. Pour l'instant, supposons qu'ils veulent empêcher tout le monde de voir comment ils allument et éteignent cette LED.
Imaginez maintenant que Google publie une version mise à jour de ses HAL dans une future version d'Android. Ils décident maintenant qu'il serait bien de vous permettre de mettre à jour la luminosité de votre LED, plutôt que de simplement l'allumer ou l'éteindre. Peut-être que c'est pour le flash adaptatif, ou peut-être est-ce simplement pour forcer une mise à jour de HAL et maintenir les fabricants de chipsets en activité? Nous vous laissons, lecteur, vous faire votre propre opinion sur ce point. Certaines mises à jour de HAL présentent des avantages évidents (comme le nouveau Camera HAL exposant la prise de vue brute et similaire), tandis que d'autres ont un objectif un peu moins clair.
Avec ce nouveau HAL (fictif) pour la luminosité, supposons que Google dise que vous devez à nouveau exposer une fonction appelée setLED, mais cette fois avec un entier transmis pour la luminosité. Maintenant, 0 l'éteindrait et 255 l'allumerait au maximum.
Si vous êtes l'OEM, vous pouvez utiliser votre code super secret pour allumer cette LED et l'intégrer à cette nouvelle fonction. Vous pouvez même utiliser la modulation de largeur d'impulsion pour ajuster la luminosité de la LED en fonction du nombre. Vous modifiez la fonction pour qu'elle apparaisse comme ceci maintenant :
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Et alors? Eh bien, désormais, cette nouvelle version d'Android est incompatible avec les "blobs" existants. Votre OEM doit utiliser ces nouveaux blobs, car le système d'exploitation Android s'attend à voir la nouvelle définition de fonction et ne « trouvera » pas l'ancienne lorsqu'il cherchera un moyen de régler la LED.
À ce stade, prenons un bref entracte pour voir comment les ROM personnalisées (construites à partir des sources) gèrent ici. C'est ce que les plus astucieux d'entre vous crieront sur votre écran en ce moment – après tout, nous sommes XDA, la maison du HTCHD2, le téléphone le plus durable au monde... (juste pour mémoire, les génies fous là-bas courent Android 6.0 sur le HD2 ces jours-ci! Pas mal pour un téléphone initialement livré avec Windows Mobile 6.5 en 2009)
Il existe différentes approches adoptées ici - parfois les développeurs piratent la ROM et demandent au système d'exploitation d'utiliser les anciennes définitions de fonctions. C'est un peu compliqué et nécessite beaucoup de changements à maintenir. L'autre approche consiste à "caler" le binaire OEM.
L'approche "shim" consiste à écrire et à construire vous-même une toute petite bibliothèque, qui contient la définition de fonction attendue - pour notre exemple, nous prendrions en charge l'entier pour la luminosité. Ensuite, à l'intérieur de la cale, cela est traduit pour répondre aux exigences de l'ancien HAL. Donc, pour notre exemple, nous dirions peut-être que toute luminosité demandée au-dessus de 128 allumera la LED, et toute luminosité inférieure à celle-ci l'éteindra. Ou vous pourriez dire que tout ce qui n'est pas zéro l'allumera. C'est au développeur. Ils compilent le shim et demandent à Android de l'utiliser à la place du natif. La cale appelle ensuite le blob OEM.
Un rapide « adb push » et un redémarrage devraient faire démarrer la cale et vous permettre de contrôler votre LED fictive, même si vous n'avez que l'ancien HAL.
Le problème est qu’il s’agit clairement d’un processus imparfait. Vous aurez maintenant des bizarreries - cet appareil aura un flash plutôt minable, qui est soit complètement allumé, soit complètement éteint. Ce n'est pas idéal: le système d'exploitation pense qu'il produit une lumière très douce, mais on dit à la LED qu'elle participe à un concours de soleil artificiel et essaie de vous aveugler. Mais bon, la vie n'est pas parfaite, et vous avez désormais une LED fonctionnelle sur votre ancien téléphone !
(Oui, c'est l'une des raisons pour lesquelles il y a des bizarreries et des bugs lorsque les utilisateurs et les développeurs XDA gèrent leurs prouesses folles et insensées en matière de portage. Je veux dire, bon sang, le Galaxy SII est en train de transporter un apparemment utilisable ROM Android 6.0 maintenant. De nombreux téléphones sortis l'année dernière n'ont toujours pas la version 6.0 !)
Revenons au point de vue de l'OEM. Malheureusement, la plupart des constructeurs OEM travaillent déjà avec au moins un téléphone en avance sur notre situation actuelle. Ils se concentrent sur le prochain téléphone qu’ils sont sur le point de vendre – on ne peut pas vraiment leur en vouloir, car ils ne gagnent de l’argent qu’avec les appareils qu’ils vendent. Ils ne gagnent pas d’argent avec les appareils qu’ils ont vendus il y a un an ou deux, ils doivent donc continuer à lancer de nouveaux appareils pour exister. C'est l'une des raisons pour lesquelles HTC et Blackberry sont en difficulté: peu importe le nombre de dirigeants qui conservent une emprise mortelle sur leur ancien Blackberry Curve, car ils n'obtiennent pas de vente de nouvel appareil là-bas.
Si l'OEM n'obtient pas de BSP, il ne suivra pas l'approche XDA consistant à pirater ensemble une version. Pourquoi? Bien, ils doivent prendre en charge ce firmware pour leurs clients. S'ils publient un firmware qui ne fonctionne qu'à moitié, les utilisateurs le détesteront, se déchaîneront et délireront, et feront résonner leurs lignes d'assistance pendant des jours.
Les équipementiers doivent également composer avec les transporteurs, du moins sur les marchés non européens. Les opérateurs ne veulent pas que leurs clients rencontrent des problèmes avec les mises à jour logicielles. En fait, les opérateurs préfèrent souvent ne pas publier de mises à jour logicielles.
Pour comprendre cela, imaginez votre grand-tante Alice. C'est elle qui vous appelle à des moments inopportuns de la journée pour vous demander de l'aide avec « ce truc d'ordinateur ». Vous décrivez ensuite comment cliquer sur le "menu Démarrer" et devez l'identifier comme le "grand drapeau dans le coin inférieur gauche", et vous êtes confronté à une certaine confusion. Environ 45 minutes (et beaucoup de frustration) plus tard, il apparaît que tante Alice a fait glisser son menu Démarrer vers le bord droit de l'écran et qu'elle avait simplement besoin de le faire glisser vers l'arrière. Oui, avec le bouton gauche de la souris !
Imaginez maintenant que vous avez mille tantes Alice. Ils appellent tous votre service client, incapables de trouver Candy Crush sur leur téléphone, inquiets qu'un pirate informatique l'ait supprimé de leur téléphone. Oh, et les icônes sont un peu différentes maintenant: peut-être que le pirate informatique est toujours dans son téléphone ?
Oui, c'est censé être un peu d'humour léger, mais jusqu'à ce que vous connaissiez les raisons pour lesquelles les gens appellent leur opérateur pour obtenir de l'aide, vous ne croirez pas les problèmes qu'ils ont. Une mise à jour logicielle qui modifie le fonctionnement du téléphone ou l'emplacement des éléments entraînera une surcharge de support importante. Au minimum, cela nécessite une nouvelle formation du personnel d'assistance (car la plupart d'entre eux ne sont malheureusement pas vos fervents lecteurs XDA).
Une fois que l'OEM aura obtenu le BSP, il portera sa ROM et appliquera toutes ses modifications à la ROM. Ils empileront leurs bloatwares et ajouteront un horrible skin de dessin animé qui conviendrait mieux à un anime d'adolescent. Ensuite, ils le testeront.
Beaucoup.
Il existe toutes sortes d'exigences auxquelles votre téléphone doit se conformer. Les réseaux mobiles sont conçus pour faire confiance à l'équipement de l'utilisateur (ce que nous appelons le téléphone) pour se comporter correctement. Cela signifie que de nombreux tests sont nécessaires pour que l'appareil soit approuvé. Les mises à jour logicielles risquent de modifier les comportements, les choses doivent donc être testées à nouveau. C'est pourquoi vous verrez généralement des informations sur les prochaines mises à jour logicielles Sony provenant de services de test externes, qui confirment que le micrologiciel est conforme aux exigences de test.
Maintenant... que se passe-t-il après une ou deux mises à jour (ou dans certains cas, aucune)? Le fabricant de SoC ne fournira pas à l'OEM un BSP mis à jour. Après tout, le fabricant de SoC n’en tirera pas grand-chose. L'OEM ne gagne plus d'argent avec votre téléphone depuis sa vente. Et à ce stade, votre téléphone ne reçoit plus de mises à jour de version majeures.
Réduire le nombre de BSP que l'OEM souhaite livrer est un excellent moyen d'économiser de l'argent - si vous n'avez besoin que du modèle actuel et que vous n'avez pas l'intention de livrer une version majeure. augmente, cela permettra d'économiser de l'argent sur l'achat initial et la licence du SoC, mais au détriment de quelques nerds en colère sur XDA sur toute la ligne, se demandant pourquoi ils n'ont pas obtenu un mise à jour.
Les mises à jour sont complexes. Il y a beaucoup de personnes différentes impliquées dans la chaîne. Rien de tout cela n’excuse les constructeurs OEM de l’état actuel des mises à jour sur Android, laxiste et pathétique. Néanmoins, il existe ici de véritables défis.
De nombreux équipementiers sont responsables de leurs promesses excessives, et le une inévitable sous-performance que nous associons désormais. La triste réalité est que pour la plupart des constructeurs OEM, les mises à jour logicielles ne sont qu’une nuisance dont ils pourraient se passer.
Le secteur mobile est principalement coincé dans la mentalité des téléphones polyvalents. Autrement dit, un appareil ne reçoit jamais de mises à jour. Testez-le une fois, expédiez-le et ne regardez jamais en arrière. Avec les problèmes de sécurité des smartphones modernes et la complexité même de faire fonctionner un système d'exploitation à usage général complet, avec des centaines de bibliothèques externes, ce n'est plus une option. Ou du moins ça je ne devrais pas être. Google a pris quelques mesures pour résoudre ce problème, en publiant au moins des bulletins de sécurité et des correctifs pour les versions existantes. d'Android (rappelez-vous que jusqu'à très récemment, le seul moyen d'obtenir des mises à jour de sécurité était via une nouvelle version majeure du système d'exploitation Android !)
Hélas, cela ne suffit pas vraiment. Même si Google continue de publier des mises à jour, la sécurité de votre appareil dépend toujours du fabricant du SoC, car les fabricants de SoC sont tellement pétrifiés quelqu'un découvrant comment il allume quelques LED ou émet un son via un haut-parleur, il envoie d'énormes quantités de blobs binaires sur son dispositifs. Ces blobs contiennent du code terriblement dangereux (il suffit de jeter un œil aux précédents bulletins de sécurité de Google si vous pensez que c'est une exagération !) et doivent être mis à jour. Ce qui signifie que des BSP mis à jour sont nécessaires.
Les ordinateurs de bureau (et par extension, les ordinateurs portables) ont une architecture complètement différente de celle des appareils mobiles. Votre téléphone mobile ou votre tablette est en fait un morceau de silicium très exclusif, conçu à la hâte par certaines personnes qui ont de bonnes intentions, mais qui n'ont pas assez de temps pour faire quelque chose de bien. Le marché évolue si rapidement qu'il est à peine capable de suivre le rythme auquel le marketing exige le lancement de nouveaux produits.
Cela signifie que des raccourcis sont pris - vous ne trouverez pas votre téléphone pris en charge par le noyau Linux principal et vous constaterez que chaque téléphone a une manière différente de démarrer. Cependant, sur votre ordinateur portable ou de bureau, les fournisseurs ont opté pour des méthodes de démarrage standard: auparavant, il s'agissait de MBR (master boot record) avec un BIOS, et maintenant de UEFI. Cette standardisation permet d'exécuter le même logiciel sur chaque appareil.
Bien que des mesures aient été prises récemment dans ce sens, notamment avec le programme de sensibilisation de Sony et son noyau unifié, il n'est pas pratique d'exécuter un noyau principal sur la plupart des téléphones, en raison du grand nombre de nouveaux hacks spécifiques au fournisseur introduits sur chaque appareil.
Câblé la prise casque à l'envers? Piratez-le simplement dans les pilotes! Nous n’avons pas le temps de le corriger dans la conception de la production.
L'équipe de fabrication a monté le module caméra à l'envers dans le lot de production 1? Lancez un hack pour vérifier le code de la version interne et retournez la vidéo s'il s'agit de la version 1 !
Des hacks comme ceux-ci résolvent le problème immédiat, mais ne font qu'effleurer la surface des changements étranges et spécifiques au produit en cours. Bon sang, il y a même parfois des puces totalement différentes dans différentes révisions du même téléphone, en raison de décisions commerciales. Cela a conduit à des piratages de chauffeurs et à des décisions étranges qui n'avaient de sens qu'à l'époque, pour faire fonctionner le téléphone afin qu'il puisse être expédié la semaine suivante.
Bien que des travaux soient en cours pour généraliser la prise en charge des puces ARM 64 bits permettant de démarrer à l'aide de l'UEFI, il y a eu jusqu'à présent des progrès. pas de mouvement clair vers une manière plus standardisée de démarrer les appareils ARM. Et c'est dommage, car cela signifie que les téléphones continueront d'être jetés bien avant la fin de leur durée de vie. vie professionnelle, car il est tout simplement trop coûteux de maintenir la dette technique et le fardeau qui pèse sur leurs employés. logiciel.
D’un autre côté, si un OEM ne gagne de l’argent qu’en vendant un appareil, n’a-t-il pas besoin de s’assurer que les gens continuent d’acheter de nouveaux téléphones? Le marché des PC évoluerait-il vers ce modèle s'il n'y avait pas déjà 30 ans d'essor et de logiciels existants utilisant la plate-forme et le standard PC ouverts ?
C’est une question difficile sans les connaissances approfondies de Qualcomm, que nous n’avons malheureusement pas pour le moment. Cependant, nous pouvons tirer quelques informations de l'API du pilote Android 7.0 et des exigences CTS. Les exigences CTS précisent ce que Google attend d'un appareil exécutant un micrologiciel donné. Le « gros marteau » utilisé pour faire respecter ces exigences est la licence accordée par Google pour utiliser son ensemble exclusif de services Google Play. si vous ne vous conformez pas, vous ne pouvez pas diffuser Google Apps sur l'appareil. Alors que, pour certains, cela pourrait être considéré comme un avantage, ce n’est évidemment pas ce que les utilisateurs veulent et attendent d’un appareil.
Android 7.0 n'a pas ajouté grand-chose en termes de modifications apportées au HAL ou aux pilotes (comme décrit ci-dessus), il est donc peu probable qu'une incompatibilité provienne de là spécifiquement. Ce qui est plus susceptible de poser problème, cependant, c'est l'introduction d'un nouvelle exigence pour l'API graphique Vulkan ou GLES 3.1, être disponible afin de réussir le CTS.
À l'heure actuelle, de nombreux systèmes sur puce (SoC) ne prennent pas en charge Vulkan sur leur processeur graphique, y compris le MSM8974. C’est également très probablement là que se posera le problème de la compatibilité avec Android 7.0. Mais encore une fois, sans connaissance approfondie de Qualcomm et de ses projets futurs, il est difficile pour nous de donner une déclaration définitive sans la nuancer. Pour le moment cependant, nous pensons qu'il est probable qu'il s'agisse d'un cas "simple" où Qualcomm interrompt son support pour le chipset MSM8974 vieillissant (à leurs yeux) et ne fournissant pas de BSP (board support package) pour 7.0 sur cette plate-forme. Si tel était le cas, cela signifierait que les OEM seraient presque certains de ne pas fournir la version 7.0 sur l'appareil - ils devraient d'une manière ou d'une autre trouver le support Vulkan ou GLE 3.1 pour leur GPU et leur source GPU. le code est l'une des parties ridiculement étroitement gardées des piles mobiles (sans aucune raison réelle, ajouterions-nous - voir AMD, open source son propre pilote AMDGPU sur le bureau pour Linux). Malheureusement, cependant, les graphiques Vulkan et accélérés (GLES) en général sont un peu plus complexes qu'une simple LED, ce n'est donc pas quelque chose pour lequel nous allons voir des cales pour introduire la compatibilité.
Comme la version 7.0 n'est pas disponible depuis longtemps, il existe une réelle possibilité que d'autres chipsets (autres que le petit nombre au sein de l'AOSP lui-même) soient laissés de côté. en retard sur la version 6.0, en raison soit de problèmes de matériel et de pilotes (c'est-à-dire pas de BSP mis à jour), soit d'un manque de support du fournisseur SoC en ce qui concerne le Vulkan ou le GLES 3.1 API. À l’heure actuelle, ni le Snapdragon 800 ni le 801 ne prennent en charge l’un d’entre eux.
Le mieux est de surveiller cet espace - Les développeurs sur XDA font déjà de bons progrès avec des ports non officiels vers 7.0 pour de nombreux appareils ne bénéficiant pas du support officiel 7.0 de Google. Cependant, ceux-ci ne prennent pas en charge Vulkan ou GLES 3.1 - peut-être que les développeurs de jeux sur Android commenceront à le faire. ressentez de la frustration à cause de la fragmentation si suffisamment d'utilisateurs commencent à exécuter des ROM personnalisées sans Vulkan ou GLES 3.1 soutien?
Apple a tendance à prendre en charge sa gamme iPhone sur la dernière version d'iOS depuis environ 5 ans - l'iPhone 4s a été lancé en octobre 2011 et a été mis à jour jusqu'à iOS 9. Il ne recevra cependant pas la prochaine mise à jour iOS 10, ce qui donnerait au téléphone une durée de vie effective de 5 ans, en supposant que iOS 10 soit lancé vers octobre. Il convient de noter qu'Apple ne prend pas toujours en charge la prise en charge de l'API graphique - Les iPhone 4s et iPhone 5 ne le font pas. disposent de l'API graphique Metal d'Apple, qui est un scénario quelque peu similaire à celui observé avec Android dans Vulcan. La seule différence est qu'Apple a continué à prendre en charge les anciens appareils sans la nouvelle API graphique.
Qu'en penses-tu? Allez-vous flasher une ROM personnalisée sur votre téléphone pour prolonger sa durée de vie? Avez-vous dit dans les commentaires ci-dessous.