I started my emulator with ./emulator -trace profile -avd emulator_15. I then tracked down the trace files to ~/.android/avd/rodgers_emulator_15.avd/traces/profile, where there are six files: qtrace.bb, qtrace.exc, qtrace.insn, qtrace.method, qtrace.pid, qtrace.static. I can't figure out what to do with these files. I've tried both dmtracedump and traceview on all of the files, but none seem to generate any output I can do anything with.
How can I view the proportion of time taken by native method calls on Android?
You need to use tracedmdump to convert the output. This is a shell function defined in build/envsetup.sh in the full Android sources. If you're using the SDK, rather than building from a full tree, I'm not sure this will work.
(If you don't have the sources and want to take a peek at the tracedmdump function, you can see it here.)
If you used emulator -trace profile, you'd run tracedmdump profile. This will dig through various binaries to retrieve symbolic information and associate it with the trace data, generating an HTML summary and a traceview-compatible trace file.
It's worth noting that the VM will execute more slowly with profiling enabled (the interpreter has overhead on every method call and return, and it's running in the slower "debug" interpreter), while native code continues to run at full speed, so you have to be careful when drawing conclusions.
General comment: don't forget to use F9 or one of the method calls to start/stop the tracing -- the -trace flag just enables the feature.
In order to use those six files, there are other scripts in the same directory as that of dmtracedump such as read_pid, read_trace, profile_trace etc. U should first run post_trace on the trace directory containing the six files, then you can use any one of them to get profile info such as how often each basic block executes, the pids they belong to etc.
Related
I have some problem running Robot Framework test suite with appium and pabot.
I'm running some tests suite on multiple android devices like this:
pabot --pabotlib --argumentfile1 phone1.dat --argumentfile2 phone2.dat -v LANG:fr --outputdir output --output basics.xml JustBasics_tests.robot
pabot --pabotlib --argumentfile1 phone1.dat --argumentfile2 phone2.dat -v LANG:fr --outputdir output --output another.xml LetsRunAnother_test.robot
I don't execute all suites in a single pabot instruction because I got some appium errors if I do like this ... errors like: WebDriverException: Message: A session is either terminated or not started pabot or WebDriverException: Message: A new session could not be created. Details: Problem getting session data for driver type AndroidDriver; does it implement 'get driverData'?
I want to make a report from another.xml and basics.xml to something like log.html and report.html (to work with Jenkins after).
My first problem is that basics.xml and another.xml files contain only one test execution from one of the two devices. If I want data from both devices of a test case execution I need to take the output.xml file which contains both test case execution... Of course output.xml is overwritten after each pabot command.
So I thought to just copy each output.xml and rename to outputX.xml and finally make a
rebot output1.xml output2.xml output3.xml ....
But rebot doesn't work like I expected : rebot just copying X times the first mobile test on the report so I have something like on my log.html:
JustBasics
Test_Results_for_phone1
Test_Results_for_phone1
LetsRunAnother
Test_Results_for_phone1
Test_Results_for_phone1
What am I doing wrong?
My second problem is that there are no screenshots in my log files, when something fails in test execution (error or crash of app for exemple). They all point to root directory from the log.html but images are in a path like pabots_results/X/TestSuiteName/appium-screenshoot-x.png
Here again what is wrong? Do I have to do something about images, or pabot should do it alone (in pabot.py nearly then end of file, there is a function named _copy_screenshots ....)
The disturbing thing about this story is that there are not plenty of documentation about pabot. And I don't know if I'm doing something wrong or if pabot has some bugs!
So thanks for reading me, and see you ;)!
UPDATE : To avoid all these problems, I wrote this little tool : https://github.com/bastienjalbert/aptr
For your screenshots issue, I'm assuming you're using Jenkins' Robot Framework plugin. What happens here is, that on post-execution of your tests, the plugin will move your output, report and log to the current build's workspace, to display it in the build's dashboard. The screenshots on the other hand, are by default, not moved.
In your job configuration, under post-build actions, you should have publish Robot Framework test results. Click the advanced button, to see all options, and you should have a field labeled as other files to copy
In this field you add the path that matches your selenium screenshots (probably just *.png)
Now, after your test execution, the plugin should move your screenshots in the same location as your log.html and they will be able to display in the log.
You can actually find this, and more information that may be relevant to you, in the plugin's page
I think you will want to use
rebot --merge output1.xml output2.xml output3.xml ....
From
rebot --help
(...)
Options
=======
-R --merge When combining results, merge outputs together
instead of putting them under a new top level suite.
Example: rebot --merge orig.xml rerun.xml
(...)
I'm compiling in debug mode a certain .so in the Android-Native layer which by default outputs to the default logging file.
However, I do not want this data to be saved to the logs in the first place because it will overwhelm the logging file; I plan on streaming it off of the device.
POSSIBLE SOLUTIONS
Modify the .so code to output the debug info to NOT the logging file.
Definitely the most straightforward way but I'd prefer not to do this since this'll require modification of the .so. I agree this should be trivial modification but I have a requirement to modify the .so as little as possible.
Is there a way to create an alias for a file, pipe all writes to it through my app (like tee) and selectively allow writes to the real file?
Is there a built-in logcat filtering tool that can do this filtering for me with some regexs?
First of all, the first solution is indeed the trivial and the better one - since it remains in the code unlike the logcat filtering that might get deleted.
If the requirement is to modify the .so as little as possible, there is no real problem - you modify the code using #ifdef for debug only, so the code changes for debug mode, but the generated .so for release does not change. This will give you a very good control - but in case you have a lot of 'special' debug code, it will make your code a little ugly...
Edit:
If you want to write to you own log, you can run logcat using Runtime class, with your own parameters - look here: Using GREP command to filter logcat in Android.
Regarding the logcat filtering - you can use regex in the filtering in Android Studio. You have a 'regex' check box next to the input box. See here for more details: How to exclude certain messages by TAG name using Android adb logcat?
The documentation in android says
you can use the methods of the Trace class to add instrumentation to
your application code and see the results in a Systrace report.
I have added the below methods to my code
Trace.beginSection("test-trace");
// block of code
Trace.endSection();
Now where can I check the results of this section. I start the systrace tool from the android device monitor and recorded it for 30 secs(performed the button click that executes the above the block). It generates the trace.html file but how do i get the above section information from this html file
It is there, I myself searched for it about one hour :D
If you have only one thread, it's shown in UI thread row, otherwise it's shown in your-defined thread row.
If you can not find it, use the search toolbox, in top right corner of page, type 'test-trace' there and it will show you the start time of that in detail
:)
this screenshot may help you
The systrace output only includes the tags that are listed on the command line. For app-specific tracing, that means adding a --app=package-name argument. This is necessary because systrace logs the entire system, and you wouldn't want it to automatically pick up the traces for every app and component.
You can find an example here. For a program with package name com.faddensoft.multicoretest, you would use a command line like:
python systrace.py --app=com.faddensoft.multicoretest gfx view sched dalvik
With that, your tracing should appear in the row of the thread that's issuing the trace calls. (Open the HTML file in a web browser; might need to use Chrome.)
Probably you recorded too long, make sure to increase buffer size with -b command, or simply follow this example:
python systrace.py -app=package_name sched freq idle am wm gfx view dalvik input binder_driver -t 30 -o test.html -b 30384
I would like to understand what is rlimit and pipe limit for an executable?
I am debugging an issue where dynamically built executables are crashing while loaded but statically built executables are fine.
WHen a dynamically built executable is loaded,
I see the following prints after the register dump
Process 2748(ls) has RLIMIT_CORE set to 1
Aborting Core
First of all some one please explain what is rlimit with perspective to exec. Also is there some thing called pipe limit? I see this proc entry.
Please point me to some resource that explains these attributes of an executable.
Question 2 :
When an executable is loaded, what exactly exec does? linker will load the shared libraries that are needed by my executable. So for this to happen linker(a binary inside /system/bin) should execute first.
Hence I understand that linker(system/bin/linker) and executable(ls) both are loaded by exec. Is my understanding correct? This is all theory. If someone, probably who is good at both fs and proc management, could point me to the relevant source, it would be great help. Thank you.
The RLIMIT_CORE is used to place a limit on the amount of info that coredump is allowed to produce, before it is aborted. Once this limit is hit, no more info is logged and the message Aborting Core is logged to the console.
From the man page of core :
A process can set its soft RLIMIT_CORE resource limit to place an upper limit on the size of the core dump file that will be produced if it receives a "core dump" signal.
Use setrlimit() to configure RLIMIT_CORE to a larger value to obtain complete coredumps.
The most common format of executables/shared-objects is ELF. On Linux, the dynamic loading and linking of these shared-objects is performed by ld.so
ld.so is loaded in the address space of a newly created process (by exec in this case) and executed first. This is possible as its path is embedded into the .interp section of the executable binary during compilation.
The dynamic linker then
loads the initial executable image
loads the dependent shared-objects(*.so files)
jumps to the entry-point of the executable
Reference : Dynamic linker on ELF-based Unix-like systems
How can I get the trace of dalvik bytecode that is being executed while the device is running an app (like logcat does)?
There is no existing tool to do what you want, but it might be possible to implement such a tool without too much work.
The general idea is that you want to connect to dalvik's vm as a debugger, using the jdwp protocol, and single step the virtual machine, inspecting the state between each step and printing out the instruction. You should be able to get the... instruction index. Or maybe the instruction offset, via JDWP.
Additionally, you will need to read the dex file, and look up the exact instruction being executed, based on the instruction index/offset you get from JDWP.
You should be able to use AndBug to implement the first part of the above solution, and then use dexlib to access the dex file, in order to get the instruction.
You might want to check out traceview
It is realy too slow to trace the method not to speak the byte code,when you want to know what the app is doing the best way is to trace method first,then trace the byte code in it.