Hacker News new | past | comments | ask | show | jobs | submit login
Chromeos-apk – Run Android APKs on Chrome OS, OS X, Linux and Windows (github.com/vladikoff)
471 points by ProfDreamer on Sept 19, 2014 | hide | past | favorite | 92 comments

This is amazing. There's a long reddit thread and some additional instructions here: http://www.reddit.com/r/Android/comments/2gv035/you_can_now_...

From the README:

> Soundcloud - Works, crashes when playing sound

Funny definition of 'works'.

I experience the same thing with devs and 'done' all the time.

"It's done; it just has some bugs that need fixing."

To be fair, I've said this sentence myself in earnest several times.

OTOH, software that has no bugs in need of fixing is usually not a realistic goal.

You can say it will probably never be done, or you update your definition of "done" to "it has no bugs stopping a release". Personally I prefer the latter.

From my experience the problem isn't the existence of bugs (like the existence of gravity), but the widespread occurrence of the cowboy programmer with very limited attention span.

Often there are tons of TODO comments left in the code (including TODO comment this class), unit tests are non-existent, a simple smoke test will cause a null pointer exception or not even deploy, or they committed schema migration SQL scripts but did not change the entities/data objects corresponding to those tables so the - now mandatory - new columns cannot even be FILLED by the app.

Stuff like that, that isn't DONE, it's deserving a punch in the face. OTOH, it may be symptomatic of our don't-blame culture that the consulting firm in question isn't fired on the spot or the much needed punch in the face isn't delivered. Those are days I wish we had US-American at-will employment and hire/fire culture.

It almost always means "bugs blocking release" in my experience. Usually the sentence I quoted is developer speak for "it's framed out, and the core functionality has been shown to work under this scheme," or "all of the known-to-be-risky stuff is done and all that's left is tedium," or perhaps some cross between the two.

It's not malicious. You could argue it's negligent, but I would only agree with that assessment if the Dev in question doesn't include the "it just has some bugs that need fixing" bit and is attempting to see what he/she can squeak by QA because he/she doesn't want to work on that thing anymore.

Otherwise it just reflects the difference in focus between writing code and building a product.

I guess that "works" just means "starts".

That's like a winedb entry that says "game works" followed by "crashes after intro video"!

Yeah Soundcloud is failing :( But Angry Birds works :)

So, now we can write apps in Angular that run on the web and compile to Java so that we can install them to Android, running on ChromeOS, running on OSX.


Edit: Perhaps the punny nature of this is deserving of downvotes, but the statement above is the actual use case I presented to a co-developer, discussing how this project could be of use to our app, which was built with Ionic.

FWIW, there's value in it (the app, not necessarily this post) even if it means having to unplug fewer devices to swap them out with different devices to test.

Can anyone explain how this differs from using an Android emulator? (http://developer.android.com/tools/help/emulator.html)

Is it a matter of features, speed, or convenience? Obviously, all of those can be overcome, be it as a fork of the official emulator or as a third-party emulator. For instance, this new Chrome extension must be the same thing under the hood: a Dalvik runtime, possibly an ARM->Intel recompiler for any NDK applications, etc.

I figured the only reason this wasn't done to mass effect already was because it wasn't in demand. But if it's so desirable, surely creating an actual emulator would be superior to hacking up web browser extensions and ostensibly playing cat-and-mouse with Google over this?

It's been a few years since I dared run the official emulator, and I used to have an underpowered computer for development, but last time it took about 10 minutes to boot Android and another 2-3 minutes to open an app.

I presume it's been improved since then and runs nicer on better hardware, but my first impulse is that speed is a huge concern in Android emulation. Convenience only matters if speed is solved, but then it becomes huge.

Hey Android developer here. I used to have the same issue - even on a fantastic machine the emulator would run very slowly, or not at all. This is now completely different

You no longer have to emulate ARM. You can run the native x86 image, using GPU acceleration, and the thing screams. I can get multiple high resolution emulators running in parallel without issue. I'm still used to debugging every single compile on an actual device having been through years of slow emulation, but let me tell you that the environment is quite different now. Genymotion is even better, but not by much with regards to performance.

The last time I worked on Android (which was about 6-12 months ago) I tried to get the x86 image working on my laptop, but it apparently requires an intel processor[1]. Do you happen to be aware of any speedups for AMD processors?

[1]: https://developer.android.com/tools/devices/emulator.html#vm...

Try out Genymotion, I think that's your best bet for AMD.

It looks like they are using KVM to accelerate in the linux sdk, maybe that will work on amd?

Yes, KVM acceleration works fine with AMD processors.

>The software requires an Intel CPU with Virtualization Technology (VT) support

Surely by "Intel" they mean "x86-compatible"? Many AMD cpus have the necessary VT-x, you shouldn't have any trouble here.

AMD processors don't have VT-x, it's an Intel specific feature. AMD has their own equivalent, called AMD-V. You can have a look at one of their top CPUs if you're in doubt: http://www.amd.com/en-us/products/server/opteron/6000/6300

When they say Intel they mean Intel unfortunately.

HAXM is enabled, I'm using an Intel image, and my system is Haswell with 8GN RAM? The official emulator still moves incredibly slowly. Genymotion just works.

The official emulator is so slow it's a joke. Genymotion or Intel HAXM are a bit better but the whole process is clunky. Once Google introduces Android runtime to Chrome, developing for Android should become much easier.

Are you talking about ChromeOS? I think ChromeOS is not good enough as dev machine. Almost all of them have very limit amount of ram and disk.

Dev system needs at lease able to run eclipse or android studio + emulator + adb at the same time.

A Chromebook Pixel is. It's doable if you are ok with command-line and building/deploying to a device using gradle.

Admittedly there are few on the market.

I'm running Eclipse and the emulator on a 4 year old Mac Pro. Initial startup time for the emulator is about 20 seconds, but after that first hit has been absorbed, it generally takes about 8-10 seconds whenever I run a new build of the app I'm developing. (This is with HAXM [0] enabled. Still far too slow, so pretty much everybody does their development on actual Android devices, but far from the times reported in this thread.)

[0] https://software.intel.com/en-us/android/articles/intel-hard...

This is why I loved developing for Firefox OS. Their simulator is really just Gecko inside a smaller window and with simulated touch events. You could do some amazing things, such as live-inspect DOM on a connected device and treat it as if it were a local webpage. And now the WebIDE built into Firefox seems to be even more pleasant. I even used to sometimes test the app in my Firefox browser, without bothering to connect a device or fire up the simulator. It was super-speedy.

I'm so sad Firefox OS is probably never going to properly take off. I use Android and like it very much, but development for it is a literal nightmare.

Another vote for firefox OS here, I definitely think they're making a better effort than most in this space. The fact that firefox is targeting entry level devices in a serious way is another positive for me. I've been using a ZTE open as my primary device, and although the hardware is absolutely awful, I've managed to get by, mostly just because of a sentimental attachment to firefox.

I agree it's somewhat unlikely to be too successful, but I definitely think they're at least aiming in the right direction.

It's a lot better now with HAXM, and host gpu support.

Just timed starting up a fresh instance, unlocking it and starting Maps.

This is starting from when I clicked launch in AVD manager on a mid-range laptop from 2011

1:25 emulator showed up

1:53 until lock screen

1:61 until maps loaded

The Android emulator is terrible. It is one of those things that will speed up Android adoption if made better. iOS simulator is so much nicer to work with.

I don't know if anything changed within the past 2 years, but I had a high-end system 2.5 years ago where the emulator was just as slow as you describe it.

It's still dog slow on a high end MacBook Pro (2012 model).

Surely the Chrome extension is also an emulator, albeit a much faster one. Just seems like a large opportunity to create and sell the Parallels equivalent for Android, given the buzz this seems to be creating.

Edit: looks like that is done by Bluestacks and Genymotion. So I guess this is just about the novelty of the hack.

Dalvik apps should run natively unmodified. No need for an emulator at all.

intel android on virtualbox runs good enough for testing on a fast machine.

This. I tried to develop for Android once. Went groveling back to Xcode, apologizing for cursing its many flaws.

My guess is that this is closer to a simulator. Just a Dalvik runtime and any necessary OS hooks, so it should be much faster than an ARM emulator or x86 Android build running in a virtual machine.

    possibly an ARM->Intel recompiler
The NDK has an x86 target, so it would make sense to just rely on developers providing those in their APK.

Last I checked the Android emulator was dog slow because it did CPU-level emulation of an ARM computer with qemu. You could get better performance (like iOS Simulator/OS X) by providing the runtime libraries with "native" implementations using the host's libraries.

I've just tried it with my own apps.

Features - it is missing logging of any sort, so when an app crashes you don't know why. You can't use adb logcat nor presumably connect a debugger (I just use logcat most of the time anyway). e.g. an app I'm working on crashes when trying to use the "share" feature. this is probably to be expected, but without a log or anything it's tricky to know why. A game I made uses the NDK and despite having the x86 version of the library in the APK, it crashes on startup.

Speed - this is the killer feature! The emulator is useless (at least on Linux) as the native drivers cause it to hang IME, the startup time is too large, and when running an app is too slow to really judge its usage. You can use the emulator in a pinch, but better to test on devices. This means plugging them in and swapping devices (first world problems ;), which is a bit of a pain.

Convenience - the regular build-install-debug cycle is incorporated into the Android build system, whereas with this solution you have to faff about running your own scripts to execute chromeos-apk on the APK, then install by hand from the extensions screen. However you can debug right on the same PC without having to have a phone or tablet available.

So the main difference is speed and a bit of convenience. It is as fast as running the app on a real Android device, without having to have one handy. I can see why Google didn't release this for all apps yet, as there are a lot of places that it crashes out. But it's really cool that this works at all, and I'm sure it'll only get better.

Slight update, if you set `"enableAdb" : true` in the app's manifest.json, then you can connect adb and view the log. This makes the whole thing miles better than the emulator.

An emulator is a dev tool that recreates the whole OS. It is very useful for devs since that way you can test your app on multiple architectures or Android versions. You can even use it to run automatic tests after each commits (or each day) in order to control your app quality.

On the other hand, what we have in ChromeOS (and soon Chrome) is a reproduction of the Dalvik/ART runtime. As a runtime, its only job is to allow Android apps to run.

It probably was an huge amount of work for the Chrome team (apparently, they have been working on it for quite some time but now that it is here, it means that with it installed you can run Android apps on your desktop computer.

so, it is both a matter of features, speed and convenience. I am an Android dev. In the startup I work for, we have mobile apps (Android, iOS and even Windows Phone), a website and are even working on desktop versions of our product. I don't know what this will mean for us though. Sure, we can use this new runtime to make our Android app run on the desktop but it has been thought out for mobile UX so a huge amount of work would be necessary to make it work nicely with the mouse+keyboard combo. It is very nice that we now have that option though, especially with Material Design looming in the corner.

Neat proof of concept.

I hope Google gets us something official sooner rather than later. It's a little disheartening that I own a Chromebook Pixel and yet I can't use Google's own hardware to design or test Android apps without installing Eclipse on a sideloaded Linux chroot via Crouton.

If you're a developer you'll want a real Linux environment anyways so I would just go the crouton route. I've been really happy with my C720 and crouton running Ubuntu.

You can go the full-installation route as well on C720:

* Xubuntu https://www.distroshare.com/distros/get/14/

* Ubuntu https://www.distroshare.com/distros/get/12/

How is that disheartening? The whole point of the Chromebook is to only use the web.

The fact that Google is starting to roll out the ability for Android apps to run as Chrome apps suggests that they are aware of the limitations of being "web only". It also stands to reason that if they're going to soon allow Android apps to run under ChromeOS, you should be able to develop them too, no?

To boot, the Pixel's relatively decent hardware, high-res display, and touchscreen just seem like it would be ideal for testing Android apps if it could be done natively.

I doubt it will ever be as simple as I would like. But I can dream.

>It also stands to reason that if they're going to soon allow Android apps to run under ChromeOS, you should be able to develop them too, no?

Why? Can you develop Android apps on your phone?

AIDE lets you develop Android apps on Android devices.


There are no limitations of what you can do via a web browser. My company personally developed and delivered projects otherwise thought not possible in browser environments. With the help of extensions and solid JS and HTML, everything is possible. Of course super low level stuff are out of the picture but this is not normal users will be concerned about.

> "There are no limitations of what you can do via a web browser" [...] "Of course super low level stuff are out of the picture"

...so what you're saying is there are limitations around what you can do with a browser.

> There are no limitations of what you can do via a web browser.

So when do we see Crysis or HPC in HTML 5?

Sorry, but this is ignorant at best and dishonest at worst. There are huge, massive practical limitations to what you can do via a web browser.

If they're going this roundabout way about bringing native apps to a browser-OS platform, I wonder they they couldn't just use the already native Android platform, which...already had the Chrome browser.

If Chromebooks can't be used to develop Android apps, then Google developers aren't using Chromebooks. Eating your own dogfood is important.

Developing Android apps isn't an intended use case of the Chromebook. As such, Chrome OS devs can still "eat their own dogfood" without developing Android apps on a Chromebook.

I work for a navigation company. We deploy navigation software on 3rd party, purpose built hardware following model analagous to Chrome OS and the "Chromebook" moniker. Even though I use our devices in my car, would you say that I'm not "eating my own dog food" because I'm not writing software on the device in my car?

only if the device in your car is supposed to be usable as a general purpose computer

Only if you're making food intended to be usable by foodmakers? This is like expecting a father of 5 to only use a motorcycle because he works at a motorcycle factory.

Except Google is selling Chromebooks at car dealerships and calling them cars.

What adverts are you looking at? All the Chromebook marketing stuff I can find is pretty clear that they're about browsing the web and not much more.

From Google's official Chrome page[1]:

"Introducing the Chromebook Pixel A laptop that brings together the best in hardware, software, and design."

"HP Chromebook 11. Made with Google. Everything you need in one laptop. For $279."

"A new type of computer designed to help you get things done faster and easier."

One click from there is the features page[2]:

"Meet Chromebook A new type of computer with everything built-in. For everyone. Starting at $199."

"Gets everyday things done Your favorite apps are built-in and one click away. Find thousands more in the Chrome Web Store."

"Meet the family Chromebooks are fast, easy to use, and great for everyone in your life who could use a computer."

Laptop. Computer. Everything built in. Thousands of apps in the Chrome Web Store. "For everyone in your life who could use a computer."

Google is absolutely, positively claiming these are computers for everyone.

1) https://www.google.com/chrome/devices/index.html

2) https://www.google.com/chrome/devices/features/

Wouldn't that make Android much less useful?

I will absolutely go nuts if this thing manages to run OneNote on my Debian desktop.

Follow up: Of course it doesn't work. It contains some native code. I don't think I'm that adventurous that I'll try it with a arm multiarch Chrome.

Please don't downvote this.

What is on debian today that you can't get on or don't like about OSX? I ask this as a former Linux die hard. What am I missing back in the Linux world these days?

Also, One Note is killer isn't it? It is so much nicer than Evernote. I've loved One Note ever since the first time it shipped with Office. It's so great to see Microsoft porting their better apps to other platforms.

I can't (easily and reliably) get OS X to run on my non-Mac computer while Debian runs like a champion, this is what's missing from OS X :) Otherwise I would like to try it seriously as my main OS if I get a chance in the future. Heck, I even used Windows 7/8 for a few years and even they get good enough after installing Cygwin, so I can't think of any showstoppers that would make me dislike OS X. (Well, lack of the vast apt repository may be a problem, but they say very good things about homebrew and MacPorts, so this wouldn't be an issue I guess.)

I was a heavy OneNote user in Windows and accumulated a lot of stuff in it, so after coming back to Debian, I desperately tried running it in Wine and also tried the Web version but unfortunately they didn't cut it. Currently I use CherryTree[0] and it gets the job done but it's very far away from the OneNote experience.

[0] http://www.giuspen.com/cherrytree/

I use SimpleNote, its dead simple text notes, not a full replacement for OneNote of course, but it suits my needs and has an open api.

I use and love it also :) But it doesn't satisfy all my note taking needs so I use it mostly for sharing and storing short-lived texts that I need to access from my phone.

I heard Simplenote developers was also thinking about a native & offical Linux client. I can't wait to try it out.

If you have an iPad with a bluetooth keyboard OneNote is great on iOS. Also, thanks for the link to Cherry Tree. It looks cool.

You're welcome. I'll try it when I get a chance. It's nice to hear Microsoft had done a good job with OneNote in iOS instead of getting away with a half baked port.

What is on debian today that you can't get on or don't like about OSX?

The ability to use any hardware other than a Mac, presumably.

|What is on debian today that you can't get on or don't like about OSX?


and I got downvoted... sheesh HN.

Saying "please don't downvote this" does not immunise you from getting downvoted.

It was more like, "hey wait I'm not attacking Linux, just read the full comment". Didn't work.

I read the whole comment. It is still an off topic plug.

And a ridiculous one

Logged in after many months just to downvote you, then realized I can not :( Please accept this sincere comment as a dovnvote!

Lesson learned. Thank you.

This is amazing.

I hope Google could really carry this project as far as possible. The next several major issues would be polishing up the platform, eliminating the bugs, unifying the android and chromebook development interface. Think of one day when android developers could actually design apps for the desktop. How cool would that be?

That's when Microsoft should really get worried.

We worked with the ARC team at Vine as a launch partner, there were 0 modifications that we had to do to get it working on ARC. The only difference was that the "bugs" we had to fix were all reproducible on Nexus devices as well BUT the threading model had to be more strict on ARC in terms accessing system resources.

Running Android apps in Chrome on desktop is huge! I'm glad that the ARC runtime I provided in https://github.com/vladikoff/chromeos-apk/issues/5 helped to achieve this.


Hope this means good netflix support in Linux.

Netflix should work on Linux natively (at least in Ubuntu) very soon http://www.omgubuntu.co.uk/2014/09/netflix-linux-html5-nss-c...

Interesting, Google announced working on this on this year's I/O and posted the first apps just one week ago ( http://chrome.blogspot.com/2014/09/first-set-of-android-apps... ).

Java makes a triumphant comeback in the browser?

I have had some success running Android x86 (http://www.android-x86.org/) in VirtualBox.

Fuuuuu Out There a good game only available on mobile crash with this solution ...

Dam but it looks full of promise i hope one day it will work well ...

How is this really good? Android apps are really good but they are designed for touch interface on mobile devices, not desktop.

A lot of new laptops of today have touch screens displays, this trend will only grow in the future.

could you use this to run ChromiumTestShell.apk on windows for testing android chrome rendering?

[1] http://commondatastorage.googleapis.com/chromium-browser-con...

Awesome! Works for me on arch linux running latest chromium. Much faster than running android emulator!

Google needs to do this.

Its about bloody time!

Want Open Office!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact