Reputation: 421
I am working on an application that has a real-time thread running.
My computer is slow, and the emulator runs very slowly on it. When I'm testing my app it seems as if the SystemClock.uptimeMillis()
call is returning real-time values from the actual computer clock, meaning that time in the emulator is not running slowly even though the emulator is.
Is this hunch correct? That the emulator clock is tied to the real computer system clock (as opposed to being itself emulated and subject to fluctuation based on the CPU load of the host computer)? Seems like an obvious question, but I couldn't find it up on the internet.
It would make sense if this is the case. I need to know for sure because I need to know if my thread being unable to keep up is simply a symptom of the emulator slowness or if I actually need to redesign things. (Can't test on a real phone because I don't have one yet).
Upvotes: 1
Views: 1505
Reputation: 421
I believe to have determined that my hunch is correct.
I ran some simple tests, e.g:
long start = SystemClock.uptimeMillis();
Log.d("blah", "start");
while (SystemClock.uptimeMillis() < start + 10000)
{
// do some work-intensive stuff here
}
Log.d("blah", "finish");
...regardless of what I did in the intervening 10 seconds (inside the code loop and/or intentionally using my computer to do other stuff to load the CPU) the thread always reports back exactly 10 seconds after it starts (+10ms, overhead I assume), judging by both the LogCat timestamps and a stopwatch, which says to me that a loaded host CPU doesn't dilate the sense of time in the emulator at all, as would be expected.
To change this behavior, I believe that I want to pass an option to the QEMU layer:
$ emulator -avd my_avd -qemu -clock vm
But that may actually just have to do with setting the time when starting the VM (which QEMU apparently does do independently of managing the results of currentTimeMillis(), uptimeMillis(), and nanoTime()). Not sure (documentation for QEMU is pretty rough.) Regardless, the Android QEMU seems to lack the "vm" clock, so the above does not work. Note:
$ emulator -avd my_avd -qemu -clock ?
Available alarm timers, in order of precedence:
unix
But at least I've gathered enough evidence to suspect that my little theory is correct. :-) I don't see how emulated apps could play audio or execute UI transition effects or the like without a link to a real clock, so it makes sense. But it would be nice to have the option of emulating the clock.
Upvotes: 2