Du magasin au rayon: une capitulation détaillée de la raison pour laquelle les périphériques MSM8974 sont exclus du nougat

Mise à jour pour refléter l'exigence de Vulkan ou 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 jeux de puces, et sur ce que cela signifie pour les périphériques qui vont de l'avant. Pourquoi cela a-t-il augmenté cette semaine?

Eh bien, il 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'il ne fournirait pas de support pour le MSM8974 (plus communément appelé Snapdragon 801) sur 7.0. Cet article a été écrit sous forme de collaboration avec bumble-bee, développeur reconnu.

Le sujet a suscité un vif 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 derrière la scène . Cet article explique un peu plus en détail le fonctionnement des mises à jour logicielles, en utilisant notre expérience de travail avec les constructeurs OEM pour leurs mises à jour officielles du microprogramme. Nous vous expliquerons en détail ce qui se passe dans les coulisses (et pourquoi) et pourquoi vous n'obtiendrez peut-être pas le dernier logiciel sur votre téléphone.

La première étape dans la vie d'une mise à jour de firmware Android est la mise à jour en amont. C'est ce que Google travaille en interne. Contrairement aux «flux de travail ouverts», Android est développé à l'aide d'un flux de travail fermé, le code source étant jeté par-dessus le mur chaque année ou à peu près, à la sortie d'une nouvelle version. À l'origine, Google avait déclaré que cela visait à empêcher la fragmentation due à l'utilisation de versions à la fine pointe de la technologie alors que la situation évoluait rapidement dans les premiers jours, mais ils semblent avoir maintenu cette politique en place.

À un moment donné, généralement avant l'annonce publique d'une mise à jour (bien qu'avec l'introduction récente de bêta publiques, ces échelles de temps changent), les constructeurs OEM seront informés de la mise à jour à venir . Ils recevront ensuite le code source à un deuxième moment pour la mise à jour finale (dans le passé, c'était parfois un peu avant le lancement, bien que nous sachions également qu'il n'y a pas de version anticipée).

Les référentiels AOSP en amont ne prennent en charge qu'un nombre limité de périphériques. Ce sont généralement vos appareils Nexus. Pour des raisons qui apparaîtront bientôt, il est toutefois important de noter que Google n’exerce aucun contrôle matériel sur ces appareils. les dispositifs sont fabriqués par un OEM et celui-ci achètera un système sur puce (SoC) auprès d'un fabricant de puces.

Une fois le code source publié, l'équipe du micrologiciel du fabricant OEM s'assiéra (au sens figuré) et se mettra sur ses pieds. L'arborescence source principale d'Android ne prend pas en charge matériellement la myriade de chipsets utilisés dans les périphériques d'expédition. Votre jeu de puces Qualcomm n'est probablement pas pris en charge par AOSP, par exemple. Votre Exynos ne l’est certainement pas. Mediatek ou HiSilicon? Oublie!

"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 progiciel de soutien de la carte (BSP) . Il s’agit d’un package super confidentiel de composants exclusifs, remis par un fabricant de puces à un OEM. Le BSP contient le code source nécessaire pour permettre aux constructeurs OEM de créer Android et les pilotes nécessaires à leur périphérique.

Il convient de noter ici que les OEM comme Qualcomm ne font pas nécessairement entièrement confiance à leurs partenaires: le BSP est disponible sur la base du "besoin de savoir". Les équipementiers n’ont généralement pas accès au code source de certaines des parties ultra-secrètes de l’appareil (telles que les logiciels exécutés sur la bande de base). Le fait de fermer cette partie présente également des problèmes potentiels, comme le montrent les vulnérabilités d’analyse ASN.1 presque nombreuses et récurrentes.

Le BSP contient les pilotes et les couches d'abstraction matérielle (HAL) nécessaires à l'exécution d'Android sur votre appareil. AOSP contient un ensemble de HAL, qui définissent ce que le système d'exploitation attend de vos pilotes. Pour utiliser un exemple ridiculement trop simpliste (et inventé, à des fins de démonstration), imaginons la lampe de poche de votre téléphone.

Un exemple HAL - Votre lampe de poche

Imaginons que votre appareil dispose d'une lampe de poche à l'arrière (si vous avez un Nexus 7 2013, vous devrez imaginer un peu plus que tout le monde - désolé!). Ceci est contrôlé par un pilote. Pour notre exemple incroyablement simple, supposons que la v1 HAL 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 à quelque chose comme ça:

vide setLED (bool ledState) {

// voici le code pour allumer ou éteindre la LED, basé sur ledState

}

Cette fonction est définie dans le code source BSP. Le BSP est ensuite compilé par le fabricant OEM lors de la création de la ROM et devient l'une des bibliothèques propriétaires «.so» sur la partition ou la zone du fournisseur de votre appareil. Cela permet à un fabricant OEM de garder certaines parties du fonctionnement de son périphérique secrètes. Pour le moment, supposons qu'ils veuillent empêcher tout le monde de voir comment ils allument et éteignent cette DEL.

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 s'agit-il de la technologie Flash adaptative ou simplement de forcer une mise à jour de HAL et de laisser les fabricants de puces en activité? Nous vous laisserons, en tant que lecteur, vous faire votre propre opinion à ce sujet. Certaines mises à jour de HAL présentent des avantages évidents (telles que le nouvel appareil photo HAL exposant la prise de vues au format RAW et similaires), alors que d’autres ont un objectif un peu moins clair.

Avec cette nouvelle HAL (fictive) pour la luminosité, supposons que Google indique que vous devez exposer à nouveau une fonction appelée setLED, mais cette fois avec un entier passé pour la luminosité. Maintenant, 0 l'éteindrait et 255 le mettrait en plein.

Si vous êtes le fabricant OEM, vous pouvez utiliser votre code super secret pour allumer ce voyant et l'intégrer à cette nouvelle fonction. Vous pouvez même utiliser une modulation de largeur d'impulsion pour ajuster la luminosité de la LED en fonction du nombre. Vous changez la fonction pour qu'elle ressemble à ceci maintenant:

void setLED (uint8_t ledBrightness) {

// un moyen exclusif ultra-confidentiel et ultra-confidentiel de régler la luminosité des LED

}

Et alors? Eh bien, maintenant cette nouvelle version d'Android est incompatible avec les "blobs" existants. Votre fabricant OEM doit utiliser ces nouveaux blobs, car le système d'exploitation Android s'attend à voir la nouvelle définition de la fonction et ne le "trouve" pas lorsqu'il cherche un moyen de régler le voyant.

À ce stade, examinons brièvement la manière dont les ROM personnalisées (construites à partir des sources) gèrent ici. C’est ce que les astucieux d’entre vous vont crier sur votre écran en ce moment - après tout, nous sommes le siège du HTC HD2, le téléphone le plus durable au monde… (juste pour mémoire, les génies fous là-bas utilisent Android 6.0 sur le HD2 ces jours-ci! Pas mal pour un téléphone livré avec Windows Mobile 6.5 en 2009)

Différentes approches sont utilisées ici - parfois, les développeurs piratent dans la ROM et demandent au système d’exploiter les anciennes définitions de fonctions. C'est un peu brouillon et apporte beaucoup de modifications à maintenir. L’autre approche consiste à “casser” le fichier binaire OEM.

L’approche «shim» consiste à écrire et à construire vous-même une toute petite bibliothèque contenant la définition de fonction attendue. Dans notre exemple, nous prendrions en charge l’entier pour la luminosité. Ensuite, dans la cale, cela est traduit pour répondre aux exigences de l’ancien HAL. Donc, pour notre exemple, nous pourrions peut-être dire que toute luminosité demandée au-dessus de 128 allumera le voyant et que tout ce qui se situerait en dessous l'éteindrait. Ou vous pouvez dire que tout ce qui n'est pas nul le mettra en marche. C'est au développeur. Ils compilent la cale et obligent Android à l'utiliser au lieu de la version native. La cale appelle ensuite le blob OEM.

Un rapide "adb push" et un redémarrage devraient vous permettre de commencer, et vous permettre de contrôler votre témoin fictif, même si vous n’avez que l’ancien HAL.

Le problème est qu'il s'agit clairement d'un processus imparfait. Vous allez maintenant avoir des bizarreries - cet appareil aura un flash plutôt minable, 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 tente de vous aveugler. Mais bon, la vie n’est pas parfaite et vous avez maintenant une DEL qui fonctionne sur votre ancien téléphone!

(Oui, c’est l’une des raisons pour lesquelles il existe des bizarreries et des bugs lorsque les utilisateurs et les développeurs gèrent leurs prouesses folles et insensées en matière de portage. Je veux dire, zut, le Galaxy S II est doté d’une ROM Android 6.0 apparemment utilisable. Beaucoup de Les téléphones sortis l'année dernière n'ont toujours pas la 6.0!)

Revenons au point de vue du constructeur. Malheureusement, la plupart des constructeurs OEM travaillent déjà au moins un téléphone avant la situation actuelle. Ils se concentrent sur le prochain téléphone qu'ils sont sur le point de vendre. Vous ne pouvez pas leur en vouloir, ils gagnent de l'argent uniquement 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 à publier de nouveaux appareils pour exister. C’est l’une des raisons pour lesquelles HTC et Blackberry ont des problèmes - peu importe le nombre de cadres qui conservent une emprise mortelle sur leur ancien Blackberry Curve, car ils n’obtiennent pas d’une nouvelle vente d’appareils.

Si le fabricant OEM ne reçoit pas de BSP, il ne va pas adopter l'approche consistant à pirater une version ensemble. Pourquoi? Eh bien, ils doivent prendre en charge ce firmware pour leurs clients . S'ils publient un micrologiciel qui fonctionne à moitié, les utilisateurs vont le détester, décrier, et laisser leurs lignes de support résonner pendant des jours.

Les équipementiers doivent également faire face à des transporteurs, du moins sur des marchés non européens. Les opérateurs ne veulent pas que les clients aient 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 grande tante Alice. C’est elle qui vous appelle à des moments de la journée qui ne vous conviennent pas pour demander de l’aide pour «ce truc d’ordinateur». Vous décrivez ensuite comment cliquer sur le menu «Démarrer» et le désigner comme «le grand drapeau dans le coin inférieur gauche», ce qui crée de la confusion. Environ 45 minutes (et beaucoup de frustration) plus tard, il en ressort que tante Alice a fait glisser son menu de démarrage sur le bord droit de l'écran et a simplement eu besoin de le faire glisser en arrière. Oui, avec le bouton gauche de la souris!

Maintenant, imaginez que vous avez mille tante Alice. Ils téléphonent tous à votre service clientèle, incapables de trouver Candy Crush sur leur téléphone, craignant qu'un pirate informatique ne les efface 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 leur téléphone?

Oui, cela est censé être un peu d'humour léger, mais jusqu'à ce que vous connaissiez les raisons pour lesquelles les gens appelleront leur opérateur, 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 de celui-ci entraînera une surcharge de support. Au minimum, cela nécessite une nouvelle formation du personnel de soutien (parce que la plupart d'entre eux ne sont pas votre lecteur assidu, malheureusement).

Une fois que le fabricant OEM a reçu le BSP, il transfère sa ROM et applique toutes ses modifications à la ROM. Ils vont s'entasser dans leur bloatware et ajouter une peau de dessin animé horrible qui aurait l'air plus à la maison dans l'anime d'un adolescent. Ensuite, ils vont le tester.

Beaucoup.

Votre téléphone doit satisfaire à toutes sortes d'exigences. Les réseaux de téléphonie mobile sont conçus pour faire confiance aux équipements des utilisateurs (ce que nous appelons le téléphone) pour qu’ils se comportent 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, il est donc nécessaire de tester à nouveau les choses. C’est pourquoi vous verrez souvent des informations sur les mises à jour logicielles Sony à venir provenant de services de test externes, confirmant 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 donnera pas au BSP un BSP mis à jour . Après tout, le fabricant de SoC n'en tirera pas grand chose. L'OEM ne gagne plus d'argent sur votre téléphone depuis sa vente. Et à ce stade, votre téléphone ne reçoit plus de mises à jour de version majeure.

Réduire le nombre de BSP livrés par les équipementiers est un excellent moyen d'économiser de l'argent. Si vous n'avez besoin que de l'actuel et que vous n'avez pas l'intention d'augmenter les versions, vous économiserez de l'argent sur l'achat initial de SoC et l'octroi de licences., mais au prix de quelques nerds en colère, se demandant pourquoi ils n’ont pas eu de 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 ne dispense les équipementiers de l’état actuel et désolant des mises à jour sur Android. Néanmoins, il y a de vrais défis ici.

De nombreux équipementiers sont à blâmer pour leur promesse excessive et pour la sous-performance inévitable que nous associons maintenant. La triste réalité est que, pour la plupart des constructeurs, les mises à jour logicielles ne sont qu'un désagrément dont ils pourraient se passer.

Le secteur de la téléphonie mobile est principalement coincé dans l’esprit des téléphones polyvalents. C'est-à-dire qu'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é inhérente à l’exécution d’un système d’exploitation généraliste complet, comprenant des centaines de bibliothèques externes, ce n’est plus une option. Ou du moins ça ne devrait pas l' être. Google a pris des 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'à tout récemment, le seul moyen d'obtenir des mises à jour de sécurité consistait en une nouvelle version majeure du système d'exploitation Android!)

Hélas, cependant, cela ne suffit pas vraiment. Même si Google publie régulièrement des mises à jour, la sécurité de votre appareil dépend toujours du fabricant de SoC. En effet, les fabricants de SoC sont tellement effrayés de voir quelqu'un allumer des DEL ou émettre un son via un haut-parleur. Ils envoient d'énormes quantités de gouttes binaires. sur leurs appareils. Ces blobs contiennent du code assez horriblement peu sûr (jetez un coup d'œil aux anciens bulletins de sécurité de Google si vous pensez que c'est une exagération!) Et ont besoin d'être mis à jour. Ce qui signifie que des BSP mis à jour sont requis.

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 portable ou votre tablette est en réalité un gros morceau de silicium, conçu par certaines personnes sensées, mais qui n'ont pas le temps de 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 les raccourcis sont utilisés - 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 un mode de démarrage différent. Sur votre ordinateur portable ou de bureau, toutefois, les fournisseurs ont opté pour certaines méthodes standard de démarrage: auparavant, il s’agissait du MBR (Master Boot Record) avec un BIOS, et à présent il s’agit du format UEFI. Cette normalisation permet d’exécuter le même logiciel sur chaque appareil.

Bien que certains progrès aient été accomplis récemment, en particulier avec le programme de diffusion externe 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 nombre considérable de nouveaux hacks spécifiques à chaque fournisseur introduits sur chaque périphérique.

La prise casque a-t-elle été branchée dans le mauvais sens? Il suffit de pirater les pilotes! Il n'y a pas de temps pour le réparer dans la conception de la production.

L’équipe de fabrication a monté le module de caméra à l’envers dans le lot de production 1? Lancez un piratage pour vérifier le code de la version interne et tournez la vidéo si c'est la version 1!

Des solutions comme celles-ci résolvent le problème immédiat, mais ne font que gratter la surface des changements étranges et spécifiques à un produit en cours. Heck, 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. Celles-ci conduisent à des piratages de la part des conducteurs et à des décisions étranges qui n’avaient de sens que pour le moment, pour que le téléphone fonctionne et qu’il soit expédié la semaine prochaine.

Bien que des travaux soient en cours pour assurer la prise en charge principale des puces ARM 64 bits à démarrer à l’aide d’UEFI, aucun mouvement clair n’a été réalisé vers un moyen plus standard de démarrer les périphériques ARM . Et c'est dommage, car cela signifie que les téléphones continueront à être éteints bien avant la fin de leur vie professionnelle, car il est tout simplement trop coûteux de maintenir la dette technique et le fardeau de leurs logiciels.

Par contre, si un OEM ne gagne que de l'argent avec la vente d'un appareil, ne doit-il pas s'assurer que les gens continuent d'acheter de nouveaux téléphones? Le marché des ordinateurs évoluerait-il vers ce modèle s'il n'y avait pas déjà 30 ans de logiciels existants et existants utilisant la plate-forme et la norme PC ouvertes?

C'est une question difficile sans connaissance interne de Qualcomm, ce que nous n'avons malheureusement pas pour le moment. Cependant, nous pouvons tirer certaines informations de l'API du pilote Android 7.0 et des exigences CTS. Les exigences CTS spécifient ce que Google attend d'un appareil exécutant un micrologiciel donné. Le «gros marteau» utilisé pour faire respecter ces exigences est l'octroi de licences par Google pour l'utilisation de leur ensemble exclusif de services Google Play. Si vous ne vous y conformez pas, vous ne pouvez pas envoyer Google Apps sur l'appareil . Bien que, pour certains, cela puisse ê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 à la couche HAL ou aux pilotes (comme décrit ci-dessus), il est donc peu probable qu'une incompatibilité vienne de là. Ce qui est plus susceptible de poser problème, cependant, est l’introduction d’une nouvelle exigence selon laquelle l’API graphique Vulkan, ou GLES 3.1, doit être disponible pour réussir le CTS.

À l'heure actuelle, de nombreux systèmes sur puce (SoC) n'ont pas pris en charge Vulkan sur leur processeur graphique, y compris le MSM8974. C’est aussi très probablement où le problème de la compatibilité avec Android 7.0 se posera. Encore une fois cependant, sans la connaissance interne de Qualcomm et de leurs projets futurs, il est difficile pour nous de donner une déclaration définitive sans le qualifier. Pour le moment, toutefois, nous pensons qu'il s'agit probablement du cas "simple" de Qualcomm qui a cessé de prendre en charge le chipset MSM8974 vieillissant (à leurs yeux) et ne fournit pas de BSP (paquet de support de carte) pour la version 7.0 sur cette plate-forme. Si tel était le cas, cela signifierait que les constructeurs seraient quasiment certains de ne pas expédier la version 7.0 sur le périphérique. Ils devraient en quelque sorte trouver le support Vulkan ou GLEs 3.1 pour leur GPU, et le code source du GPU est l’un des plus rigoureusement protégés. certaines parties des piles mobiles (sans aucune raison réelle, ajoutons - voir AMD, open source pour leur propre pilote AMDGPU sur le bureau pour Linux). Malheureusement, les graphiques Vulkan et accélérés (GLES) en général sont un peu plus complexes qu'une simple LED, c'est pourquoi nous ne verrons pas cela de la même manière.

Comme la version 7.0 n'est pas disponible depuis longtemps, il est possible que d'autres chipsets (autres que le petit nombre au sein de l'AOSP lui-même) soient laissés sur la version 6.0, en raison de problèmes de matériel et de pilotes (c'est-à-dire pas de BSP mis à jour) ou d'un manque du support des fournisseurs de SoC en ce qui concerne l’API Vulkan ou GLES 3.1. À l'heure actuelle, ni le Snapdragon 800 ni le 801 ne prennent en charge l'un d'eux.

Le mieux est de surveiller cet espace - les développeurs sur font déjà de bons progrès avec les ports non officiels à 7.0 pour de nombreux appareils qui ne bénéficient pas du support officiel de Google 7.0. Cependant, ceux-ci sont sans le support de Vulkan ou de GLES 3.1 - peut-être que les développeurs de jeux sur Android commenceront à éprouver de la frustration à travers la fragmentation si suffisamment d'utilisateurs commencent à exécuter des ROM personnalisées sans le support de Vulkan ou de GLES 3.1?

Apple a tendance à prendre en charge leur gamme iPhone sur la dernière version 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 pas la prochaine mise à jour iOS 10. cependant, 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 n'utilise pas toujours la prise en charge des API graphiques: les iPhone 4 et 5 ne disposent pas de l'API graphique Metal d'Apple, ce qui est un scénario assez similaire à celui observé avec Android dans Vulkan. La seule différence est qu'Apple a continué à prendre en charge les appareils plus anciens sans la nouvelle API graphique.

Qu'est-ce que tu penses? Voulez-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.