Avec les Android Extensions, Google pourrait réduire la fragmentation de son système

Avec les Android Extensions, Google pourrait réduire la fragmentation de son système

Enfin ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

11/11/2016 5 minutes
44

Avec les Android Extensions, Google pourrait réduire la fragmentation de son système

Le Compatibility Definition Document (CDD), qui explique aux constructeurs comment s’assurer que leurs appareils sont compatibles avec Android, vient d’être mis à jour. On y trouve une curieuse mention des « Android Extensions », qui laissent présager l’arrivée de bibliothèques partagées.

Avant de plonger dans les Android Extensions, il est nécessaire de rappeler certains points, liés de près à la fragmentation du système. Celle-ci n’est en effet pas si simple.

Android propose tout un lot de technologies fournies sous la forme d’API (Application Programming Interface), qui permettent aux développeurs de faire appel à ses fonctionnalités. Ces API sont réparties en deux grands lots, les unes dans la base du système, les autres dans les Services Google Play.

Les deux grands lots d'API dans Android

La base d’Android, c’est AOSP (Android Open Source Project), le socle open source du projet. Les API qui s’y trouvent se réfèrent toutes à des fonctions centrales, comme la gestion des fichiers, le démarrage, le noyau Linux, les paramètres, tout ce qui touche à l’interface, le contrôle du volume, l’écran verrouillé et ainsi de suite.

De leur côté, les Services Google Play se concentrent tout ce qui concerne les applications et les technologies de type Auto, Pay, les jeux, la gestion des DRM, la synchronisation, etc.

La différence entre les deux ensembles est importante car elle intervient dans la compréhension de la fragmentation d’Android, un sujet récurrent. Elle est évidente quand on inspecte les parts de marché de chaque version du système, mais elle ne se manifeste pas forcément dans le support des applications.

Pourquoi ? Parce que les Services Google Play sont mis à jour indépendamment du système, et cela passe par une nouvelle version diffusée sur le Play Store. Pour qu’une API d’AOSP évolue, il faut une mise à jour du système.

Le blocage des mises à jour par les constructeurs

La firme est bien placée pour savoir que diffuser les mises à jour d’Android est complexe, ce qui provoque un ralentissement de l’utilisation des API liées à AOSP. L’écrasante majorité des appareils vendus provient de constructeurs tiers, dont Google ne contrôle pas le cycle de mise à jour.

Même s’ils bénéficient d’un support garanti de 18 mois pour les mises à jour, la période est vite écoulée. Sans parler de tous les vieux appareils restent sur d’anciennes moutures, avec les énormes risques de sécurité que cela suppose.

Pour Google, la situation est problématique. Non seulement les critiques sur la sécurité sont nombreuses et régulières, mais les développeurs ne peuvent jamais profiter complètement des nouveautés puisqu’une immense majorité des appareils ne fonctionne pas sur les dernières révisions d’Android.

Une situation très différente par exemple de ce que connait Apple, puisque la même version d’iOS est diffusée simultanément à l’ensemble des appareils compatibles. Mais alors, comment sortir de cette impasse ?

Vers des API système déportées ?

Dans la nouvelle version du CDD (pour Android 7.0 Nougat), Google parle des Android Extensions. Il est question d’éléments que les constructeurs auraient l’obligation de charger, quelle que soit l’ampleur des modifications qu’ils apporteront au système.

En théorie, notamment selon nos confrères d’Ars Technica, cela permettrait notamment de déporter vers les Extensions tout un ensemble de briques du système, qui pourraient alors être mise à jour sur le même modèle que les Services Google Play.

En somme, diminuer le nombre d’éléments dont les constructeurs doivent s’occuper. Le texte indique clairement que ces Extensions seraient obligatoires, signifiant probablement au passage qu’elles ne peuvent pas être modifiées. Ars Technica précise qu’actuellement, ces Extensions ne contiennent que deux fichiers, pratiquement vides : GoogleExtShared.apk et GoogleExtServices.apk.

Pourquoi alors les rendre obligatoires ? Nos confrères suggèrent qu’ils seraient alors installés et donc pris en charge par le Play Store… qui pourrait les mettre à jour automatiquement.

GoogleExtServices serait ainsi l’équivalent des Services Google Play d’AOSP : un ensemble grandissant de briques que les constructeurs ne peuvent pas bloquer. Les mises à jour seraient plus régulières, permettant aux développeurs de profiter beaucoup plus rapidement des nouvelles API. GoogleExtShared est présenté comme une bibliothèque partagée, ce qui reviendrait à déporter du système de base des morceaux de code auxquels les applications doivent souvent faire face.

Il faudra sans doute attendre encore avant d’en savoir davantage, et de confirmer une telle possibilité, car Google n’a donné pour l’instant aucune explication complémentaire sur le sujet.

D’autres points importants dans le CDD

Même si les Extensions ont largement attiré l’attention des médias, d’autres éléments importants figurent dans la nouvelle version du CDD. Par exemple, il est désormais « fortement recommandé » aux constructeurs de ne pas s’appuyer sur des technologies propriétaires pour les recharges rapides sur les appareils mobiles.

Autre point significatif, l’obligation pour les constructeurs qui souhaitent utiliser Nougat de proposer un mode multifenêtre si la taille de l’écran le permet. Pour tous les autres, le mode peut être refusé lors de la phase d’implémentation.

Enfin, tous les appareils doivent être munis de capacité de blocage des appels. Même si ce type de fonction se retrouve presque partout, Google préfère manifestement s’assurer de sa présence.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les deux grands lots d'API dans Android

Le blocage des mises à jour par les constructeurs

Vers des API système déportées ?

D’autres points importants dans le CDD

Commentaires (44)


C’est très bon comme choix, et je suppose qu’étant donné que même les API Google sont déportés dans un .apk, ça permettra de s’en débarrasser encore plus facilement.


Très bon principe. Ca complète le nombre croissants d’applis du système qui se retrouvent sur le Play Store.



Cela étant dit avec les bibliothèques AppCompat, il y a quand même de moins en moins de difficultés à faire une appli pour toutes les versions qui conserve un aspect et des fonctionnalités similaires.


C’est une très bon choix pour l’adoption de versions récentes des APIs. Si pour toi ça signifie la possibilité de s’en débarrasser, tu vas te retrouver avec un système bien peu fonctionnel.








ErGo_404 a écrit :



Si pour toi ça signifie la possibilité de s’en débarrasser, tu vas te retrouver avec un système bien peu fonctionnel.





C’est un choix, et avoir plus de choix n’est pas préjudiciable en soi, bien au contraire. Ca permet à chacun de trouver chaussure à son pied.



Cyanogen propose une version android sans applis Google (qu’on peut ensuite installer si on a envie … ou pas), et le système est parfaitement fonctionnel.



Mais les android extensions sont des APIs du système Android, pas des machins proprios de Google.

Autrement dit, autant on peut imaginer un système qui n’utilise pas les Google services (c’est tout à fait de développer une appli sans), autant on ne peut pas se passer du framework de base d’Android.



EDIT : si tu veux comprendre ce que je dis, supprime un des fichiers .apk dans /system/framework/ <img data-src=" />


Ca veut aussi dire adieu aux optimisations de perfs pour un apparel précis sur tout ce qui se retrouverait dans ce machin à moins de rompre l’accès à la mise à jours auto pour les composants en question ?

Autant pousser un dpkg/yum pour gérer les bins critiques à ce niveau non ? ça ne m’amuse pas spécialement d’avoir des paquets qui prennent deux fois du stockage.


C’est pas encore la solution. La solution tout le monde la connait depuis le départ il suffit de l’appliquer : plutôt que de fournir un firmware par téléphone fournir à la place un programme d’installation d’OS comme Windows ou Linux sur PC qui s’installe sur n’importe quel téléphone ou tablette.


De ce que j’ai compris il demandent juste d’obliger le fonctionnement des api incluent dans cet androidExtension.

S’il veux faire à coté son truc proprio et optimisé pour ces applications, pas de problèmes.

En revanche il faut aussi qu’il supporte cela pour, par exemple, les applications qui se veulent génériques. et dont l’api sera mis a jour en fonction de google (et non des constructeurs).



Si j’ai bien compris c’est une très bonne chose, les constructeurs font toujours ce qu’il veulent, mais ne pourrons plus bloquer les mise à jours de sécurité parce que le téléphone à plus d’un mois et que c’est plus rentable de les faire racheter le prochain.



J’ai bon ? j’ai bon ?&nbsp;<img data-src=" />


J’ai du mal a voir comment on pourrait utiliser Android sans Play Store si les libs systeme deviennent des apk a charger obligatoirement sur le Play Store…


Cette nouvelle est bien pour les développeurs car ça réduira

effectivement la fragmentation de l’API level sur tous les nouveaux

devices Android.

Cependant, je ne suis pas convaincu du tout que ça

réglera les problèmes de sécurité étant donné qu’il n’y a rien de

nouveau pour forcer les constructeurs à mettre à jour le noyau qu’il y a

dessous toutes ces bibliothèques !!!








flagos_ a écrit :



J’ai du mal a voir comment on pourrait utiliser Android sans Play Store si les libs systeme deviennent des apk a charger obligatoirement sur le Play Store…





Il existe bien d’autres stores qui pourraient tout aussi bien diffuser ces apk (faut avoir confiance quand même…) mais dans tous les cas, un utilisateur de AOSP nu doit déjà s’occuper à la main de la mise à jour de ses apk donc je ne pense pas que ça change grand chose à ce niveau.



En effet la grande question pour les utilisateurs.



Ça ve rendre la sécurité meilleure à long terme ?


Il faudrait déjà savoir ce qu’ils vont y mettre concretement avant de répondre <img data-src=" />



Mais pour moi si ils font comme avec la webview avec leur bibliothèque multimédia (Stagefright) par exemple, ça peut déjà réduire le nombre de failles graves.



Maintenant il y aura toujours des failles que les OEM “devront” patcher (genre les failles liés au SOC ou noyau), mais au moins ça va dans la bonne direction niveau sécurité.


Et pourtant c’est bien problématique. Imaginons que Google sorte une nouvelle librairie d’accès a la ram dans ce joli petit apk. Parce que la nouvelle librairie ‘roxerait du poney’. Et ben adieu toute les appli qui implémente ça, a moins d’utiliser un truc genre Xposed et c’est loin d’être trivial !

A mon avis, c’est la mort a moyen terme des roms custom si l’envie en prend a Google.


Ah oui et tes applis dans le store officiel de Google qui tournent sur les rom officielles elles se débrouillent comment dans ta compréhension du problème ??


Malheureusement, si je comprends bien, cela ne concerne que certaines couches du système. Malheureusement, pour répondre aux problématiques de failles de sécurité, il faudrait que l’ensemble du système soit concerné, y compris (et surtout) les couches basses de l’Os comme le noyau Linux.



La meilleure solution serait de créer un standard de compatibilité et un bios/uefi contenant des interfaces d’abstraction matérielles.



Si google ne fait pas ce travail indispensable, les plateformes ARM/Android traîneront cette tare de naissance comme un boulet. Et un beau matin ils se réveilleront avec le standard PC/x86 qui reviendra en force sur les appareils mobiles…


C’est un peu mon avis aussi. Tout dépend de ce qui sera poussé dans ces extensions.



par contre, une petite question en passant. Si il y a moyen de mettre à jour des composants critiques de sécurité par un apk, ne risque-t-il pas de rendre possible en même temps les attaques contre ces mêmes composants, du fait que l’on puisse justement les mettre à jour ?


Comme quelqu’un l’a dit précédemment, c’est pas possible d’avoir une base comme windows et linux ?

Qu’on puisse installer sur n’importe quelle smartphone, avec dedans les driver pour qualcomm, mediatek etc ?


Peutêtre pas à ce point, mais intégrer un gestionnaire de paquets dans android, à la manière de Linux, permettrait clairement d’aider les choses. De mettre à jour telle ou telle partie du système (extension ou noyau) sereinement.

Et ça réduirait aussi la fragmentation du côté des roms Android/cyanogenmod customs.


+1 pour la sécurité.

Par contre j’ai PEUR pour quelque chose : ça permet à Google de déporter, tranquillement et de manière transparente, les APIs ouvertes et leur implémentation open source depuis AOSP vers des “blobs” que sont ces extensions, qui peuvent être… Propriétaires, à l’image des PlayServices.

J’ai donc peur, très peur pour l’avenir de AOSP.


Personnellement je n’attends que ça de voir le modèle foireux des smartphones imploser.



Mais c’est pas demain la veille. <img data-src=" />



Même si demain il était annoncé dans le monde entier qu’on pourrait récolter tout le contenu des smartphones de la planète en un claquement de doigt, ça continuerait à se vendre par paquebots entiers.

L’utilisateur final s’en fout.



Après tout, quand on balance toute sa vie sur des trucs sociaux, qu’est-ce qu’on peut en avoir à faire d’avoir des smartphones sans sécurité ?




Avec les Android Extensions, Google pourrait réduire la fragmentation de son système.





Réduire la fragmentation en “fragmentant” le système (core AOSP + extensions) ?



J’ai un doute. A moins d’imposer l’upgrade des extensions aux utilisateurs, on aura toujours une fragmentation entre ceux qui vont upgrader à-tout-va (au risque d’avoir des incompatibilité), et ceux qui conserveront ce qui marche (au risque d’être obsolète).



La décision de Google a davantage a voir avec la volonté de pousser rapidement les “nouveautés” sur les smartphones en circulation. Et par “nouveauté”, je veux dire des services stratégiquement important pour Google…








linconnu a écrit :



C’est pas encore la solution. La solution tout le monde la connait depuis le départ il suffit de l’appliquer : plutôt que de fournir un firmware par téléphone fournir à la place un programme d’installation d’OS comme Windows ou Linux sur PC qui s’installe sur n’importe quel téléphone ou tablette.









popo76 a écrit :



Comme quelqu’un l’a dit précédemment, c’est pas possible d’avoir une base comme windows et linux ?

Qu’on puisse installer sur n’importe quelle smartphone, avec dedans les driver pour qualcomm, mediatek etc ?





Dans cet article il y a les explications du pourquoi c’est compliqué :

http://www.nextinpact.com/news/101715-pour-linus-torvalds-x86-a-encore-beaux-jou…









Salamandar a écrit :



+1 pour la sécurité.

Par contre j’ai PEUR pour quelque chose : ça permet à Google de déporter, tranquillement et de manière transparente, les APIs ouvertes et leur implémentation open source depuis AOSP vers des “blobs” que sont ces extensions, qui peuvent être… Propriétaires, à l’image des PlayServices.

J’ai donc peur, très peur pour l’avenir de AOSP.







C’est pour moi l’énorme problème.

Avec ça Android basculerait du côté obscure. J’espère sur Google ne compte pas prendre ce chemin.









jackjack2 a écrit :



C’est pour moi l’énorme problème.

Avec ça Android basculerait du côté obscure. J’espère sur Google ne compte pas prendre ce chemin.





A cause de qui ? Des constructeurs qui ne jouent absolument pas le jeux des maj même sur des smartphones qui coûtent plusieurs centaines d’euros.



Franchement on ne peut pas dire qu’android soit très clair. Dans la mesure ou une partie d’un produit est d’emblée propriétaire ça casse un peu l’engagement libriste du promoteur !!!









wanou2 a écrit :



A cause de qui ? Des constructeurs qui ne jouent absolument pas le jeux des maj même sur des smartphones qui coûtent plusieurs centaines d’euros.



Franchement on ne peut pas dire qu’android soit très clair. Dans la mesure ou une partie d’un produit est d’emblée propriétaire ça casse un peu l’engagement libriste du promoteur !!!







Le problème, c’est qu’Android demande de customiser une ROM pour chaque appareil à chaque mise à jour, sans compter les tests…



Il est évident que pour les constructeurs, ce n’est pas gérable, ça coûterait trop cher.



Il faudrait des standard de compatibilité comme sur le PC, ce qui permet d’éviter de customiser l’Os pour chaque machine.









sr17 a écrit :



Le problème, c’est qu’Android demande de customiser une ROM pour chaque appareil à chaque mise à jour, sans compter les tests…



Il est évident que pour les constructeurs, ce n’est pas gérable, ça coûterait trop cher.



Il faudrait des standard de compatibilité comme sur le PC, ce qui permet d’éviter de customiser l’Os pour chaque machine.





Il est sans doute plus profitable de sortir 30 ou 40 références de smartphones non finis par an que de sortir 34 références solides et suivies mais c’est tout à fait gérable je pense. Après je pense que ce n’est pas une demande du consommateur.









wanou2 a écrit :



Il est sans doute plus profitable de sortir 30 ou 40 références de smartphones non finis par an que de sortir 34 références solides et suivies mais c’est tout à fait gérable je pense. Après je pense que ce n’est pas une demande du consommateur.







Le problème, c’est que pour gérer sérieusement la sécurité, il faudrait pouvoir mettre à jour les Os sur une base quotidienne. C’est ce que font toutes les bonnes distributions Linux.



Bien sûr, Apple arrive à gérer ce problème parce qu’ils sortent peu de modèles, qu’ils se vendent en très grand nombre et qu’il y a une bonne marge.



A l’inverse, le marché Android, c’est comme celui du compatible PC : des dizaines de constructeurs, une pléthore de modèles pour aller chercher tous les segments de marché, des marges réduites. Sans aucune standardisation, ce n’est pas gérable…










sr17 a écrit :



Le problème, c’est que pour gérer sérieusement la sécurité, il faudrait pouvoir mettre à jour les Os sur une base quotidienne. C’est ce que font toutes les bonnes distributions Linux.



Bien sûr, Apple arrive à gérer ce problème parce qu’ils sortent peu de modèles, qu’ils se vendent en très grand nombre et qu’il y a une bonne marge.



A l’inverse, le marché Android, c’est comme celui du compatible PC : des dizaines de constructeurs, une pléthore de modèles pour aller chercher tous les segments de marché, des marges réduites. Sans aucune standardisation, ce n’est pas gérable…





Sauf que ce n’est pas Android la cause du problème là mais ARM…

Dans le monde PC je prend un OS et je peux l’installer sur une machine au pire en mode compatibilité si j’ai du matériel exotique (vga, pas de touche macros, etc…) merci le bios/uefi.

&nbsp;

Sous ARM le bootloader n’est même pas standard…

Non là chacun fait à sa sauce dans son coin chez les fabriquants. Donc pour chaque config il faut réinventer la roue à chaque fois.

Bref pas un problème de marge, segmentation ou autre. Juste d’une plate-forme hardware où personne ne veut s’entendre avec le voisin…









-DTL- a écrit :



Sauf que ce n’est pas Android la cause du problème là mais ARM…

Dans le monde PC je prend un OS et je peux l’installer sur une machine au pire en mode compatibilité si j’ai du matériel exotique (vga, pas de touche macros, etc…) merci le bios/uefi.

 

Sous ARM le bootloader n’est même pas standard…

Non là chacun fait à sa sauce dans son coin chez les fabriquants. Donc pour chaque config il faut réinventer la roue à chaque fois.

Bref pas un problème de marge, segmentation ou autre. Juste d’une plate-forme hardware où personne ne veut s’entendre avec le voisin…







Je nuancerait tes propos.



Il faut garder à l’esprit qu’ARM n’est qu’un concepteur de processeur “fabless”. En tant que tel, ils sont très peu impliqués dans le design final des machines .



C’est peut être un tort, mais que je saches, Intel n’a pas écrit les bios des premiers PC.



Tu dit qu’Android n’est pas la cause du problème. Mais si Google avait édicté un standard de compatibilité et que la première machine sortie sous Android à l’initiative de Google avait été équipée d’un bios et d’un loader standard, la tournure des choses aurait peut être pris un autre chemin car les fabricants auraient certainement suivi le modèle.

Il aurait du reste été facile de créer un logo “compatible Android” dépendant du respect des specifications.



Cela étant dit, je rejoint ton avis sur le fait que personne ne semble se sentir très concerné par le problème et qu’on voit mal comment les choses pourraient évoluer. C’est pour cela que je pense que cela finira probablement par un retour du x86 et du standard PC.



Il ne faut pas oublier que la finalité n’est pas la meme: autant sur “compatible PC” le but c’est d’être compatible, autant sur mobile le but c’est d’être All in One: 1 seul chip pour faire le CPU, la mémoire, le SSD, l’alim de tous, les leds, les HPs, la caméra, la CG.



Bref: 1 chip = 1 BIOS


Je vois pas comment ils pourront mettre à jour le noyau Linux avec deux apk, faudra que le bootloader prévoit le démarrage de l’ancien noyau en cas de souci, et aussi les drivers seront incompatibles.


Ça ressemble fort à la béquille (feu) Google Gears tout ça.








sr17 a écrit :



Malheureusement, si je comprends bien, cela ne concerne que certaines couches du système. Malheureusement, pour répondre aux problématiques de failles de sécurité, il faudrait que l’ensemble du système soit concerné, y compris (et surtout) les couches basses de l’Os comme le noyau Linux.



La meilleure solution serait de créer un standard de compatibilité et un bios/uefi contenant des interfaces d’abstraction matérielles.



Si google ne fait pas ce travail indispensable, les plateformes ARM/Android traîneront cette tare de naissance comme un boulet. Et un beau matin ils se réveilleront avec le standard PC/x86 qui reviendra en force sur les appareils mobiles…







C’est bien possible, à moins que ces extensions ne soient un premier pas à la mise en place sur ARM d’un système de Bios/UEFI comparable à ce qui existe sur PC.



Sinon :





Enfin, tous les appareils doivent être munis de capacité de blocage des appels.





Ben il serait temps, parce que vu comme le mien est spammé… Exemple : un numéro de promotion m’a rappelé une bonne douzaine de fois sur trois semaines en tombant systématiquement sur mon bloqueur d’appels (appli tierce du Play Store envoyant chier les numéros hors contacts du téléphone)…









Commentaire_supprime a écrit :



Ben il serait temps, parce que vu comme le mien est spammé… Exemple : un numéro de promotion m’a rappelé une bonne douzaine de fois sur trois semaines en tombant systématiquement sur mon bloqueur d’appels (appli tierce du Play Store envoyant chier les numéros hors contacts du téléphone)…





C’est quoi?

Dois-je répondre est pas mal





sr17 a écrit :

La meilleure solution serait de créer un standard de compatibilité et un bios/uefi contenant des interfaces d’abstraction matérielles.



Avant cela Il faudrait aussi revoir la conception hardware et avoir un standard hardware.



Car sinon il impossible de savoir que tel ou tel périphérique est à telle ou telle adresse.

&nbsp;

Il faudrait également changer les bus pour avoir des bus avec détection de périphérique (par exemple tout migrer de l’i2C vers de PCI express) ce qui risque d’augmenter les coups.








jackjack2 a écrit :



C’est quoi?

Dois-je répondre est pas mal







C’est une appli qui s’appelle Bloqueur d’Appels, tout court. Très basique (blocage liste noire/liste blanche) mais fait le job.



Dans ce cas, faut utiliser un CPU à archi x86 et pas ARM car cette dernière est absolument non standardisée.








Gilbert_Gosseyn a écrit :



Dans ce cas, faut utiliser un CPU à archi x86 et pas ARM car cette dernière est absolument non standardisée.





Qu’est ce qu’il ne faut pas entendre.



Il y a certes de la diversité dans les versions successives d’architecture ARM, mais tout est présent pour savoir où met les pieds, avec en plus des tonnes de rétrocompatibilité. Un peu comme … avec x86 finalement, où il faut savoir si on parle au 64b ou au 32b (qui se fait rare, mais qu’Intel utilise toujours, cf. quark), et aussi se demander quel niveau de SSE on va utiliser, et aussi si on va utiliser AES-NI ou pas …



C’est pas à ce niveau là que x86 est plus simple que ARM, mais bien au niveau plateforme.

x86, on part du principe que c’est un PC, et on scanne les bus.

ARM, on ne sait rien, et on compte sur le fournisseur, qui souvent ne mérite pas ce nom très longtemps.









CryoGen a écrit :



Ah oui et tes applis dans le store officiel de Google qui tournent sur les rom officielles elles se débrouillent comment dans ta compréhension du problème ??







Ben elle s’en moque en fait, elles utilisent juste un sdk à jour, et l’apk qui va bien sera pousser par le play store, obligatoire sur toutes les mouture android “officielles”. Comme je l’ai dit, “Si l’envie leur en prend”. Sachant bien sur que ça n’empêcherait pas les roms custom de fonctionner si on installe l’APK qui va bien. Mais alors on perd toute la justification d’une rom non-officielle (j’entends par la compilé depuis AOSP hein, pas juste un unzip, rm, re-zip d’une rom officielle). Voir pire, si l’envie prend à Google de bloquer l’install du fameux APK si la ROM n’est pas “Google Safe” parce que “la sécurité de nos travailleurs utilisateurs est un enjeu majeur en ces temps troublé bla bla bla”



Il n’y a pas de standard unique façon x86 ou x86-64 : un code pour puce Qualcomm ne tournera pas forcément sur une puce Mediatek ou Exynos. Alors qu’un code x86 ou x86-64 tournera indifféremment sur un AMD ou un Intel (voire du VIA).


Toujours aussi faux.

Si j’écris du code ARM propre, il tourne sur tous les CPU ARM que je veux

Si j’écris du code x86 sale, il ne tournera pas sur tous les CPU x86.



Ce n’est pas le jeu d’instruction qui est en cause mais l’accès aux périphériques.


Encore uen fois, non : une puce ARM intègre les instructions de base ARM certes (valable normalement sur tous les CPU de ce type, encore que …), mais le souci est que chaque CPU ARM dispose de son propre “à coté” qui est tout sauf standard. La est le problème.


C’est bien ce que je dis: Cet «à côté» concerne les périphériques.

Le genre de chose qu’une application n’accède pas directement, mais par le biais de l’OS.



Et qu’on OS bien fait accède par le biais de la couche HAL, soit dit en passant.



Donc une application pourra tourner sur une large gamme de CPUs ARM différents pourvu que l’OS qu’elle utilise y soit disponible (et c’est là que c’est pas gagné). Évidemment, si je décide de compiler en 64bits, ça ne marchera pas sur les CPUs 32b exclusivement.



C’est vrai aussi sur x86. Si je compile en 64b, faut pas se plaindre si ça ne marche pas en 32b (Intel en sort encore, pour l’embarqué). Si j’utilise directement les plus récentes instructions, ça ne marchera pas sur les CPUs un peu plus vieux, ou sur les CPUs d’un «autre» fabricant qui n’ont pas encore intégré ces dernières évolutions.



Le gros avantage du x86 pour l’auteur de l’application, c’est bien que la question de savoir si l’OS est disponible pour la plate-forme matérielle visée ne se pose normalement pas, grace au fait que tous les périphériques sont derrière un bus énumérable connu.

&nbsp;