Hacker News Reader

Comment by byuu | Hacker News Reader

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?

View on HN

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.

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

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.

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

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

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

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com