First set of Android apps for ChromeOS
chrome.blogspot.com
chrome.blogspot.com
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.
Maybe the Android app had better offline support?
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.
1) http://techcrunch.com/2014/01/28/google-brings-chrome-apps-t...
(Genuine question, not me being a smarty pants.)
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.
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)
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.
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.
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
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.
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".
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.
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.
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.
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 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.
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
[0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...
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.
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 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.
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.
Personally I hope that Android with or without Google will replace Windows.
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.
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.
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.
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.
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?
And I say this as someone who really likes the Pixel otherwise.
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.
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).
floor->add(jaw);
Think about that for a while...