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.
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.
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 (63)
#1
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.
#2
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.
#3
Cool je vais pouvoir utiliser gmail dans chrome.
Oh Wait
#4
Moi, je trouve ça génial… Enfin, quand ça va fonctionner, ce sera génial…
#5
Ça évitera d’installer BlueStacks pour jouer à tel ou tel jeu sur PC
" />
#6
Ce serait pas mal à la Amazon (je ne sais pas si ça existe encore) de pouvoir tester les app directement dans le store.
#7
ça va être utile pour les tablettes sous windows!
" />
#8
Petit cheval de troie :)
Dommage que MS ne joue pas le même jeu plus sérieusement de son coté avec mono…
#9
oui, c’est probable que le problème vienne des fonction NDK, ils auront potentiellement à trafiquer 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
#10
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.
#11
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 
" />
" />
Va falloir que je teste ça suer mon app moi
#12
Bon je viens de faire quelques petits tests :
#13
#14
#15
En même temps, c’est très concis comme avis. Je ne peux que te suivre dans ton raisonnement.
#16
#17
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 !
#18
Bon bah mon app fonctionne pas dessus … peut être que c’est la lib flurry :/ … faudrait que je fasse des tests ….
#19
#20
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 ?
#21
#22
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..
#23
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)
#24
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 ?
#25
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
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…
#26
#27
aucune appli testée ne marche sur Win7. Faut-il être obligatoirement sur 8.1 ?
#28
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é ^^
Mais il ne faut pas oublier que c’est une version beta, donc faut pas s’attendre non plus à des miracles …
#29
Thanks :-)
oui, à voir. J’étais tenté par déporter Whatzapp sur l’ordi.
A re tester à la maison.
#30
#31
#32
Question : cela ne concerne que Chrome ou les navigateurs basés sur Blink pourront également en profiter ?
#33
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
#34
#35
Pour moi, tout ce qui fait qu’un dev se dit “développer pour Android est indispensable” est tout bénéf pour Google 
" /> …. 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
#36
#37
Après on verra à quoi ressemble W10 au final.
#38
#39
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 …….
" />
De toute façon les prochains mois devraient être intéressants
#40
#41
#42
Non.
#43
Pourquoi pas ? 
" />
#44
Parce que Microsoft n’intégrera pas pnacl à Spartan, y’a 4000 raisons contre ça.
#45
Là dessus on est d’accord … mais alors ils ne pourront pas annoncer le support des extensions chrome.
#46
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…
#47
Oui mais alors ce sera plus ARC dans ce cas.
#48
#49
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)…
#50
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.
#51
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.