Connexion
Abonnez-vous

Google ARC : les applications Android se promènent dans Chrome

Tout du moins certaines d'entre elles

Google ARC : les applications Android se promènent dans Chrome

Le 08 avril 2015 à 06h30

Google a publié récemment une nouvelle version d’ARC, son « App Runtime for Chrome ». Même s’il manque encore de nombreux éléments, il n’est pas impossible que l’ensemble du parc applicatif d’Android puisse un jour fonctionner dans le navigateur, au prix de quelques changements dans le code.

Le début du support des API Google Services

App Runtime for Chrome est un projet lancé officiellement en septembre dernier. Il devait initialement permettre aux applications Android de fonctionner dans Chrome OS, mais certains développeurs n’avaient cependant pas tardé à modifier le projet pour qu’il supporte Chrome. En outre, même s’il était basé sur NaCl (Native Client) et permettait donc en théorie aux applications d’obtenir des performances presque natives, de nombreuses API étaient absentes, notamment celles des Google Services. D’autre part, ARC se sert de la machine virtuelle Dalvik (Android 4.4) pour lancer les applications et non pas ART (Android Runtime) apparu avec Lollipop (voir cette actualité).

La nouvelle mouture du projet ajoute officiellement le support de Chrome et propose six de ces API : OAuth2, Google Cloud Messaging, Google+ sign-in, Maps, Location et Ads. Comme le signale Ars Technica, c’est évidemment très loin de représenter l’ensemble des fonctionnalités, mais cet ajout débloque la situation pour une partie des applications. D’après nos confrères, certaines d’entre elles, à l’instar de Twitter, fonctionnent désormais sans problème, tandis que beaucoup d’autres ne peuvent pas être lancées ou plantent. 

Pas de fonctionnement des applications sans changements spécifiques

Il ne suffit pas en tout cas pour un développeur de prendre son application et de la lancer dans Chrome via ARC. Son fonctionnement réclame des changements dans le code, en activant spécifiquement le support de la version spéciale des Google Services et en ajoutant des références aux métadonnées du Runtime. Google propose toutefois ARC Welder, dont la mission est justement de convertir un fichier APK classique pour y opérer les changements nécessaires de manière automatisée.

Il ne suffit donc pas d'ouvrir n'importe quelle fiche d'application sur le Play Store pour la lancer via Welder. Il faut récupérer les fichiers APK et faire ses tests manuellement. Il existe plusieurs méthodes pour récupérer ces fichiers, mais l'APK Downloader d'Evozi est sans le doute le plus simple : il suffit de lui indiquer le lien de l'application dans le Play Store de Google pour qu'il en récupère le fichier. De là, on peut alors lancer Welder depuis les applications Chrome et se laisser guider par l'assistant.

ARC WelderARC WelderARC WelderARC Welder

Même si certaines applications ne sont pas adaptées, Google recommande de toujours sélectionner l'orientation « Landscape » (paysage) et « Tablet » dans la rubrique Form Factor. D’après nos tests, le comportement de Welder peut se révéler capricieux. Il a ainsi bien voulu fonctionner sur une installation Windows 8.1, mais pas sur une autre, sans causer non plus de difficultés sur un Mac sous Yosemite. Du côté des applications, les résultats sont très variables et Twitter, Instagram, WhatsApp ou encore Telegram se sont par exemple lancées sans faire d’histoires. D'autres par contre, notamment Firefox et Facebook, ont planté au démarrage, affichant simplement un écran et une icône blanche.

Dans le cas des applications fonctionnelles par contre, aucun problème particulier n'était à recenser. Sachez cependant que Welder ne permettra pas de garder l'état de plusieurs applications en même temps. Si vous lancez par exemple Instagram et que vous comptez vous en resservir, il ne faudra ouvrir aucun autre APK. Dans le cas contraire, le dossier créé est supprimé par la nouvelle application. Il n'est pas impossible cependant qu'une prochaine évolution d'ARC Welder sache garder plusieurs profils d'applications.

ARC WelderARC Welder
Twitter fonctionne, mais pas Firefox

Mais même si le projet nécessite encore beaucoup de travail, ne serait-ce que pour supporter le reste des API des Google Services, on peut aisément entrevoir le débouché final. Les développeurs pourraient ainsi faire fonctionner leurs applications Android n’importe où, puisque Chrome se retrouve sous Windows, OS X, Linux et bien entendu Chrome OS.

Vers des applications universelles à la Google ?

Pour l’instant, le projet est clairement destiné aux développeurs. Mais Google pourrait très bien dans l’avenir pousser vers une stratégie « d’applications universelles » qui lui permettrait alors de tenir peu ou prou le même discours que Microsoft : un seul code pour toutes les plateformes. Car si une application Android pouvait fonctionner de manière quasi-transparente sous Chrome, elle pourrait alors être utilisée partout ou presque.

Mais la route sera probablement encore longue, car il y aura de sérieuses barrières à abattre. D’une part, il faut que l’ensemble des API des Google Services soient proposées afin que toutes les applications puissent fonctionner correctement. D’autre part, et surtout, il faut que le fait de lancer une telle application dans un navigateur ait un intérêt. Prévue pour un écran de smartphone ou de tablette, il n’est pas certain en effet que son interface se prête à la fenêtre d’un navigateur, même si le cadre s’en adapte automatiquement. En outre, même si une partie des ordinateurs est vendue aujourd’hui avec des écrans tactiles, beaucoup s’utilisent au clavier et à la souris, ce qui nécessite des adaptations dans l’ergonomie, comme l’a appris douloureusement Microsoft avec Windows 8.

Commentaires (51)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Marrant, j’ai voulu tester Chrome dans Chrome et ça n’a pas fonctionné.



En tout cas, je pourrais peut-être enfin utiliser certains de mes jeux Android.

votre avatar

Je ne suis pas sûr que l’arc Welder sache interpréter les lib linux que contiennent les applis qui utilisent le NDK. C’est peut être déjà une première piste pour expliquer le nombre d’applis qui plantent misérablement au démarrage.

 

votre avatar

Cool je vais pouvoir utiliser gmail dans chrome.

Oh Wait

votre avatar

Moi, je trouve ça génial… Enfin, quand ça va fonctionner, ce sera génial…

votre avatar

Ça évitera d’installer BlueStacks pour jouer à tel ou tel jeu sur PC <img data-src=" />

votre avatar

Ce serait pas mal à la Amazon (je ne sais pas si ça existe encore) de pouvoir tester les app directement dans le store.

votre avatar

ça va être utile pour les tablettes sous windows! <img data-src=" />

votre avatar

Chrome sandbox les app et offre des lib de bases identiques que ce soit sous Linux, Windows ou mac. une seule compilation pour tous les OS, mais par architecture, ça c’est NPAPI, c’est libre, ça utilise GCC.



Avec PNPAPI, une seul compilation pour tous les OS ET toutes les arch, c’est libre, ça utilise LLVM. c’est quand même super simple à comprendre pour une moule un peu moins neuneu que la moyenne.



à votre avis, pourquoi les vrais aiment bien Chrome ?&nbsp;



&nbsp;

votre avatar

pitié, t’en es à combien de commentaire comparant ActiveX/Sylvestrelight et NaCL? à croire que tu bosse chez MS pour avoir une interprétation aussi personnelle de la réalité..



Allez, je fais mon généreux, pour la nieme fois :&nbsp;

1 - c’est portable, là où Chrome est portable

2 - c’est TOTALEMENT sécurisé (oui, puisque le but est d’isoler le programme de l’OS, CONTRAIREMENT à ActiveX)

3 - c’est Open Source, jusqu’au bout des ongles (c’est pas une petite différence)

4 - ça n’a strictement rien à voir : ça consiste à utiliser de vieux composant logiciel dans le navigateur (entre autre), sans accéder à l’OS alors qu’ActiveX/Sylverlight consiste soit à concurrencer Flash/Applet java, soit à utiliser des composants de l’OS…

votre avatar







TheDidouille a écrit :



Chrome sandbox les app et offre des lib de bases identiques que ce soit sous Linux, Windows ou mac. une seule compilation pour tous les OS, mais par architecture, ça c’est NPAPI, c’est libre, ça utilise GCC.



Avec PNPAPI, une seul compilation pour tous les OS ET toutes les arch, c’est libre, ça utilise LLVM. c’est quand même super simple à comprendre pour une moule un peu moins neuneu que la moyenne.



à votre avis, pourquoi les vrais aiment bien Chrome ?&nbsp;



&nbsp;





NaCL et PNaCL à la place de NPAPI et PNPAPI… faut que je dorme moi


votre avatar

aucune appli testée ne marche sur Win7. Faut-il être obligatoirement sur 8.1 ?

votre avatar

non ça sera uniquement lié à ta version de Chrome. Tu peux essayer de passer à une version Canary pour avoir de meilleurs résultats … mais pour moi ça n’a rien changé ^^&nbsp;



Mais il ne faut pas oublier que c’est une version beta, donc faut pas s’attendre non plus à des miracles …

votre avatar

Thanks :-)&nbsp;



&nbsp;oui, à voir. J’étais tenté par déporter Whatzapp sur l’ordi.&nbsp;

A re tester à la maison.

votre avatar







blamort a écrit :



Thanks :-)&nbsp;



&nbsp;oui, à voir. J’étais tenté par déporter Whatzapp sur l’ordi.&nbsp;

A re tester à la maison.





Whatsapp tourne! Bon après ya déjà la webapp pour whatsapp tout en material design qui fait bien le job quand même… Voir sur Chrome OS ça roule bien :&nbsp;screen

&nbsp;

Par contre l’app sur ton tel va criser, car tu t’es mis à utiliser Whatsapp sur un “autre téléphone”.&nbsp;


votre avatar







zaknaster a écrit :



Whatsapp tourne! Bon après ya déjà la webapp pour whatsapp tout en material design qui fait bien le job quand même… Voir sur Chrome OS ça roule bien :&nbsp;screen

&nbsp;

Par contre l’app sur ton tel va criser, car tu t’es mis à utiliser Whatsapp sur un “autre téléphone”.&nbsp;





Yep, mais avec l’iphone, pas encore de webapp… C’est pour cela que cette solution m’intéressait

mmm.. ok, enregistration à refaire donc…. meme soucis que via mon server whatzapp sur rpi…&nbsp;


votre avatar

Question : cela ne concerne que Chrome ou les navigateurs basés sur Blink pourront également en profiter ?&nbsp;

votre avatar

C’est une extention sur Chrome, donc pour moi, si il est compatible avec les extensions Chrome, alors c’est possible.



Et d’ailleurs si vraiment, comme la rumeur semble l’indiquer, Spartan est compatible avec les extensions Chrome, ça pourrait vouloir dire, des applications Android dans Spartan&nbsp;<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





<img data-src=" />

votre avatar







atomusk a écrit :



C’est une extention sur Chrome, donc pour moi, si il est compatible avec les extensions Chrome, alors c’est possible.



Et d’ailleurs si vraiment, comme la rumeur semble l’indiquer, Spartan est compatible avec les extensions Chrome, ça pourrait vouloir dire, des applications Android dans Spartan&nbsp;<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





<img data-src=" />





Ce serait cocasse, par contre je ne sais pas qui de Google ou MS serait gagnant dans l’affaire.

Pour MS cela&nbsp;lui permettrait de présenter des machines Windows qui réunissent le meilleur du desktop et de la mobilité mais enterrerait peut-être l’intérêt de WinRT auprès des dev avec des conséquences facheuses à terme.

Pour Google ce serait un sérieux coup de pouce aux OS MS.



Par contre pour l’utilisateur d’une Surface par exemple c’est tout bénéf.

&nbsp;


votre avatar

Pour moi, tout ce qui fait qu’un dev se dit “développer pour Android est indispensable” est tout bénéf pour Google&nbsp;<img data-src=" />&nbsp;…. parce que au final, c’est le “material design qui prédominera et non pas le “modern UI” … que les outils de dev Google seront préférés à Visual Studio, et que les services google seront préférés (pour avoir une version portable android / Windows … )



Mais bon, c’est quand même de grosses spéculations sur absolument rien d’officiel&nbsp;<img data-src=" />

votre avatar







atomusk a écrit :



Pour moi, tout ce qui fait qu’un dev se dit “développer pour Android est indispensable” est tout bénéf pour Google&nbsp;<img data-src=" />&nbsp;…. parce que au final, c’est le “material design qui prédominera et non pas le “modern UI” … que les outils de dev Google seront préférés à Visual Studio, et que les services google seront préférés (pour avoir une version portable android / Windows … )



Mais bon, c’est quand même de grosses spéculations sur absolument rien d’officiel&nbsp;<img data-src=" />





On est d’accord.&nbsp;

Et depuis le changement de CEO, MS mise tout sur ses services et leur présence partout. W10 est je pense là pour permettre à WinRT et au Store de décoller, je pense donc que MS fera tout pour empêcher un cheval de Troie de Google.

D’ailleurs c’est peut-être bien une réponse de Google à MS.


votre avatar

Après on verra à quoi ressemble W10 au final.

votre avatar







Oryzon a écrit :



D’ailleurs c’est peut-être bien une réponse de Google à MS.





C’est surtout un retour à la raison qui met fin à la situation absurde où Google développait 2 OS (Android et ChromeOS), deux environnements applicatifs (Android et Applications Chrome), où l’utilisateur ne comprenait plus rien. Là on peut espérer un peu plus de collaborations entre les équipes Chrome/ChromeOS et Android.

&nbsp;



&nbsp;


votre avatar

On verra ce que donnera Win10, ce que donnera Arc (qui pour l’instant semble avoir des compatibilités limités), ce que proposera Microsoft sur Spartan …….&nbsp;



De toute façon les prochains mois devraient être intéressants &nbsp;<img data-src=" />

votre avatar







alexandredenis a écrit :



C’est surtout un retour à la raison qui met fin à la situation absurde où Google développait 2 OS (Android et ChromeOS), deux environnements applicatifs (Android et Applications Chrome), où l’utilisateur ne comprenait plus rien. Là on peut espérer un peu plus de collaborations entre les équipes Chrome/ChromeOS et Android.

&nbsp;



&nbsp;





Ouais enfin moi ça me parait pas délirant que des applis natives sur un OS desktop fassent autre chose que sur un OS smartphone.

Parce que si ChromeOS se résume à faire tourner des applis Android autant dire que ChromeOS ne sert à rien.&nbsp;


votre avatar







arno53 a écrit :



La technique utilisé est moins élégante que WinRT mais elle aura clairement un impact majeur sur la stratégie de Microsoft… A terme le développement sur WinRT sera peut-être complètement abandonner par les développeurs car Android/Chrome sera la voie royale pour toucher le gros des smartphone et l’ensemble du parc PC…&nbsp;



Juste les les smartphone android, les versions mobiles de chrome n’embarquent pas pnacl…

Et microsoft dispose encore d’un large avantage avec .net, car mieux pensé et plus confortable.

&nbsp;Bref si l’objectif de tel ou tel boite c’est de faire du desktop first, ils vont pas s’emmerder à faire le projet avec l’android framework… :°


votre avatar

Non.

votre avatar

Pourquoi pas ?&nbsp;<img data-src=" />

votre avatar

Parce que Microsoft n’intégrera pas pnacl à Spartan, y’a 4000 raisons contre ça.

votre avatar

Là dessus on est d’accord … mais alors ils ne pourront pas annoncer le support des extensions chrome.

votre avatar

Pas l’ensemble des extensions/app en tout cas, y’a tres peu d’extension qui tirent partie de PNaCl, mais chrome dispose de pas mal d’api propre à lui pour le bon fonctionnement de ses app.

Genre le filesystem api qui est pas mal utilisé dans les application offline de chrome, et qui a été refusée simplement sous pression de Mozilla qui avait comme seul argument “C’est facile à implement, mais je sais pas à quoi ça sert! donc non lol” (bon depuis janvier un gars de chez Mozilla à relancer un draft à ce sujet, ces mecs là ont aucun respect).



EDIT: Et tres honnêtement j’y crois pas à la rumeur du support des extension chrome, si MS voulait prendre un systeme existant je pense qu’il s’orienterait plus vers celui de firefox, beaucoup plus standard…

votre avatar

Oui mais alors ce sera plus ARC dans ce cas.

votre avatar

Petit cheval de troie :)

Dommage que MS ne joue pas le même jeu plus sérieusement de son coté avec mono…

votre avatar

oui, c’est probable que le problème vienne des fonction NDK, ils auront potentiellement à trafiquer &nbsp;une nouvelle cible de compilation “Chrome” dans leurs NDK ..



Mais c’est définitivement interessant comme idée, à voir si ils vont pousser fort ces nouvelles possibilité, et si les utilisateurs sont réceptifs …



Par contre, çà risque de devenir un nouveau vecteur de faille de sécu dans chrome, ce qui n’est pas forcement idéal&nbsp;<img data-src=" />

votre avatar

A priori ces applis sont bien sandboxées, elles n’ont pas accès au reste du navigateur. Par contre je ne vois pas trop l’intérêt pour Chrome sur PC, à part faire le cadeau à Microsoft de la compatibilité avec toutes les applis Android.

votre avatar

Faire de Chrome le navigateur indispensable et du dev Android un environnement de développement “universel” suffira à compenser le fait d’offrir à Microsoft la “compatibilité Android” je pense&nbsp;<img data-src=" />



Va falloir que je teste ça suer mon app moi&nbsp;<img data-src=" />

votre avatar

Bon je viens de faire quelques petits tests :




  • Chargement et lancement d’un app destinée à la préparation d’examens via des fichiers .vce. Ca marche bien, et on retrouve nos fichiers dans le dossier /vendor/chromium/crx <img data-src=" />

  • Tentative de charger une seconde app via ARC Welder, ça supprime la précédente. Normal certainement, ce n’est qu’un outil de dev après tout.

  • Tentative de packager l’app en .crx -&gt; cela permet d’avoir plusieurs apps en parallèle, en revanche l’app des VCE ne fonctionne plus ainsi.

  • L’application de la TV d’Orange ne fonctionne toujours pas quant à elle. ^^;

votre avatar







ErGo_404 a écrit :



Je ne suis pas sûr que l’arc Welder sache interpréter les lib linux que contiennent les applis qui utilisent le NDK. C’est peut être déjà une première piste pour expliquer le nombre d’applis qui plantent misérablement au démarrage.

&nbsp;





Si si ca marche , j’ai une appli qui embarque entre autre ffmpeg et un décodeur h264 écrit en C via le NDK et ça fonctionne sans problème ( à ma grande surprise). Après il faut que le code C et les libs soit dispo pour x86 et pas seulement Arm


votre avatar
votre avatar

En même temps, c’est très concis comme avis. Je ne peux que te suivre dans ton raisonnement.

votre avatar







EMegamanu a écrit :



En même temps, c’est très concis comme avis. Je ne peux que te suivre dans ton raisonnement.





quoi que le second paragraphe me laisse septique…


votre avatar

Celui où il a redéfini la constante de Landau-Ramanujan, lui permettant de prouver que tout problème appartenant à NP appartient aussi à P ?



S’il dit vrai, il n’y aura pas que la conversion d’applications Android en applications Chrome, mais aussivers Windows RT et Amstrad CPC qui seront facilitées. Un futur prix Turing et une médaille Fields en perspective !

votre avatar

Bon bah mon app fonctionne pas dessus … peut être que c’est la lib flurry :/ &nbsp;… faudrait que je fasse des tests ….

votre avatar







Tiebor a écrit :



ça va être utile pour les tablettes sous windows! <img data-src=" />







Bah oui…



Il y a des apps géniales qui existent sous Android et pas sous Windows. Ça pourrait réunir le meilleur des deux mondes.&nbsp;

En tout cas Arc Welder serait bien mieux que les emulateurs “BlueStacks” et compagnie.

&nbsp;

Mais aucune des applis que j’ai testé ne marche… (ex : Candy Crush Saga, N64oid, PowerAmp, …).



Bonne Idée malgré tout et à suivre de près.


votre avatar

Sous Linux c’est normal, les exécutables sont les mêmes (tant que c’est compilé en x86 comme tu le dis). Mais tu es en train de dire que ça fonctionne sous Windows ?

votre avatar







EMegamanu a écrit :



Bon je viens de faire quelques petits tests :




  • Chargement et lancement d’un app destinée à la préparation d’examens via des fichiers .vce. Ca marche bien, et on retrouve nos fichiers dans le dossier /vendor/chromium/crx <img data-src=" />

  • Tentative de charger une seconde app via ARC Welder, ça supprime la précédente. Normal certainement, ce n’est qu’un outil de dev après tout.

  • Tentative de packager l’app en .crx -&gt; cela permet d’avoir plusieurs apps en parallèle, en revanche l’app des VCE ne fonctionne plus ainsi.

  • L’application de la TV d’Orange ne fonctionne toujours pas quant à elle. ^^;





    voir ce lien de korben -&gt;http://korben.info/app-android-mac-linux-windows.html (22 septembre 2014)

    il y a possibilité de faire tourner plusieurs APK en même temps, avec une extension spécifique qui se base sur ARC de Google.

    edit : par contre, je ne sais pas si cette extension va suivre la mise à jour récente de ARC de Google.


votre avatar

La technique utilisé est moins élégante que WinRT mais elle aura clairement un impact majeur sur la stratégie de Microsoft… A terme le développement sur WinRT sera peut-être complètement abandonner par les développeurs car Android/Chrome sera la voie royale pour toucher le gros des smartphone et l’ensemble du parc PC…



Face à ça, je ne suis pas sûr que MS puisse réellement répondre avec autant d’impact.. Vivement la Build pour savoir si Microsoft a les moyens de proposer les API WinRT sur Android sans que Google puisse le bloquer.. Sinon reste le plan B à la Xamarin mais bon ça ne vaudra pas la simplicité du Java/Android sur Windows via Chrome…



Bon au final c’est une résurrection des principes d’ActiveX, Silverlight ou Flash mais en sandboxé ce qui ne peut être que mieux..

votre avatar

Oui , je n’ai testé que sous windows. Et c’est d’ailleurs assez performant , 25% de cpu sur un malheureux core i3 1.8Ghz avec 4 decodeur H264 (bon petite résolution tout de même)

votre avatar







TheDidouille a écrit :



pitié, t’en es à combien de commentaire comparant ActiveX/Sylvestrelight et NaCL? à croire que tu bosse chez MS pour avoir une interprétation aussi personnelle de la réalité..



Allez, je fais mon généreux, pour la nieme fois : 

1 - c’est portable, là où Chrome est portable





Ca tombe bien les applis Silverlight et Flash ou Applet Java sont portable là où Silverlight/Flash/Java étaient portés …





TheDidouille a écrit :



2 - c’est TOTALEMENT sécurisé (oui, puisque le but est d’isoler le programme de l’OS, CONTRAIREMENT à ActiveX)





Ca tombe bien j’ai écris “une résurrection des principes d’ActiveX, Silverlight ou Flash mais en sandboxé ce qui ne peut être que mieux”





TheDidouille a écrit :



3 - c’est Open Source, jusqu’au bout des ongles (c’est pas une petite différence)





Ouais … Je vois pas bien ce que ça change dans le principe du truc …

Des choses proprio sont devenues des “standards” industriel de part leur avantages (jadis Flash, H264) …

Flash aurait été sandboxé dès sa conception (et bien codé ^^), il ne serait pas traité comme un pestiféré comme il l’est aujourd’hui.

Aujourd’hui on a un projet open-source Chromium-Centric que MS et Mozilla devront (forcement) intégré (à terme) plus ou moins de force, poussé par l’industrie comme Mozilla intègrera les DRM (blob-binaire) de l’Encrypted Media Extensions du W3C plus poussé par Netflix et Youtube (Google) que part le plaisir de supporté ce “standard W3C”…

On est encore loin du projet Open-Source porté par tous les acteurs du marchés … mais ça viendra surement … Je te l’accorde <img data-src=" />





TheDidouille a écrit :



4 - ça n’a strictement rien à voir : ça consiste à utiliser de vieux composant logiciel dans le navigateur (entre autre), sans accéder à l’OS alors qu’ActiveX/Sylverlight consiste soit à concurrencer Flash/Applet java, soit à utiliser des composants de l’OS…





Active X est l’équivalent du NPAPI … Mais le seul avantage du PeperPAPI c’est justement le sandboxage qu’apporte NaCl. Là la solution ARC ou PNaCl ce sont juste des API type Flash/Java/Silverlight sandboxé et dispo sur 2 architectures (comme l’étais Flash/Java/Silverlight) …


votre avatar

Donc en gros on va bientôt se taper sur les sites de banques “installer Chrome pour installer notre application” là où on avait “installer Flash/Java/Silverlight pour lire/exécuter ce contenu” …



Donc pendant un certain temps on va se retrouver avec cette superbe vision du Web à la IE6 Google Chrome … Jusqu’à ce qu’un des 2 autres acteurs se résigne à l’intégrer …



Pendant ce temps pour exécuter du C/C++ sur le Web il reste le ASM.js qui lui reste compatible avec les browser non compatible (Chrome pour ne pas le cité, ca sera supporté par Spartan)…

votre avatar

ChromeOS, c’est quand même assez éloigné d’un OS “desktop” généraliste. Un ChromeBook, c’est à peine mieux qu’une tablette avec un clavier, et ça exécute des applis web uniquement. C’est logique que ça converge avec Android, et c’est incompréhensible que ça n’ait pas été fait plus tôt.

En plus, répandre les applis android partout risque d’atomiser Windows Phone.

&nbsp;

votre avatar

Sachant que le diable se cache dans les détails, j’attends les premières déconvenues d’une utilisation “intensive” d’un tel système….



Pour l’instant ca parait prometteur sur le papier, mais avec beaucoup d’inconnues….. Et evidemment l’aura “particulière” de Google qui plane là dessus.

Google ARC : les applications Android se promènent dans Chrome

  • Le début du support des API Google Services

  • Pas de fonctionnement des applications sans changements spécifiques

  • Vers des applications universelles à la Google ?

Fermer