8 ms·

First set of Android apps for ChromeOS

153 points by hencq 12y ago

tecnik 12y ago
Initial thoughts (duolingo on Acer C720): a lot of the UI design is pretty unintuitive, and although I'm sure I'd get used to using it with a non touchscreen and a physical keyboard, it just feels suboptimal. Also a weird feeling having Android-like prompts on a 'regular' computer. No fullscreen, so I'm left with a small window on an already small (11") screen. Functionality-wise, does what it should, but I'd much much rather have an offline proper chrome app. Currently, it'd be my last choice behind my android phone, iphone, ipad, and laptops I have with me right now (I realise I'm unlikely target audience).
- ZeroGravitas 12y ago
  I'm fairly certain that, at least when I was using it a year or so ago, the Duolingo website was better than the Android app. So it's odd that they chose this as one of the first apps to port. Maybe the Android app had better offline support?
- panzerboy 12y ago
  This is exactly my experience with Evernote. Although I've used it on the C720P with the touchscreen and it was a bit better. But the fonts look really small and the fact that you can't make it full screen is annoying. But it is still better than the Evernote web app. Now the question is: given all this, is Evernote (and Duolingo, etc.) motivated to release a proper Chrome app or not anymore? My fear is that they are not, which is bad from Chromebooks.
i_am_ralpht 12y ago
Is the source for the app runtime available anywhere? I've done a bunch of hacking on the Android framework to do things like multitasking before, so I'm really curious to see how they "put Android in a box".
- mwcampbell 12y ago
  I'm curious about the same thing. For example, did they stub out the user-space part of the binder? Presumably things like the media player run in the same address space as the application, rather than as separate service processes. I hope they managed this without forking Android.
- briandh 12y ago
  I think this is it, or at least part: https://chromium.googlesource.com/arc/arc https://chromium.googlesource.com/arc/arc
ecesena 12y ago
Anyone knows what happened to Flipboard? It was demoed in the keynote, but it's not listed here.
mcintyre1994 12y ago
I wish the results of the form [0] for favourite apps to port was public. [0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8t-RYx06qr61EPI_g/viewform https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...
grimmfang 12y ago
I really just wish they would make a native email client & possibly native word and spreadsheet app to work with Google drive. It's confusing for me to know whats synced offline vs online, I can't imagine how the average user must feel.
mjcohen 12y ago
Open Office
pgrote 12y ago
Does anyone know what is involved in getting an android app to run on chrome os? Is it a rewrite?
- Zigurd 12y ago
  Based on the apps listed, and on some other surmises, I'm guessing that apps that don't use the NDK and don't use 3D graphics will run pretty easily, and many of them should Just Work. I was involved in a project that did somewhat similar things. I think Google got it right by doing a release that restricts apps to ones that use certain capabilities, particularly since, in Android apps, those capabilities are declared and can be filtered using the app manifest. Making GPU acceleration work in a system with a "hybrid graphics stack" instead of layering Android's 2D graphics on a native substrate is a ton of work for an incremental (albeit an important increment) gain.
- georgemcbay 12y ago
  According to this [ http://arstechnica.com/gadgets/2014/09/chrome-os-can-now-run-android-apps-no-porting-required http://arstechnica.com/gadgets/2014/09/chrome-os-can-now-run... ] no porting is required. But with that in mind, it is unclear from the posts I've seen why the list of available apps is currently so small and why working closely with Google is required to get your app up and running right now, perhaps this is just due to the runtime being very much in active development and not supporting the entire set of Android APIs yet.
  - pgrote 12y ago
    Thanks. I was wondering why the few number of apps right now if it isn't a rewrite.
    - Zigurd 12y ago
      My guess is that some app manifests might have to set tighter compatibility restrictions, and would run, but poorly, on this environment. Non-game, non-SDK apps that don't have required accelerated visual transitions are probably the best candidates. But that's not a situation most developers are explicitly coding and testing for.
esolyt 12y ago
According to Arstechnica, developers do not need to port or modify their code. Though Google is manually adding apps to ensure good user experience.
- panzerboy 12y ago
  I wonder if Skype would work. I guess Microsoft has to agree with that (and I won't hold my breath on that one).
api 12y ago
"App runtime for Chrome..." floor->add(jaw); Think about that for a while...
- otibom 12y ago
  You have to stop counting the abstraction levels to maintain any sanity these days. I mean we have a computer running a web browser running a Javascript VM running an Android runtime running a JAVA VM running the app. Did I miss one? Maybe the app is Minecraft running one of those graphical calculators :) /sarcasm
  - ossreality 12y ago
    That's not even close to an accurate description of how these apps are running, if that's what you were trying to imply there.
higherpurpose 12y ago
This is a mistake. Not only does it potentially irreparably destroy ChromeOS' strong security model, by trying to force two different platforms into one, but this is going to be a S L O W process to bring Android apps on ChromeOS, making the whole idea almost useless. If you thought Android finally getting "tablet apps" was slow, this will be much worse. Just look at them here announcing a whopping number of four apps. That has got to be the weakest "platform" launch in recent years. Even for Honeycomb they had like 30 apps at launch. What Google should be doing (despite the strong internal conflict against this - Android is run by the guy who invented ChromeOS after all) is fitting Android on PC's. Now hear me out. I don't want the current Android to be put on PC's. That's obviously a bad idea, and it's been tried before and it doesn't work. Why? Because it's a terrible user experience having a phone (or even tablet) UI on a laptop. Nobody really wants to use Android-x86 project on their laptops, either. But here's what Google can do. It can turn it into another "Android Wear" or "Android TV", but for PC's. What that means is that it takes the Android core, and all the Android compatibility, and then highly optimizes it for that usage mode. Doing this will be surprisingly easy for Google, and about an order of magnitude easier than putting Android apps on ChromeOS. What they need is 3 things: 1) a taskbar - don't laugh. It worked for ChromeOS. ChromeOS really started being seen as a potentially good alternative for Windows when it got a taskbar, despite it having only shortcuts to web apps. But it helps greatly with usability 2) multi-windows - another thing that ChromeOS got later on. Initially it was kind of full-screen/multi-desktop, which wasn't that great of an experience. 3) Android apps that scale nicely to 13" screens or larger. This is actually already underway since they announced the whole material design stuff together with the Polymer library for web apps (which guess what - work on 13"+ PC's!) - so they have already "fixed" this problem for Android PCs, even if somewhat unintentionally. In fact, they are already doing that with these Android apps inside ChromeOS. Look at the picture they're using in the blog post. The app could look exactly the same way on an "Android PC". So why not do the same thing on Android, where those apps came from? This would have the advantage of getting virtually all the apps on Android PC's from day one of "Android PC" mode. So the first two would solve the "OS optimization" problem, for larger screens, while the last one would solve the problem of the Android apps being optimized for larger screens. Again, this should be much easier than doing it on top of ChromeOS. Do I expect Google to do this anytime soon? No it won't. Instead it will waste 2 years not doing this, while Apple puts iOS on a laptop, with advanced multi-tasking, a laptop that I expect to be much more successful than any Mac OS laptop, because it will be cheaper, and because an order of magnitude more people know iOS now, than Mac OS, so an iOS laptop has a much wider reach. After 2 years, they'll think "gee, maybe we should do that, too", but by then they will already be behind. Android, with its 1 billion user base and still rapidly growing is also by far a bigger threat to Windows on the desktop than ChromeOS. People in many countries, especially emerging ones, are already familiar with Android, and have been using it as their "first OS". It's such a shame Google isn't going to take advantage of this, to push people to Android laptops. Oh well, they can't say I didn't try. Failing to bring Android on PCs will be on them.
deleted 12y ago
[deleted]
- jayd16 12y ago
  The assumption is that Android apps are more intensive than web pages?
  - deleted 12y ago
    [deleted]
  - cwyers 12y ago
    Or that running the Android apps on the Android platform on top of NaCl is more battery intensive than either running Android apps directly on top of Android or running NaCl apps on NaCl.
mwcampbell 12y ago
It seems likely that this new runtime won't work with apps that use the NDK. Three reasons come to my mind: 1. The NDK assumes a Linux environment, which the NaCl sanbox is not. 2. Binaries compiled with the NDK don't meet the special requirements of the NaCl machine code verifier. 3. A lot of NDK-based apps only build the native components for ARM. These wouldn't work on x86 Chromebooks, including the Pixel.
- lhchavez 12y ago
  Two of the applications mentioned in the announcement (Vine and Sight Words) use NDK.
- lxgr 12y ago
  Since there are already x86 emulators in JavaScript, surely Google could implement an ARM emulator running Linux and the Android NDK stack in (P)NaCl? :)
  - vidarh 12y ago
    They already have an ARM emulator: The Android emulator. Those who have suffered through it's excruciating performance presumably wouldn't wish that on their worst enemy..
    - drdaeman 12y ago
      They use qemu in system mode for full-stack emulation, which is, indeed, has performance issues. They may use it in user mode, like shown here: http://tuxthink.blogspot.ru/2012/04/executing-arm-executable-in-x86-using.html http://tuxthink.blogspot.ru/2012/04/executing-arm-executable... (a first link Google gave me), and implement most of Android APIs in platform-native way not bearing the arm->x86 translation costs. Such approach may provide reasonably better performance.
cwyers 12y ago
Okay, so if ChromeOS can run Android apps, and Android can run Chrome Web Apps[1], at what point does Google start to actually merge the platforms together? 1) http://techcrunch.com/2014/01/28/google-brings-chrome-apps-to-android-and-ios/ http://techcrunch.com/2014/01/28/google-brings-chrome-apps-t...
- final 12y ago
  OK, so Linux can run Windows apps (Wine) and Windows can run Linux apps (Cygwin). When do Microsoft and RedHat merge their platforms?
  - mathnode 12y ago
    Your thing, doesn't relate to his thing. Not one bit.
  - todd3834 12y ago
    If Microsoft created and maintained both Linux and Microsoft, your analogy would make more sense.
  - cwyers 12y ago
    I know that the behavior of the Chrome and Android teams hasn't always SEEMED like they were part of the same company, but they are. Microsoft and Red Hat are two different, competing organizations. If Android and ChromeOS are two different, competing organizations (and at one point, that really did seem to be the case), that's a problem for Google.
- dragonwriter 12y ago
  When they did those things, they already started merging the platforms.
  - cwyers 12y ago
    Not really. There's still a separate Chrome Web Store and Google Play stores for apps. Google has to approve specific Android apps for Chrome, and you have to package your Chrome Web Apps apps using Cordova and put them through the same Google Play submission procedure every other Android app goes through to get them onto Android. There's no integration, there's just Chrome on Android and Android on Chrome.
TheMagicHorsey 12y ago
What would be really dope, is if there was one application interface for ChromeOS/ChromeBrowser/Android ... AND ... we could use it from some nice modern language ... like Go.
MarkMc 12y ago
It's a shame that Google don't just let Chromebooks boot to Android.
podgib 12y ago
Well it seems that now that they have two strong platforms, google have given up the pretence of pushing the open web. The open web made sense for them in a world dominated by Microsoft, but now that they have the dominant mobile platform and the most popular browser, they no longer need it.
- derefr 12y ago
  I've never understood what "the open web" has to do with Javascript vs. native binaries. Right now, we write in a variety of languages (ClojureScript, CoffeeScript, etc.) to produce opaque minified+concatenated blobs of JS-targeting (or asm.js-targeting, even) object-code. Sometimes, we just take raw machine language and re-encode it with Emscripten! Nobody can read any of this without a process that exactly fits the term "decompilation." Effectively, then, in the current model, the browser is just obeying this contract: 1. When you encounter a <script> tag, download the specified binary (for the Javascript Abstract Machine, the world's most verbose ISA); 2. resolve its CORS origin to calculate a default permissions set, and boot it up within a fresh VM/container/sandbox circumscribed by that permissions set; 3. allow it to manipulate various browser APIs (e.g. the DOM, WebGL); 4. give it the ability to request additional permissions (for e.g. storage, or location information) which you will then prompt the user for. So what's the difference if the binary is encoded in some other way? What's wrong with Native Client, or Android, or even Java, if it's run under this same "contract"? Javascript is no more open or closed than any of these. They're all relatively opaque and require decompilation to comprehend or learn from. They all only act through browser APIs. They all talk to servers using "open web" REST requests. And--this is key--a web browser could be taught to debug them in just the same way it debugs Javascript.
  - erikpukinskis 12y ago
    You're right that's not a real distinction. I would say there's a spectrum though, even among JavaScript apps, of standards adherence. For example you could draw your own glyphs on a HTML canvas element. That would still be "the open web" in some literal sense, but it's less of a web app in that case and more of a JavaScript app that can run in the browser. You're right that using the browser as the runtime is a key requirement for an open web app, but I would add a bunch more criteria: - every user-relevant resource has a URL. - content is rendered with the semantic tags HTML provides when possible - the app is performant in common browsers - you use HTML and CSS in a way that things degrade gracefully on older browsers - you use standard interactions (hyperlinks, forms) wherever possible and implement your own widgets only when necessary. By these criteria many pure HTML apps are not good open web apps. The old practice of rendering text in GIFs to get typefaces and anti-aliasing was a step away from "the open web". I don't think it's strictly a technical line people are talking about. It's a set of conventions that let us write code that is cross platform and gets many benefits for free (sharability, printability, responsive design, etc)
MarkMc 12y ago
Got to admit I'm relieved to see this. I'm currently porting a large desktop Java app to the cloud, and this means I can focus on just creating an Android app instead of Android AND WebApp.
- guardian5x 12y ago
  With a WebApp you had still a bigger reach with your App, for example iOS and Windows devices.
  - tmzt 12y ago
    Of course, Chrome runs on both of those platforms, and this (ARC) could as well.
AdmiralAsshat 12y ago
Why is the size of the app so huge? I started the download until I saw it was 100mb. I'm fairly sure my Android Evernote app is half that size, and that's including data.
- panzerboy 12y ago
  I read elsewhere that they bundle the runtime with the first app you download. Afterwards it should only be the Android app that's downloaded.
SimeVidas 12y ago
Google created "Chrome Apps" for the exact purpose of filling the "gap to native", i.e. making web apps offline-capable, with device APIs, etc. Now they're embracing Android apps. What does this tell us about Google's priorities (wrt open web vs Android silo)?
- enapupe 12y ago
  Considering the first released apps I don't agree the gap thing: Duolingo - a fun and free way to learn a new language before your next trip Evernote - write, collect and find what matters to you, with a full-size keyboard and touchscreen Sight Words - a delightful way for you to help improve your child's reading skills Vine - create short, beautiful, looping videos in a simple and fun way
  - SimeVidas 12y ago
    Could you elaborate? The gap exists - that's why Chrome Apps (and Firefox OS apps for that matter) are provided with additional API to bridge the gap. Google and Mozilla are working on standardizing these APIs but until then, Chrome Apps/Firefox OS apps should be an active effort. In that context, I don't understand the Android support in Chrome OS.

153 points by hencq 12y ago

Initial thoughts (duolingo on Acer C720): a lot of the UI design is pretty unintuitive, and although I'm sure I'd get used to using it with a non touchscreen and a physical keyboard, it just feels suboptimal. Also a weird feeling having Android-like prompts on a 'regular' computer. No fullscreen, so I'm left with a small window on an already small (11") screen. Functionality-wise, does what it should, but I'd much much rather have an offline proper chrome app. Currently, it'd be my last choice behind my android phone, iphone, ipad, and laptops I have with me right now (I realise I'm unlikely target audience).

ZeroGravitas 12y ago
I'm fairly certain that, at least when I was using it a year or so ago, the Duolingo website was better than the Android app. So it's odd that they chose this as one of the first apps to port. Maybe the Android app had better offline support?
panzerboy 12y ago
This is exactly my experience with Evernote. Although I've used it on the C720P with the touchscreen and it was a bit better. But the fonts look really small and the fact that you can't make it full screen is annoying. But it is still better than the Evernote web app. Now the question is: given all this, is Evernote (and Duolingo, etc.) motivated to release a proper Chrome app or not anymore? My fear is that they are not, which is bad from Chromebooks.

i_am_ralpht 12y ago

Is the source for the app runtime available anywhere? I've done a bunch of hacking on the Android framework to do things like multitasking before, so I'm really curious to see how they "put Android in a box".

mwcampbell 12y ago
I'm curious about the same thing. For example, did they stub out the user-space part of the binder? Presumably things like the media player run in the same address space as the application, rather than as separate service processes. I hope they managed this without forking Android.
briandh 12y ago
I think this is it, or at least part: https://chromium.googlesource.com/arc/arc https://chromium.googlesource.com/arc/arc

ecesena 12y ago

Anyone knows what happened to Flipboard? It was demoed in the keynote, but it's not listed here.

mcintyre1994 12y ago

I wish the results of the form [0] for favourite apps to port was public. [0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8t-RYx06qr61EPI_g/viewform https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...

grimmfang 12y ago

I really just wish they would make a native email client & possibly native word and spreadsheet app to work with Google drive. It's confusing for me to know whats synced offline vs online, I can't imagine how the average user must feel.

mjcohen 12y ago

Open Office

pgrote 12y ago

Does anyone know what is involved in getting an android app to run on chrome os? Is it a rewrite?

Zigurd 12y ago
Based on the apps listed, and on some other surmises, I'm guessing that apps that don't use the NDK and don't use 3D graphics will run pretty easily, and many of them should Just Work. I was involved in a project that did somewhat similar things. I think Google got it right by doing a release that restricts apps to ones that use certain capabilities, particularly since, in Android apps, those capabilities are declared and can be filtered using the app manifest. Making GPU acceleration work in a system with a "hybrid graphics stack" instead of layering Android's 2D graphics on a native substrate is a ton of work for an incremental (albeit an important increment) gain.
georgemcbay 12y ago
According to this [ http://arstechnica.com/gadgets/2014/09/chrome-os-can-now-run-android-apps-no-porting-required http://arstechnica.com/gadgets/2014/09/chrome-os-can-now-run... ] no porting is required. But with that in mind, it is unclear from the posts I've seen why the list of available apps is currently so small and why working closely with Google is required to get your app up and running right now, perhaps this is just due to the runtime being very much in active development and not supporting the entire set of Android APIs yet.
- pgrote 12y ago
  Thanks. I was wondering why the few number of apps right now if it isn't a rewrite.
  - Zigurd 12y ago
    My guess is that some app manifests might have to set tighter compatibility restrictions, and would run, but poorly, on this environment. Non-game, non-SDK apps that don't have required accelerated visual transitions are probably the best candidates. But that's not a situation most developers are explicitly coding and testing for.

esolyt 12y ago

According to Arstechnica, developers do not need to port or modify their code. Though Google is manually adding apps to ensure good user experience.

panzerboy 12y ago
I wonder if Skype would work. I guess Microsoft has to agree with that (and I won't hold my breath on that one).

api 12y ago

"App runtime for Chrome..." floor->add(jaw); Think about that for a while...

otibom 12y ago
You have to stop counting the abstraction levels to maintain any sanity these days. I mean we have a computer running a web browser running a Javascript VM running an Android runtime running a JAVA VM running the app. Did I miss one? Maybe the app is Minecraft running one of those graphical calculators :) /sarcasm
- ossreality 12y ago
  That's not even close to an accurate description of how these apps are running, if that's what you were trying to imply there.

higherpurpose 12y ago

This is a mistake. Not only does it potentially irreparably destroy ChromeOS' strong security model, by trying to force two different platforms into one, but this is going to be a S L O W process to bring Android apps on ChromeOS, making the whole idea almost useless. If you thought Android finally getting "tablet apps" was slow, this will be much worse. Just look at them here announcing a whopping number of four apps. That has got to be the weakest "platform" launch in recent years. Even for Honeycomb they had like 30 apps at launch. What Google should be doing (despite the strong internal conflict against this - Android is run by the guy who invented ChromeOS after all) is fitting Android on PC's. Now hear me out. I don't want the current Android to be put on PC's. That's obviously a bad idea, and it's been tried before and it doesn't work. Why? Because it's a terrible user experience having a phone (or even tablet) UI on a laptop. Nobody really wants to use Android-x86 project on their laptops, either. But here's what Google can do. It can turn it into another "Android Wear" or "Android TV", but for PC's. What that means is that it takes the Android core, and all the Android compatibility, and then highly optimizes it for that usage mode. Doing this will be surprisingly easy for Google, and about an order of magnitude easier than putting Android apps on ChromeOS. What they need is 3 things: 1) a taskbar - don't laugh. It worked for ChromeOS. ChromeOS really started being seen as a potentially good alternative for Windows when it got a taskbar, despite it having only shortcuts to web apps. But it helps greatly with usability 2) multi-windows - another thing that ChromeOS got later on. Initially it was kind of full-screen/multi-desktop, which wasn't that great of an experience. 3) Android apps that scale nicely to 13" screens or larger. This is actually already underway since they announced the whole material design stuff together with the Polymer library for web apps (which guess what - work on 13"+ PC's!) - so they have already "fixed" this problem for Android PCs, even if somewhat unintentionally. In fact, they are already doing that with these Android apps inside ChromeOS. Look at the picture they're using in the blog post. The app could look exactly the same way on an "Android PC". So why not do the same thing on Android, where those apps came from? This would have the advantage of getting virtually all the apps on Android PC's from day one of "Android PC" mode. So the first two would solve the "OS optimization" problem, for larger screens, while the last one would solve the problem of the Android apps being optimized for larger screens. Again, this should be much easier than doing it on top of ChromeOS. Do I expect Google to do this anytime soon? No it won't. Instead it will waste 2 years not doing this, while Apple puts iOS on a laptop, with advanced multi-tasking, a laptop that I expect to be much more successful than any Mac OS laptop, because it will be cheaper, and because an order of magnitude more people know iOS now, than Mac OS, so an iOS laptop has a much wider reach. After 2 years, they'll think "gee, maybe we should do that, too", but by then they will already be behind. Android, with its 1 billion user base and still rapidly growing is also by far a bigger threat to Windows on the desktop than ChromeOS. People in many countries, especially emerging ones, are already familiar with Android, and have been using it as their "first OS". It's such a shame Google isn't going to take advantage of this, to push people to Android laptops. Oh well, they can't say I didn't try. Failing to bring Android on PCs will be on them.

deleted 12y ago

[deleted]

jayd16 12y ago
The assumption is that Android apps are more intensive than web pages?
- deleted 12y ago
  [deleted]
- cwyers 12y ago
  Or that running the Android apps on the Android platform on top of NaCl is more battery intensive than either running Android apps directly on top of Android or running NaCl apps on NaCl.

mwcampbell 12y ago

It seems likely that this new runtime won't work with apps that use the NDK. Three reasons come to my mind: 1. The NDK assumes a Linux environment, which the NaCl sanbox is not. 2. Binaries compiled with the NDK don't meet the special requirements of the NaCl machine code verifier. 3. A lot of NDK-based apps only build the native components for ARM. These wouldn't work on x86 Chromebooks, including the Pixel.

lhchavez 12y ago
Two of the applications mentioned in the announcement (Vine and Sight Words) use NDK.
lxgr 12y ago
Since there are already x86 emulators in JavaScript, surely Google could implement an ARM emulator running Linux and the Android NDK stack in (P)NaCl? :)
- vidarh 12y ago
  They already have an ARM emulator: The Android emulator. Those who have suffered through it's excruciating performance presumably wouldn't wish that on their worst enemy..
  - drdaeman 12y ago
    They use qemu in system mode for full-stack emulation, which is, indeed, has performance issues. They may use it in user mode, like shown here: http://tuxthink.blogspot.ru/2012/04/executing-arm-executable-in-x86-using.html http://tuxthink.blogspot.ru/2012/04/executing-arm-executable... (a first link Google gave me), and implement most of Android APIs in platform-native way not bearing the arm->x86 translation costs. Such approach may provide reasonably better performance.

cwyers 12y ago

Okay, so if ChromeOS can run Android apps, and Android can run Chrome Web Apps[1], at what point does Google start to actually merge the platforms together? 1) http://techcrunch.com/2014/01/28/google-brings-chrome-apps-to-android-and-ios/ http://techcrunch.com/2014/01/28/google-brings-chrome-apps-t...

final 12y ago
OK, so Linux can run Windows apps (Wine) and Windows can run Linux apps (Cygwin). When do Microsoft and RedHat merge their platforms?
- mathnode 12y ago
  Your thing, doesn't relate to his thing. Not one bit.
- todd3834 12y ago
  If Microsoft created and maintained both Linux and Microsoft, your analogy would make more sense.
- cwyers 12y ago
  I know that the behavior of the Chrome and Android teams hasn't always SEEMED like they were part of the same company, but they are. Microsoft and Red Hat are two different, competing organizations. If Android and ChromeOS are two different, competing organizations (and at one point, that really did seem to be the case), that's a problem for Google.
dragonwriter 12y ago
When they did those things, they already started merging the platforms.
- cwyers 12y ago
  Not really. There's still a separate Chrome Web Store and Google Play stores for apps. Google has to approve specific Android apps for Chrome, and you have to package your Chrome Web Apps apps using Cordova and put them through the same Google Play submission procedure every other Android app goes through to get them onto Android. There's no integration, there's just Chrome on Android and Android on Chrome.

TheMagicHorsey 12y ago

What would be really dope, is if there was one application interface for ChromeOS/ChromeBrowser/Android ... AND ... we could use it from some nice modern language ... like Go.

MarkMc 12y ago

It's a shame that Google don't just let Chromebooks boot to Android.

podgib 12y ago

Well it seems that now that they have two strong platforms, google have given up the pretence of pushing the open web. The open web made sense for them in a world dominated by Microsoft, but now that they have the dominant mobile platform and the most popular browser, they no longer need it.

derefr 12y ago
I've never understood what "the open web" has to do with Javascript vs. native binaries. Right now, we write in a variety of languages (ClojureScript, CoffeeScript, etc.) to produce opaque minified+concatenated blobs of JS-targeting (or asm.js-targeting, even) object-code. Sometimes, we just take raw machine language and re-encode it with Emscripten! Nobody can read any of this without a process that exactly fits the term "decompilation." Effectively, then, in the current model, the browser is just obeying this contract: 1. When you encounter a <script> tag, download the specified binary (for the Javascript Abstract Machine, the world's most verbose ISA); 2. resolve its CORS origin to calculate a default permissions set, and boot it up within a fresh VM/container/sandbox circumscribed by that permissions set; 3. allow it to manipulate various browser APIs (e.g. the DOM, WebGL); 4. give it the ability to request additional permissions (for e.g. storage, or location information) which you will then prompt the user for. So what's the difference if the binary is encoded in some other way? What's wrong with Native Client, or Android, or even Java, if it's run under this same "contract"? Javascript is no more open or closed than any of these. They're all relatively opaque and require decompilation to comprehend or learn from. They all only act through browser APIs. They all talk to servers using "open web" REST requests. And--this is key--a web browser could be taught to debug them in just the same way it debugs Javascript.
- erikpukinskis 12y ago
  You're right that's not a real distinction. I would say there's a spectrum though, even among JavaScript apps, of standards adherence. For example you could draw your own glyphs on a HTML canvas element. That would still be "the open web" in some literal sense, but it's less of a web app in that case and more of a JavaScript app that can run in the browser. You're right that using the browser as the runtime is a key requirement for an open web app, but I would add a bunch more criteria: - every user-relevant resource has a URL. - content is rendered with the semantic tags HTML provides when possible - the app is performant in common browsers - you use HTML and CSS in a way that things degrade gracefully on older browsers - you use standard interactions (hyperlinks, forms) wherever possible and implement your own widgets only when necessary. By these criteria many pure HTML apps are not good open web apps. The old practice of rendering text in GIFs to get typefaces and anti-aliasing was a step away from "the open web". I don't think it's strictly a technical line people are talking about. It's a set of conventions that let us write code that is cross platform and gets many benefits for free (sharability, printability, responsive design, etc)

MarkMc 12y ago

Got to admit I'm relieved to see this. I'm currently porting a large desktop Java app to the cloud, and this means I can focus on just creating an Android app instead of Android AND WebApp.

guardian5x 12y ago
With a WebApp you had still a bigger reach with your App, for example iOS and Windows devices.
- tmzt 12y ago
  Of course, Chrome runs on both of those platforms, and this (ARC) could as well.

AdmiralAsshat 12y ago

Why is the size of the app so huge? I started the download until I saw it was 100mb. I'm fairly sure my Android Evernote app is half that size, and that's including data.

panzerboy 12y ago
I read elsewhere that they bundle the runtime with the first app you download. Afterwards it should only be the Android app that's downloaded.

SimeVidas 12y ago

Google created "Chrome Apps" for the exact purpose of filling the "gap to native", i.e. making web apps offline-capable, with device APIs, etc. Now they're embracing Android apps. What does this tell us about Google's priorities (wrt open web vs Android silo)?

enapupe 12y ago
Considering the first released apps I don't agree the gap thing: Duolingo - a fun and free way to learn a new language before your next trip Evernote - write, collect and find what matters to you, with a full-size keyboard and touchscreen Sight Words - a delightful way for you to help improve your child's reading skills Vine - create short, beautiful, looping videos in a simple and fun way
- SimeVidas 12y ago
  Could you elaborate? The gap exists - that's why Chrome Apps (and Firefox OS apps for that matter) are provided with additional API to bridge the gap. Google and Mozilla are working on standardizing these APIs but until then, Chrome Apps/Firefox OS apps should be an active effort. In that context, I don't understand the Android support in Chrome OS.