0

I bought a book and it suggested the use of the Android Studio Manager which I am now using. However when I try to utilize the emulator in this package it gets to the splash screen or a picture of a phone with android written on it and then stops.

I have left it running for up to an hour and a bit and it still doesn't get to a usable state although there is still activity taking place in the logcat file of the Android Device Monitor. This leads me to my first question, is longer than an hour an expected first load time for this particular emulator with my ballpark specs? It seems really excessive...

To clarify my AVD settings I am using an ARM cpu for API 23 with a 1080 x 1920 xxhdpi 4.3inch screen. I cannot use any emulators which require HAXM.exe as my processor does not support the VTx functionality. I am currently using host GPU setting rather than snapshot and have set the device RAM as 512MB in my AVD setup. So question 2 do these settings sound sort of sensible?

I do own an android device and am considering using it for my testing but am worried that I will spend forever bundling and installing apps on my phone if I try to use it as the basis for my learning. So question 3 is, is this the case or will the bundle time be quicker in the long run than waiting for emulation platforms?

Just to be clear I am at the hello world.apk stage of programming.

Any advice on speeding up the emulator so I can use it...

davejal
  • 6,009
  • 10
  • 39
  • 82
GregB
  • 73
  • 10
  • Have you tried Genymotion? The built in emulator is really really bad. Or even a real device- I'd rather test on an actual phoen than the built in emulator. – Gabe Sechan Jan 20 '16 at 22:03
  • It takes maybe 10-20 seconds to go from android studio to your phone. Don't worry about it. The emulator is very slow, so slow in fact that it is even slower than using your actual phone – Chronicle Jan 20 '16 at 22:05
  • Have you tired using the x86 image in the SDK emulator? – Maks Jan 20 '16 at 22:23
  • I am worried that as files go from hello world to a decent game size the compile time will be epic for very small changes and checking. Is this not the case? And thanks Gabe but unfortunately Genymotion requires HAXM. – GregB Jan 20 '16 at 22:24
  • Thanks. Yes Maks I started out with X86 image but it is the one that requires HAXM/ VT - x processor acceleration and so will not work on my machine. – GregB Jan 20 '16 at 22:25
  • GregB if you are willing/able to downgrade to an earlier version of the SDK you can force the emulator to run with VTx acceleration, see: http://stackoverflow.com/a/34054673/85472 – Maks Jan 20 '16 at 23:09
  • 3
    I purchased a "pay as you go" phone for $9usd. I use that phone for debugging rather than running the emulator in many cases. It's especially helpful when you're trying to use a real peripheral on the phone (like the camera or accelerometers). This way I shift the processing and ram to the phone rather than emulate at all. I still emulate 30% of the time, but 70% I just debug directly to the device via USB. – Baronz Jan 21 '16 at 01:50
  • @GregB My advise, use a physical device. Buy a device that's running the version of Android that your app is targeting as it's minimum, that way you know that it runs on there, and also use your phone that has the updated Android OS – SMKS Jan 21 '16 at 02:18
  • 1
    using an actual device is the best solution. `I will spend forever bundling and installing apps on my phone` no reason for that. just setup the dev options in the device, plug it, and it behaves like a emulator – njzk2 Jan 21 '16 at 02:38
  • Baronz and njz do you mean that if I have the usb connected I can simply select my phone as the run device and run programs from the studio the same way as with the emulator? If so that solves all problems. I thought each change in code would have to be recompiled as an apk transferred to the phone, installed on the phone and then checked... – GregB Jan 21 '16 at 13:29

4 Answers4

2

Unfortunately, for any kind of emulation (running Linux or Windows under VMWare, or emulating an Android device under the AVD), it helps to have lots of RAM, a fast 64-bit CPU ... and the VT extensions.

There are things you can do to speed up your emnulator, however:

1) smaller screen size <= this is a biggie!!!

2) Set "use host GPU"= Y

... and, something I haven't tried, but looks interesting:

3) Run an Android image under QEMU:

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • 1
    "use Host GPU" made a massive difference for me. Where previously it took 20s to start up and each action would take 2-5s to register, it now starts up in 5s and is faster than any real phone. I'm using a GTX 1060 so YMMV. – Prashanth Chandra Nov 23 '16 at 13:50
1

With your configuration, as Gabe Sechan recommended, you should try using Genymotion instead of the built in emulator.

https://www.genymotion.com/

Link to their free personal use version: https://www.genymotion.com/#!/download

Distwo
  • 11,569
  • 8
  • 42
  • 65
  • I tried this but it requires VTx processor functionality. – GregB Jan 20 '16 at 22:21
  • Why would using Genymotion be any more benficial than using the SDKs emulator with a x86 image. given that Genymotion is *not* an Arm emualtor and that is explicitly what the original question mentions that he needs to use. – Maks Jan 20 '16 at 22:21
  • Genymotion is dope. Much faster than the Android Studios emulator, use it and you will end up with less holes in your wall due to frustration. – SMKS Jan 21 '16 at 02:15
1

That is a lot of questions, but to answer the general thrust:

Genymotion, like WINE, Is Not an Emulator! Neither is VMWare or VBox. These are virtualization technologies that may require VTx processor hardware support. This is exactly because they are NOT emulators, but co-located OS instances - its your machine that becomes virtualized into many machines, with separate IPs, etc. The OP has repeatedly stated VTx is not supported by his system (generally intended for servers).

The emulators are slow because they are just another process scheduled by your real OS. That is why they all share the same IP address - there is only one machine. They are good for layout tests with various screen resolutions. You could also try Eclipse, if Studio is giving problems. You can still download the latest SDKs with it. ADT is no longer supported, but is very stable.

For any other tests, I have found that deploying directly to a device is actually better (but monotonous - you might want to write an ant or other build script to do this).

Other than buying additional devices (and a rack, and usb hubs, and UPS, and a cooling system that sounds like turbines recycling), your best bet is to use the alpha and beta test launches, and cultivate relationships with a variety of device users. Depends on whether you want more friends, or a wicked cool ARM stack. Decisions ...

The worst, but most effective way is to just go ahead and publish early and often. Free QA, but your users will punish you for it with a hail of 1-star reviews. You could then just republish under a different package name to zap all reviews (also zaps download stats, effectively orphaning the old app - dark magic if it is also a paid app).

Google is launching a cloud testing lab (shared ARM stacks) which will run your app on the most popular real device/os combos simultaneously, and send back all the actual logs and real vidcaps of the screens in seconds. This a real answer to cross platform testing challenges like these, minus the turbine recycling noises, which they could easily add to the web UI.

Dominic Cerisano
  • 3,522
  • 1
  • 31
  • 44
1

Thanks for the info all. Sounds like the general consensus is my best route is to use my phone for all debugging. I will try the other settings that have been suggested before I bin the emulator but in a lot of ways I think it will be more fun to see it all going on on my phone! Thanks all and I doubt you've seen the last if me!

GregB
  • 73
  • 10