Re: [android-developers] Re: How to speed up the Android emulator.
Wow, I thought the startup time (of 30-60 seconds) on my two-year-old Gateway laptop (with 4GB RAM) was slow!! No idea what's wrong with your setup, but something must be wrong with it or with the emulator startup config or something On Sat, Oct 23, 2010 at 6:50 AM, gbarros gabriel.bar...@gmail.com wrote: I get a couple HOURS of load time on my linux box. 2x p4 3Ghz cpu use reported by /bin/top is 4% for emulator process. launch emulator with `emulator -cpu-delay 0 -no-boot-anim -cache / ramdisk/cache -noaudio` can't think of anything else to speed it up. i usually waits a couple hours then give up and use a windows box. i think i never managed to wait for the emulator to start on linux... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to speed up the Android emulator.
I get a couple HOURS of load time on my linux box. 2x p4 3Ghz cpu use reported by /bin/top is 4% for emulator process. launch emulator with `emulator -cpu-delay 0 -no-boot-anim -cache / ramdisk/cache -noaudio` can't think of anything else to speed it up. i usually waits a couple hours then give up and use a windows box. i think i never managed to wait for the emulator to start on linux... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to speed up the Android emulator.
Re-hello, and thanks for all answers. Good to hear that the emulation speed on this Linux machine is within the normal limits, so I can continue learning and coding with full motivation. Rumours say that Canonical (the company behind Ubuntu) is going to make Android apps to run on their Ubuntu Linux. Ref: http://i1.no/095q/ Maybe we can soon develope, (let' say 90% of all) Android apps on X86. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to speed up the Android emulator.
I could not get the Emulator to run newly build Apps from within Eclipse when emulator is already up and running and I had to relaunch the Emulator every time. I tried different things but to no avail. Please help. I am running Android SDK 1.5 r3, latest DDMS and Eclipse Galileo in Windows Vista. Any ideas will be greatly appreciated. THANKS. On Thu, Aug 27, 2009 at 6:49 PM, Dianne Hackborn hack...@android.comwrote: There is a simulator build for Linux that compiles everything to native code that (sometimes) works. Trying to do this kind of thing for Android is pretty tricky, however, because the system relies heavily on basic operating system objects like processes, various mechanisms for communicating between them (such as sockets and binder), etc. Trying to get a somewhat realistic environment running natively on a desktop is thus tricky enough if that desktop is Linux; it has actually been a very long time since the simulator did anything besides run all of the applications as threads inside of a single process, which is extremely different than the real environment. Someone could maybe cobble this together to work on Linux again (requiring you to install a desktop build of the binder driver etc), but it's really difficult to maintain even the single process version. Trying to get this running on something like Windows would be a long long rough road. On Thu, Aug 27, 2009 at 9:49 AM, Chris Stratton cs07...@gmail.com wrote: On Aug 27, 10:24 am, Moma osm...@gmail.com wrote: It takes 35 seconds to cold start the emulator and acitivity from the Eclipse IDE. Likely faster than cold booting an actual phone It takes 12 seconds to reload the acitivity when emulator is already up running. Not significantly different from a hardware device either Do you think these numbers are normal? Is there any possibility to speed up the emulation speed of QEMU? You could use an x86 build of android running in a hypervisor-type virtual machine (VirtualBox, etc) so that the processor itself doesn't have to be emulated except when doing privileged/system things... that's how the palm pre development kit handles things. I think it's good that the android emulator is closer to current devices for accuracy in testing, but when just iterating over software issues having something that's faster (even unrealistically fast compared to any existing phone) would be handy. Actually, I keep thinking it should be possible to have a davlik environment running within an ordinary desktop linux, though you might have to do something like run everything under the current UID which would grossly break the security model... -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to speed up the Android emulator.
On Aug 27, 6:49 pm, Dianne Hackborn hack...@android.com wrote: Trying to get a somewhat realistic environment running natively on a desktop is thus tricky enough if that desktop is Linux; it has actually been a very long time since the simulator did anything besides run all of the applications as threads inside of a single process, which is extremely different than the real environment. Someone could maybe cobble this together to work on Linux again (requiring you to install a desktop build of the binder driver etc), but it's really difficult to maintain even the single process version. Trying to get this running on something like Windows would be a long long rough road. Ah, so it has been tried and found ugly. Running an x86 build in a VM should work though (to the degree the x86 builds work), and should be substantially faster then emulating an arm chip, right? I do think emulating the processor was the right choice for the official sdk emulator (vs the pre sdk's x86 VM approach), but the VM approach does seem like it would be a great unofficial tool for speeding up less accuracy-critical work. Or we could go the other way... instead of trying to graft android onto a desktop linux, we could try to graft enough of a desktop linux userland onto an x86 android netbook to run eclipse and gcc and have ourselves a hosted development playground... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to speed up the Android emulator.
On Aug 27, 10:24 am, Moma osm...@gmail.com wrote: It takes 35 seconds to cold start the emulator and acitivity from the Eclipse IDE. Likely faster than cold booting an actual phone It takes 12 seconds to reload the acitivity when emulator is already up running. Not significantly different from a hardware device either Do you think these numbers are normal? Is there any possibility to speed up the emulation speed of QEMU? You could use an x86 build of android running in a hypervisor-type virtual machine (VirtualBox, etc) so that the processor itself doesn't have to be emulated except when doing privileged/system things... that's how the palm pre development kit handles things. I think it's good that the android emulator is closer to current devices for accuracy in testing, but when just iterating over software issues having something that's faster (even unrealistically fast compared to any existing phone) would be handy. Actually, I keep thinking it should be possible to have a davlik environment running within an ordinary desktop linux, though you might have to do something like run everything under the current UID which would grossly break the security model... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to speed up the Android emulator.
There is a simulator build for Linux that compiles everything to native code that (sometimes) works. Trying to do this kind of thing for Android is pretty tricky, however, because the system relies heavily on basic operating system objects like processes, various mechanisms for communicating between them (such as sockets and binder), etc. Trying to get a somewhat realistic environment running natively on a desktop is thus tricky enough if that desktop is Linux; it has actually been a very long time since the simulator did anything besides run all of the applications as threads inside of a single process, which is extremely different than the real environment. Someone could maybe cobble this together to work on Linux again (requiring you to install a desktop build of the binder driver etc), but it's really difficult to maintain even the single process version. Trying to get this running on something like Windows would be a long long rough road. On Thu, Aug 27, 2009 at 9:49 AM, Chris Stratton cs07...@gmail.com wrote: On Aug 27, 10:24 am, Moma osm...@gmail.com wrote: It takes 35 seconds to cold start the emulator and acitivity from the Eclipse IDE. Likely faster than cold booting an actual phone It takes 12 seconds to reload the acitivity when emulator is already up running. Not significantly different from a hardware device either Do you think these numbers are normal? Is there any possibility to speed up the emulation speed of QEMU? You could use an x86 build of android running in a hypervisor-type virtual machine (VirtualBox, etc) so that the processor itself doesn't have to be emulated except when doing privileged/system things... that's how the palm pre development kit handles things. I think it's good that the android emulator is closer to current devices for accuracy in testing, but when just iterating over software issues having something that's faster (even unrealistically fast compared to any existing phone) would be handy. Actually, I keep thinking it should be possible to have a davlik environment running within an ordinary desktop linux, though you might have to do something like run everything under the current UID which would grossly break the security model... -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
