First set of Android apps for ChromeOS

http://chrome.blogspot.com/2014/09/first-set-of-android-apps-coming-to.html

by hencq • 12 years ago

153 84 12 years ago

chrome.blogspot.com

pgrote2• 12 years ago

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

georgemcbay• 12 years ago

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.

pgrote2• 12 years ago

Thanks. I was wondering why the few number of apps right now if it isn't a rewrite.

dragonwriter4• 12 years ago

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.

on_and_off3• 12 years ago

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 ?

dragonwriter4• 12 years ago

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.

Zigurd2• 12 years 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.

esolyt• 12 years 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.

panzerboy3• 12 years 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• 12 years ago

"App runtime for Chrome..."

floor->add(jaw);

Think about that for a while...

otibom• 12 years 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

higherpurpose2• 12 years 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.

4thjuly• 12 years ago

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

dragonwriter4• 12 years ago

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.

andcase• 12 years ago

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.

wvenable3• 12 years ago

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.

eslaught3• 12 years ago

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.

throwawaydjasda2• 12 years ago

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.

ZenoArrow• 12 years ago

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?

AdmiralAsshat2• 12 years ago

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.

rawatson• 12 years ago

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.

mjcohen2• 12 years ago

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.

higherpurpose2• 12 years ago

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.

SyncTheory13• 12 years ago

-- "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).

final2• 12 years ago

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.

mwcampbell2• 12 years 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• 12 years ago

Two of the applications mentioned in the announcement (Vine and Sight Words) use NDK.

lxgr• 12 years 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• 12 years 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..

cwyers4• 12 years 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-t...

dragonwriter4• 12 years ago

When they did those things, they already started merging the platforms.

cwyers4• 12 years 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.

final2• 12 years 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• 12 years ago

Your thing, doesn't relate to his thing. Not one bit.

todd3834• 12 years ago

If Microsoft created and maintained both Linux and Microsoft, your analogy would make more sense.

cwyers4• 12 years 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.

on_and_off3• 12 years ago

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.

madoublet• 12 years ago

I don't think it is as big as it once was with frameworks such as Polymer and Ionic.

tecnik• 12 years 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• 12 years 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?

panzerboy3• 12 years 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• 12 years 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".

mwcampbell2• 12 years 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• 12 years ago

I think this is it, or at least part: https://chromium.googlesource.com/arc/arc

ecesena• 12 years ago

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

mcintyre1994• 12 years ago

I wish the results of the form [0] for favourite apps to port was public.

[0] https://docs.google.com/forms/d/10mlIGJq2ENubhkvTJYk11ujckA8...

grimmfang• 12 years 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.

mjcohen2• 12 years ago

Open Office

TheMagicHorsey• 12 years 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.

MarkMc2• 12 years ago

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

podgib• 12 years 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.

derefr2• 12 years 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• 12 years 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)

pjmlp2• 12 years ago

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.

jkn• 12 years ago

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

MarkMc2• 12 years 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.

guardian5x2• 12 years ago

With a WebApp you had still a bigger reach with your App, for example iOS and Windows devices.

tmzt2• 12 years ago

Of course, Chrome runs on both of those platforms, and this (ARC) could as well.

AdmiralAsshat2• 12 years 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.

panzerboy3• 12 years 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.

SimeVidas2• 12 years 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• 12 years 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

SimeVidas2• 12 years 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.

First set of Android apps for ChromeOS

Related Stories