6 ms·

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

by byuu 12y ago

Can anyone explain how this differs from using an Android emulator? (http://developer.android.com/tools/help/emulator.html 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?

cryptoz 12y ago
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.
- umsm 12y ago
  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.
  - IgorPartola 12y ago
    It's still dog slow on a high end MacBook Pro (2012 model).
- vamur 12y ago
  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.
  - srcmap 12y ago
    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.
    - ecspike 12y ago
      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.
- echeese 12y ago
  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
- ingve 12y ago
  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-hardware-accelerated-execution-manager https://software.intel.com/en-us/android/articles/intel-hard...
- fsiefken 12y ago
  intel android on virtualbox runs good enough for testing on a fast machine.
- passfree 12y ago
  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.
- dozy 12y ago
  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.
  - tokenizerrr 12y ago
    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-windows https://developer.android.com/tools/devices/emulator.html#vm...
    - mappu 12y ago
      >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.
      - Veratyr 12y ago
        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 http://www.amd.com/en-us/products/server/opteron/6000/6300 When they say Intel they mean Intel unfortunately.
    - dozy 12y ago
      Try out Genymotion, I think that's your best bet for AMD.
    - 12y ago
- ryanmarsh 12y ago
  This. I tried to develop for Android once. Went groveling back to Xcode, apologizing for cursing its many flaws.
- byuu 12y ago
  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.
  - duaneb 12y ago
    Dalvik apps should run natively unmodified. No need for an emulator at all.
- thegeomaster 12y ago
  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.
  - q_revert 12y ago
    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.
cbhl 12y ago
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.
TheMakeA 12y ago
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.
rquirk 12y ago
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.
- rquirk 12y ago
  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.
on_and_off 12y ago
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.

by byuu 12y ago

cryptoz 12y ago

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.

umsm 12y ago
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.
- IgorPartola 12y ago
  It's still dog slow on a high end MacBook Pro (2012 model).
vamur 12y ago
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.
- srcmap 12y ago
  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.
  - ecspike 12y ago
    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.
echeese 12y ago
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
ingve 12y ago
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-hardware-accelerated-execution-manager https://software.intel.com/en-us/android/articles/intel-hard...
fsiefken 12y ago
intel android on virtualbox runs good enough for testing on a fast machine.
passfree 12y ago
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.
dozy 12y ago
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.
- tokenizerrr 12y ago
  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-windows https://developer.android.com/tools/devices/emulator.html#vm...
  - mappu 12y ago
    >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.
    - Veratyr 12y ago
      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 http://www.amd.com/en-us/products/server/opteron/6000/6300 When they say Intel they mean Intel unfortunately.
  - dozy 12y ago
    Try out Genymotion, I think that's your best bet for AMD.
  - 12y ago
ryanmarsh 12y ago
This. I tried to develop for Android once. Went groveling back to Xcode, apologizing for cursing its many flaws.
byuu 12y ago
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.
- duaneb 12y ago
  Dalvik apps should run natively unmodified. No need for an emulator at all.
thegeomaster 12y ago
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.
- q_revert 12y ago
  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.

cbhl 12y ago

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.

TheMakeA 12y ago

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.

rquirk 12y ago

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.

rquirk 12y ago
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.

on_and_off 12y ago

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.