First set of Android apps for ChromeOS(chrome.blogspot.com)
chrome.blogspot.com
First set of Android apps for ChromeOS
http://chrome.blogspot.com/2014/09/first-set-of-android-apps-coming-to.html
90 comments
Two of the applications mentioned in the announcement (Vine and Sight Words) use NDK.
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? :)
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..
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... (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.
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).
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.
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'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?
Maybe the Android app had better offline support?
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-t...
1) http://techcrunch.com/2014/01/28/google-brings-chrome-apps-t...
When they did those things, they already started merging the platforms.
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.
parent didn't write "they already finished merging the platforms"
Right now this is a very Parallels sort of solution, where you run the app in a VM. No actual merging of anything is going on, there's just a runtime that lets you run Android apps on ChromeOS, looking like they do on Android.
I think it's likely that they're writing a runtime for dalvik to run on chromeOS, which, is essentially 'merging' though now you're just arguing semantics.
(Dalvik is dead. You probably mean ART.)
Dalvik the runtime is dead. Dalvik the bytecode is not.
Aren't Android apps run in a virtual machine (because of the Java roots) anyway?
(Genuine question, not me being a smarty pants.)
(Genuine question, not me being a smarty pants.)
"Virtual Machine" is an overloaded term. It can either mean virtualization of an existing CPU (like the x86), or of an abstract bytecode machine (like the JVM or Dalvik). In the former case, you have to efficiently virtualize/emulate an entire system (including stuff like hardware devices and CPU interrupts); in the latter, you only have to execute the bytecode program well, which most VMs of this sort compile just-in-time (they compile the bytecode program into a native equivalent at execution time).
[deleted]
So far Cordova apps on Android have constantly been the worst apps on the platform.
If Google wants to make it possible to make html mobile app that perform as well as native ones, there is an enormous gap to bridge.
I don't think it is as big as it once was with frameworks such as Polymer and Ionic.
I have heard many claims through the years that html based mobile apps were finally coming along.
So far, I have not seen a single webapp that comes even close to native.
OK, so Linux can run Windows apps (Wine) and Windows can run Linux apps (Cygwin). When do Microsoft and RedHat merge their platforms?
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.
If Microsoft created and maintained both Linux and Microsoft, your analogy would make more sense.
Your thing, doesn't relate to his thing. Not one bit.
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.
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.
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.
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)
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)
There are many apps that don't consist of representing and manipulating hyperlinked documents, though. For example, games. Would Angry Birds be better if it was built out of DOM nodes? Would an night-sky astronomy visualization app? Would a synthesizer?
These are the types of things people make Chrome apps for. And frankly, I don't see the advantage of those being built out of "standards-conforming semantic markup" versus just manipulating the browser's APIs directly.
These are the types of things people make Chrome apps for. And frankly, I don't see the advantage of those being built out of "standards-conforming semantic markup" versus just manipulating the browser's APIs directly.
What is this open web thinggie with applications behind closed doors that I never get to see?
Google is just yet another big corporation that no longer needs to pretend to be the open source champion.
Likewise Apple is no different from the good old days of Mac OS. The openness that started with NeXT acquisition is long gone.
Open is only good as long as it sells, there is never the idea of making a better world for consumers just because it feels right or something like that.
Google is just yet another big corporation that no longer needs to pretend to be the open source champion.
Likewise Apple is no different from the good old days of Mac OS. The openness that started with NeXT acquisition is long gone.
Open is only good as long as it sells, there is never the idea of making a better world for consumers just because it feels right or something like that.
I'm surprised by this comment. Google is still very supportive of open source, I don't think there is any comparison with other big tech companies. It's not just the still growing Google Summer of Code and Code-in programs[1], but the scope and number of open source projects that they publish and maintain: Android, Chrome OS, Chromium, V8, Go, Dart, Angle, Angular, PDFium, Guava, GWT, WebM...
By the way, I think the impact of Android (the open source project) is underestimated. There is a huge number of research and industry projects that are based on the open platform, not just phone and tablet apps but all kind of hardware projects.[2]
So when I read a casual dismissal of these efforts (by knowledgeable people like you) I feel bad for the engineers and managers that work to promote open source inside the company.
On the other hand, Google is the biggest force behind the shift to the Cloud, and that shift means more and more users using closed-source web apps like Google Docs instead of open source applications like LibreOffice, so there is that...
[1] https://code.google.com/p/google-summer-of-code/wiki/Program...
[2] As a random example see http://www.citlprojects.com/android_list.html
By the way, I think the impact of Android (the open source project) is underestimated. There is a huge number of research and industry projects that are based on the open platform, not just phone and tablet apps but all kind of hardware projects.[2]
So when I read a casual dismissal of these efforts (by knowledgeable people like you) I feel bad for the engineers and managers that work to promote open source inside the company.
On the other hand, Google is the biggest force behind the shift to the Cloud, and that shift means more and more users using closed-source web apps like Google Docs instead of open source applications like LibreOffice, so there is that...
[1] https://code.google.com/p/google-summer-of-code/wiki/Program...
[2] As a random example see http://www.citlprojects.com/android_list.html
I was being a bit stronger to make a point about corporations and their relationship with open source.
There was a time I was one of such engineers that you mention, but eventually came to realize how company boards see open source and how little we could get in return.
There was a time I was one of such engineers that you mention, but eventually came to realize how company boards see open source and how little we could get in return.
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".
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".
I think this is it, or at least part: https://chromium.googlesource.com/arc/arc
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.
Does anyone know what is involved in getting an android app to run on chrome os? Is it a rewrite?
According to this [ 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.
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.
> perhaps this is just due to the runtime being very much in active development and not supporting the entire set of Android APIs yet.
Probably this: its in beta, so they are probably working with individual, high-demand apps to assure that they work (and by doing so validate the runtime itself) to manage the scope of potential consumer-facing bugs.
Probably this: its in beta, so they are probably working with individual, high-demand apps to assure that they work (and by doing so validate the runtime itself) to manage the scope of potential consumer-facing bugs.
Thanks. I was wondering why the few number of apps right now if it isn't a rewrite.
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.
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.
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.
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.
It is not a rewrite, according to the I/O keynote it is the native Android app (maybe with some minor changes).
I would be curious to know how it works exactly. Did Google write a port of Dalvik/ART that runs on ChromeOS ?
> I would be curious to know how it works exactly. Did Google write a port of Dalvik/ART that runs on ChromeOS ?
From what I can gather from the articles, they run in the "App Runtime for Chrome (beta)", which is an Android VM for Native Client.
From what I can gather from the articles, they run in the "App Runtime for Chrome (beta)", which is an Android VM for Native Client.
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.
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)?
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
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
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.
I wish the results of the form [0] for favourite apps to port was public.
[0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...
[0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...
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.
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.
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.
With a WebApp you had still a bigger reach with your App, for example iOS and Windows devices.
Of course, Chrome runs on both of those platforms, and this (ARC) could as well.
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.
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.
Anyone knows what happened to Flipboard? It was demoed in the keynote, but it's not listed here.
[deleted](1)
It's a shame that Google don't just let Chromebooks boot to Android.
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.
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.
I would agree with you until I discovered that these Android applications are running under Native Client. So this doesn't irreparably destroy ChromeOS's strong security model, for example. It also think it maintains the fundamental application model of ChromeOS.
This isn't a fundamental change to ChromeOS -- it's just a compatibility library. Maybe they should go all out and port WINE to ChromeOS next.
This isn't a fundamental change to ChromeOS -- it's just a compatibility library. Maybe they should go all out and port WINE to ChromeOS next.
And yet, to be truly compatible with Android, they will have to poke holes in the sandbox to allows access to contacts, social data, etc. So while I have no problem believing that the sandbox will be equally resilient against buffer overflows, this is nevertheless modifying the security model in a very real sense.
Personally, permissions are the one area of Android that I'm not happy with, because permissions being all-or-nothing means that apps can twist my arm to give them access to things I'd rather they not have access to (e.g. contacts). Seeing ChromeOS adopt this security model would make it less appealing to me rather than more appealing, because it encourages apps to demand access to more data than they need.
Personally, permissions are the one area of Android that I'm not happy with, because permissions being all-or-nothing means that apps can twist my arm to give them access to things I'd rather they not have access to (e.g. contacts). Seeing ChromeOS adopt this security model would make it less appealing to me rather than more appealing, because it encourages apps to demand access to more data than they need.
Does Chrome OS actually store anything like contacts, social data, etc, natively? If not, then I don't see where it could even poke any holes.
You're right that Chrome OS doesn't store any of that at the moment. But this is the sort of integration that would be fairly easy for Google to add. Chrome already has some minimal integration with Google web services, especially on Android where Chrome will automatically log in to Google for you. How much bigger a step would it be to fetch your Google contacts while they're at it?
The concept of permissions (to contacts, etc) doesn't exist on Chrome OS and will likely never exist on Chrome OS. But both Chrome and Android apps can access the Internet where all this stuff is stored. But this has nothing to do with security of Chrome OS itself.
Sure, nothing stops a website (or app) from going to Google to ask for your contacts. This is the classic "invite your contacts" strategy that Facebook, LinkedIn, etc. have employed since the beginning. But granting that access is almost never mandatory with such services. Why? Because people just wouldn't sign up. It's not even necessarily a question of people not trusting the service, because the UX hurdle of forcing the user to enter yet-one-more-password is enough to hurt conversion rates.
On Android, this is not the case; if you use the Facebook or LinkedIn apps, you will be forced to give up access to your contacts (unless you root your device). The reasons for this are twofold. First, Android permissions are all-or-nothing, which means that apps have to over-approximate their required permissions. Second, because granting access is so easy (no UX hurdle to speak of), there's really no downside to doing so (which is to say, conversion rates will not decrease substantially).
The issue of how the device gets access to the data (e.g. whether contacts are cached locally or are purely remote) is really not the issue. You could easily implement the Android API with no local caching of data, and aside from the performance hit the behavior would be identical.
I could certainly imagine a version of ChromeOS which supports Android apps without the Android permission model, essentially by returning empty data sets whenever the app asks. This would be compatible with ChromeOS's current security policies, and would protect user privacy. But it would be so easy for Google to break that line in order to promote "better UX" for apps in the style of Android, that I can't honestly convince myself that they'll never go down that road. And that's why I can't be entirely comfortable with believing the ChromeOS security model will remain intact.
On Android, this is not the case; if you use the Facebook or LinkedIn apps, you will be forced to give up access to your contacts (unless you root your device). The reasons for this are twofold. First, Android permissions are all-or-nothing, which means that apps have to over-approximate their required permissions. Second, because granting access is so easy (no UX hurdle to speak of), there's really no downside to doing so (which is to say, conversion rates will not decrease substantially).
The issue of how the device gets access to the data (e.g. whether contacts are cached locally or are purely remote) is really not the issue. You could easily implement the Android API with no local caching of data, and aside from the performance hit the behavior would be identical.
I could certainly imagine a version of ChromeOS which supports Android apps without the Android permission model, essentially by returning empty data sets whenever the app asks. This would be compatible with ChromeOS's current security policies, and would protect user privacy. But it would be so easy for Google to break that line in order to promote "better UX" for apps in the style of Android, that I can't honestly convince myself that they'll never go down that road. And that's why I can't be entirely comfortable with believing the ChromeOS security model will remain intact.
Or it could simply return contacts taken from the user's Google account, after asking the user for permission in browser chrome.
Android has potential to be next Windows, because it's getting commoditized right now. Thanks to cheap devices. Apple doesn't have that, because it doesn't want it.
I think there are few things remaining for Android to replace Windows (in no particular order):
1. UX - what you already said.
2. Cheap and universal docks for even cheapest devices. Alternatively cheap wireless display technology (without lags), something more than ChromeCast - again even for cheapest devices.
What can be used for this? Bluetooth (sound and input) and/or USB-OTG (with charging of device).
3. Android needs to be selfhosting - you can't rely on Windows or traditional desktop linux if you want to replace them. There is toybox and Aborginal Linux project from Rob Landley on http://landley.net/ Recent commits advancing in the goal of building Linux kernel with clang will come in handy too.
I think that all of these will eventually come, but ask myself is this what Google really wants now.
ChromeOS seems more in line with Google business model.
They are using NaCl to bring Android apps to ChromeOS, so probably it could enable Android apps for Windows. But that would undermine Android as replacement of Windows just like Wine for Desktop Linux.
I think there are few things remaining for Android to replace Windows (in no particular order):
1. UX - what you already said.
2. Cheap and universal docks for even cheapest devices. Alternatively cheap wireless display technology (without lags), something more than ChromeCast - again even for cheapest devices.
What can be used for this? Bluetooth (sound and input) and/or USB-OTG (with charging of device).
3. Android needs to be selfhosting - you can't rely on Windows or traditional desktop linux if you want to replace them. There is toybox and Aborginal Linux project from Rob Landley on http://landley.net/ Recent commits advancing in the goal of building Linux kernel with clang will come in handy too.
I think that all of these will eventually come, but ask myself is this what Google really wants now.
ChromeOS seems more in line with Google business model.
They are using NaCl to bring Android apps to ChromeOS, so probably it could enable Android apps for Windows. But that would undermine Android as replacement of Windows just like Wine for Desktop Linux.
Should be noted that Android as a PC OS already exists. Can read more about the x86 version here...
http://www.android-x86.org/
It's not supported by Google (no Play services AFAIK) but most applications that are installable from a 3rd party app store should run (they're JVM apps after all).
But why would you want to run Android on your PC? What advantages does it offer over Windows for the average user?
It's not supported by Google (no Play services AFAIK) but most applications that are installable from a 3rd party app store should run (they're JVM apps after all).
But why would you want to run Android on your PC? What advantages does it offer over Windows for the average user?
Just to nitpick the first point, ARC apps run inside the NaCl sandbox so there's no potential for harming the strong security model in ChromeOS
-- "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"."
Interesting point... I recently helped an elderly man (who has very poor reading skills and has never used a computer without help) - buy, set-up, and use his first computer. What did I choose for him?
A cheap Android tablet with a keyboard case. The idea behind this decision was that most people (in a low-income area) that he'd ask for help would already know how to work an Android tablet because they probably have a phone or tablet already. If not, he knows the basics, and it's much more simple than a PC but almost fully-capable with his needs (Facebook, PayPal, YouTube). I also locked it down so that he could get help with his financial data without giving anybody the actual password to his bank accounts (as he was doing before).
Interesting point... I recently helped an elderly man (who has very poor reading skills and has never used a computer without help) - buy, set-up, and use his first computer. What did I choose for him?
A cheap Android tablet with a keyboard case. The idea behind this decision was that most people (in a low-income area) that he'd ask for help would already know how to work an Android tablet because they probably have a phone or tablet already. If not, he knows the basics, and it's much more simple than a PC but almost fully-capable with his needs (Facebook, PayPal, YouTube). I also locked it down so that he could get help with his financial data without giving anybody the actual password to his bank accounts (as he was doing before).
> Doing this will be surprisingly easy for Google, and about an order of magnitude easier than putting Android apps on ChromeOS.
I suspect that putting Android apps on ChromeOS isn't that hard now, given all the work that's gone into Native Client and that even if the beta of the Android Runtime being used wasn't announced until I/O this year, the end goal of doing this has probably been part of the motivation behind Native Client for some time.
In fact, the fact that its in Beta and they are starting to publicly expose it with high-visibility apps probably means that its mostly done. And its potentially a much bigger win than expanding Android to low-end PCs, since there's no reason when its completely ready to leave Beta it has to be limited to ChromeOS -- a Native Client based runtime for apps should be usable on Chrome desktop as well, which suddenly means "Android" apps can be used on Android (naturally), on ChromeOS, and on MacOS/Windows desktop.
I suspect that putting Android apps on ChromeOS isn't that hard now, given all the work that's gone into Native Client and that even if the beta of the Android Runtime being used wasn't announced until I/O this year, the end goal of doing this has probably been part of the motivation behind Native Client for some time.
In fact, the fact that its in Beta and they are starting to publicly expose it with high-visibility apps probably means that its mostly done. And its potentially a much bigger win than expanding Android to low-end PCs, since there's no reason when its completely ready to leave Beta it has to be limited to ChromeOS -- a Native Client based runtime for apps should be usable on Chrome desktop as well, which suddenly means "Android" apps can be used on Android (naturally), on ChromeOS, and on MacOS/Windows desktop.
Chrome is already the defacto desktop for millions of users regardless of actual base OS. They are leveraging Android apps to continue to chip away at the things that "don't work unless its a native" and dev effort already committed to mobile.
This way when your hardware cycle is up. Hmmm $300 machine runs chrome and all those cool apps I use on my mobile but for my "desktop".
The goal is to erase the idea of desktop all together for the most part.
This way when your hardware cycle is up. Hmmm $300 machine runs chrome and all those cool apps I use on my mobile but for my "desktop".
The goal is to erase the idea of desktop all together for the most part.
If Google will bring Android apps to traditional desktops they can gain something in a short run, but hurt Android as a platform replacing Windows. Android as Windows replacement can bring Google much more, but it would take much more time.
Personally I hope that Android with or without Google will replace Windows.
Personally I hope that Android with or without Google will replace Windows.
What would be the advantage of Android to replace Windows on the Desktop?
As someone who doesn't use Android, i am really interested. Are there technical details where Android is ahead somehow or is it personal preference?
Before they can implement 3), they have to actually make ChromeOS scale nicely to high-res displays. I've got a Chromebook Pixel that usually runs at slightly below 1080p (closest possible with 3:2 ratio) despite having a max of 2560 x 1700, simply because the max res is unusable in Google's own OS without a massive amount of tweaking. UI does not scale, taskbar does not scale, have to manually bump up the font size within Chrome, etc. It's embarrassing.
And I say this as someone who really likes the Pixel otherwise.
And I say this as someone who really likes the Pixel otherwise.
I'm posting from a ChromeBook pixel running at 2560 x 1700, and the UI looks great. The taskbar, UI, fonts, etc. are all scaled perfectly.
Have you tried running at 2560 x 1700 on the most up-to-date version of ChromeOS? Some of the issues you had may have been fixed in more recent Chrome releases.
Have you tried running at 2560 x 1700 on the most up-to-date version of ChromeOS? Some of the issues you had may have been fixed in more recent Chrome releases.
I'm posting from an Acer C720 docked to a 1920 x 1080 Benq monitor, and it looks and works just fine. If Open Office was working on ChromeOS, my joy would be extreme.
Which goes to my point - that it would be even easier to do 3) on Android, than it is to do it now on ChromeOS, since Android has nice resolution scaling.
You are living in the past, when Windows was the holy graal for the software companies. Today Android is waaaay outselling Windows. Its like advising Ford to change his cars in such ways as to allow clients to use horses, instead of motors. And yes there are markets for horse cars and laptops today, but those are not the markets where the big profits are.
Open Office
"App runtime for Chrome..."
floor->add(jaw);
Think about that for a while...
floor->add(jaw);
Think about that for a while...
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
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.