I want to measure the FPS of my Android Augmented Reality app. I am trying to follow the documentation for using dumpsys framestats.
This is my procedure:
connect device (Galaxy Tab S5e) via USB to computer (MacBook Pro)
Launch application
Open terminal and enter adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats
I get results. The documentation says that I should get some CSV data (which I do). Here it is:
Flags,IntendedVsync,Vsync,OldestInputEvent,NewestInputEvent,HandleInputStart,AnimationStart,PerformTraversalsStart,DrawStart,SyncQueued,SyncStart,IssueDrawCommandsStart,SwapBuffers,FrameCompleted,DequeueBufferDuration,QueueBufferDuration,
1,270900288236110,270901404902732,9223372036854775807,0,270901406732543,270901407052751,270901407062751,270901480932022,270901488003689,270901488511137,270901489180876,270901502575459,270901504554157,1520000,1026000,
1,270901416955482,270901500288812,9223372036854775807,0,270901507061241,270901507131709,270901507732074,270901524054574,270901524125251,270901524430720,270901524804834,270901531068480,270901534144522,3249000,1831000,
Firstly, why is there only two rows, if:
"Each line of this output represents a frame produced by the app"
If I wait and then rerun the command, I again only get 2 rows. Sometimes the values have updated, but other times they have not...
The documentation says that I can calculate frame time with:
(FRAME_COMPLETED - INTENDED_VSYNC)
So, I thought I could run the ADB command after say, 1 minute, get out a load of frame times and then graph it, but if I only get out 2 frames at a time... and if rerunning the ADB command does not update the data... how can I measure Frametimes? What am I missing here?
I am writing my bachelor thesis and using this adb command to get framerate. In my experience, the framerate data is updated only when the screen is changed. For example, you have a long list. If you don't scroll it, you only see limited framerate data, but if you scroll it, there will be more framerate data (but the maximum number of frames is 122 )
I've been using adb shell uiautomator dump and this works some of the time for some apps on my Pixel 2 device. When it decides to not work, I get this error message:
ERROR: could not get idle state.
I've read online that this is supposedly due to the UI not staying still while executing the dump, but even after letting apps idle for several minutes I still see that error. Even tried rebooting and rerooting the device. Is there a more reliable solution for this, preferably a native one?
You can try CulebraTester2.
It does not use uiautomator so you may not be affected by its limitation, which needs some idle time to be able to get the dump, and this doesn't happen when an animation is constantly being updated.
There are prebuilt APKs available at Github Actions (see Artifacts).
Install both APKs
Start server: ./culebratester2 start-server
Dump hierarchy: ./dump-window-hierarchy XML
The default format for the dump is JSON that's why you should specify XML in the command line if this is what you want.
I am spawning a couple of apps for my use case and I want to analyze the performance impact of doing so in order to decide between various approaches. I use the adb shell top -m 10 command to monitor the CPU usage constantly.
Is there a similar adb command to recursively display the live system memory usage by application while I perform different operations on my device ?
I'm new to developing for Android and have been tasked with helping the development of some React Native based Android application. I have a working setup in which an emulated Android device can run this application. However, when starting the emulator, the process adb.exe repeatedly gets spawned in the background at a rate of about 1 process per second. These processes seemingly take no/very little memory (144K according to the Task Manager), but over time, this still adds up to a massive list of processes (nearing 3000 at the time of writing) taking up quite a bit of memory (which is already scarce thanks to a fairly heavy development toolchain).
Closing the emulator does not automatically terminate these processes. The only way I have found so far that works is by using taskkill /IM /F.
Is this expected behaviour? If not, how could I begin with tracking down the reasons for behaviour.
If that happens again try to find in task manager, there will be numerous adb.exe processes popping-up most of them with same memory usage.Lookout for a process which uses different amount of memory once you identify it dont make any changes to that one instead stop processes that display same memory usage if you even kill one of those whole stack of them will come down to one adb.exe process. i've faced a similar issue and doing this has solved the problem. generally, it happens when you start to run emulator thats when you need to see the taskmanager.
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).
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.