Command Options Reference

The table below lists all options you can include on the Monkey command line.

Category

Option

Description

General

--help

Prints a simple usage guide.

-v

Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little information beyond startup notification, test completion, and final results. Level 1 provides more details about the test as it runs, such as individual events being sent to your activities. Level 2 provides more detailed setup information such as activities selected or not selected for testing.

Events

-s <seed>

Seed value for pseudo-random number generator. If you re-run the Monkey with the same seed value, it will generate the same sequence of events.

--throttle <milliseconds>

Inserts a fixed delay between events. You can use this option to slow down the Monkey. If not specified, there is no delay and the events are generated as rapidly as possible.

--pct-touch <percent>

Adjust percentage of touch events. (Touch events are a down-up event in a single place on the screen.)

--pct-motion <percent>

Adjust percentage of motion events. (Motion events consist of a down event somewhere on the screen, a series of pseudo-random movements, and an up event.)

trackball

<percent>

Adjust percentage of trackball events. (Trackball events consist of one or more random movements, sometimes followed by a click.)

--pct-nav <percent>

Adjust percentage of "basic" navigation events. (Navigation events consist of up/down/left/right, as input from a directional input device.)

--pct-majornav <percent>

Adjust percentage of "major" navigation events. (These are navigation events that will typically cause actions within your UI, such as the center button in a 5-way pad, the back key, or the menu key.)

--pct-syskeys <percent>

Adjust percentage of "system" key events. (These are keys that are generally reserved for use by the system, such as Home, Back, Start Call, End Call, or Volume controls.)

appswitch

<percent>

Adjust percentage of activity launches. At random intervals, the Monkey will issue a startActivity() call, as a way of maximizing coverage of all activities within your package.

--pct-anyevent <percent>

Adjust percentage of other types of events. This is a catch-all for all other types of events such as keypresses, other less-used buttons on the device, and so forth.

Constraints

-p <allowed-package-name>

If you specify one or more packages this way, the Monkey will only allow the system to visit activities within those packages. If your application requires access to activities in other packages (e.g. to select a contact) you'll need to specify those packages as well. If you don't specify any

packages, the Monkey will allow the system to launch activities in all packages. To specify multiple packages, use the -p option multiple times — one -p option per package.

-c <main-category>

If you specify one or more categories this way, the Monkey will only allow the system to visit activities that are listed with one of the specified categories. If you don't specify any categories, the Monkey will select activities listed with the category Intent.CATEGORY_LAUNCHER or Intent.CATEGORY_MONKEY. To specify multiple categories, use the -c option multiple times — one -c option per category.

Debugging

--dbg-no-events

When specified, the Monkey will perform the initial launch into a test activity, but will not generate any further events. For best results, combine with -v, one or more package constraints, and a non-zero throttle to keep the Monkey running for 30 seconds or more. This provides an environment in which you can monitor package transitions invoked by your application.

--hprof

If set, this option will generate profiling reports immediately before and after the Monkey event sequence. This will generate large (~5Mb) files in data/misc, so use with care. See Traceview for more information on trace files.

--ignore-crashes

Normally, the Monkey will stop when the application crashes or experiences any type of unhandled exception. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.

--ignore-timeouts

Normally, the Monkey will stop when the application experiences any type of timeout error such as a "Application Not Responding" dialog. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.

--ignore-security-exceptions

Normally, the Monkey will stop when the application experiences any type of permissions error, for example if it attempts to launch an activity that requires certain permissions. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.

process-after-error

Normally, when the Monkey stops due to an error, the application that failed will be left running. When this option is set, it will signal the system to stop the process in which the error occurred. Note, under a normal (successful) completion, the launched process(es) are not stopped, and the device is simply left in the last state after the final event.

--monitor-native-crashes

Watches for and reports crashes occurring in the Android system native code. If --kill-process-after-error is set, the system will stop.

--wait-dbg

Stops the Monkey from executing until a debugger is attached to it.

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. !_G°_to_top

Site Terms of Service - Privacy Policy - Brand Guidelines

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. !_G°_to_top

Site Terms of Service - Privacy Policy - Brand Guidelines

ciro^on

Traceview: A Graphical Log Viewer

Traceview is a graphical viewer for execution logs saved by your application. The sections below describe how to use the program.

Contents

Creating Trace Files Copying Trace Files to a Host Machine Viewing Trace Files in Traceview Timeline Panel

Profile Panel

Traceview File Format Data File Format

Key File Format

Traceview Known Issues Using dmtracedump

Creating Trace Files

To use Traceview, you need to generate log files containing the trace information you want to analyze. To do that, you include the Debug class in your code and call its methods to start and stop logging of trace information to disk. When your application quits, you can then use Traceview to examine the log files for useful run-time information such as method calls and run times.

To create the trace files, include the Debug class and call one of the startMethodTracing() methods. In the call, you specify a base name for the trace files that the system generates. To stop tracing, call stopMethodTracing(). These methods start and stop method tracing across the entire virtual machine. For example, you could call startMethodTracingO in your activity's onCreate() method, and call stopMethodTracing() in that activity's onDestroy() method.

// start tracing to "/sdcard/calc.trace" Debug.startMethodTracing("calc"); // ...

// stop tracing Debug.stopMethodTracing();

When your application calls startMethodTracing(), the system creates a file called <trace-base-name>.trace. This contains the binary method trace data and a mapping table with thread and method names.

The system then begins buffering the generated trace data, until your application calls stopMethodTracing(), at which time it writes the buffered data to the output file. If the system reaches the maximum buffer size before stopMethodTracing() is called, the system stops tracing and sends a notification to the console.

Interpreted code will run more slowly when profiling is enabled. Don't try to generate absolute timings from the profiler results (i.e. "function X takes 2.5 seconds to run"). The times are only useful in relation to other profile output, so you can see if changes have made the code faster or slower.

When using the Android emulator, you must create an SD card image upon which the trace files will be written. For example, from the /tools directory, you can create an SD card image and mount it when launching the emulator like so:

$ mksdcard 1024M ./imgcd $ emulator -sdcard ./img

For more information, read about the mksdcard tool.

The format of the trace files is described later in this document.

Copying Trace Files to a Host Machine

After your application has run and the system has created your trace files <trace-base-name>.trace on a device or emulator, you must copy those files to your development computer. You can use adb pull to copy the files. Here's an example that shows how to copy an example file, calc.trace, from the default location on the emulator to the /tmp directory on the emulator host machine:

adb pull /sdcard/calc.trace /tmp

Viewing Trace Files in Traceview

To run traceview and view the trace files, enter traceview <trace-base-name>. For example, to run Traceview on the example files copied in the previous section, you would use:

traceview /tmp/calc

Traceview loads the log files and displays their data in a window that has two panels:

• A timeline panel -- describes when each thread and method started and stopped

• A profile panel -- provides a summary of what happened inside a method

The sections below provide addition information about the traceview output panes.

Timeline Panel

The image below shows a close up of the timeline panel. Each thread's execution is shown in its own row, with time increasing to the right. Each method is shown in another color (colors are reused in a round-robin fashion starting with the methods that have the most inclusive time). The thin lines underneath the first row show the extent (entry to exit) of all the calls to the selected method. The method in this case is LoadListener.nativeFinished() and it was selected in the profile view.

Profile Panel

The image below shows the profile pane. The profile pane shows a summary of all the time spent in a method. The table shows both the inclusive and exclusive times (as well as the percentage of the total time). Exclusive time is the time spent in the method. Inclusive time is the time spent in the method plus the time spent in any called functions. We refer to calling methods as "parents" and called methods as "children." When a method is selected (by clicking on it), it expands to show the parents and children. Parents are shown with a purple background and children with a yellow background. The last column in the table shows the number of calls to this method plus the number of recursive calls. The last column shows the number of calls out of the total number of calls made to that method. In this view, we can see that there were 14 calls to LoadListener.nativeFinished(); looking at the timeline panel shows that one of those calls took an unusually long time.

Name

Incl %

Inclusive

Excl %

Exclusive

Calls+Rec

▼ 1 4 android/webkit/LoadListener.nativeFinished OV

66.6% 17734.382

53.2% 14161.

950

14 + 0

3 android/webkit/LoadlJstener.tearDown ()V

100.09617734.382

14/14

1 6 android/view/View.invalidate (llil)V

19.8%

3516.410

2413/2853

1 57 android/webkit/BrowserFrame.startLoadingResource (ILjava

0.3%

44.636

3/15

53 java/util/HashMap.put (Ljava/lang/Object;Ljava/lang/Objec

0.0%

6.223

6/326

1 20 android/webkit/JWebCoreJavaBridge.setSharedTimer (J)V

0.0%

2.593

2/730

378 android/view/ViewCroup.requestLayout OV

0.0%

1.139

2/54

1 315 java/util/HashMap.<init> (l)V

0.0%

0.879

3/41

629 android/webkit/BrowserFrame.loadCompleted OV

0.0%

0.285

1/1

1 598 android/webkit/WebView.didFirstLayout OV

0.0%

0.231

1/2

1 703 android/webkit/BrowserFrame.windowObjectCleared (l)V

0.0%

0.036

1/2

► 1 5 android/webkit/JWebCoreJavaBridgeSTimerHandler.handleMessa

16.3%

4342.697

0.5%

132.

018

730+0

► 1 6 android/view/View.invalidate (llll)V

15.6%

4161.341

1.2%

319.

164

2853+0

► 7 android/webkit/JWebCoreJavaBridge.accessS300 (Landroid/webl>

15.1%

4025.658

0.1%

26.

727

729+0

► 1 8 android/webkit/JWebCoreJavaBridge.sharedTimerFired OV

15.0%

3998.931

8.5%

2256.

801

729 + 0

► 1 9 android/view/View.invalidate (Landroid/graphics/Rect;)V

13.8%

3671.342

0.9%

246.

190

2853+0

► 10 android/view/ViewCroup.invalidateChild (Landroid/view/View:La

12.4%

3298.987

6.3%

1687.

629

876+1148

► 1 11 android/event/EventLoop.processPendingEvents OV

6.3%

1674.317

0.6%

151.

201

12 + 0

► 12 android/view/ViewRoot.handleMessage (Landroid/os/Message;)

4.6%

1217.210

0.0%

1.

992

35 + 0

► 1 13 android/view/ViewRoot.performTraversals OV

4.5%

1209.815

0.0%

7.

190

34 + 0

► 1 14 android/view/ViewRoot.draw (Z)V

4.1%

1096.832

0.0%

11.

508

34+0

► 1 15 android/policy/PhoneWindowSDecorView.drawTraversal (Landrc

3.9%

1040.408

0.0%

2.

218

34 + 0

► 1 16 android/widget/FrameLayout.drawTraversal (Landroid/graphics

3.8%

1023.779

0.0%

3.

129

34 + 48

► 1 17 android/vlew/View.drawTraversal (Landroid/graphics/Canvas;U

3.8%

1022.611

0.1%

19.

213

34+154

► 1 18 android/view/ViewGroup.dispatchDrawTraversal (Landroid/graf

3.8%

1000.413

0.2%

42.

609

34+130

► 19 android/view/ViewGroup.drawChild (Landrold/graphics/Canvas;

3.7%

983.346

0.2%

42.

926

34+150

► 1 20 android/webkit/JWebCoreJavaBridge.setSharedTimer (J)V

3.5%

929.506

0.2%

57.

241

730 + 0

► 1 21 android/webkit/WebView.nativeDrawRect (Landroid/graphics/Ci

3.5%

923.805

3.0%

807.

952

15 + 0

► 1 22 android/net/http/QueuedRequest.start (Landroid/net/http/Quei

3.2%

847.172

0.0%

3.

556

15 + 0

► 23 android/net/http/QueuedRequestSQREventHandler.endData OV

3.1%

828.592

0.0%

1.

619

15 + 0

► |24 android/net/http/QueuedRequest.setupRequest OV

3.1%

819.888

0.0%

5.

860

15 + 0

► 1 25 android/net/http/QueuedRequest.requestComplete OV

3.1%

816.585

0.0%

1.

506

15 + 0

► 26 android/webkit/CookieManager.getCookie (Landroid/content/Cc

2.7%

722.837

0.0%

8.

081

15 + 0

► 1 27 android/webkit/LoadListener.commitLoad OV

2.6%

688.168

0.1%

17.

708

58+0

► 28 android/webkit/Loadüstener.nativeAddData ([BI)V

2.3%

621.864

1.2%

306.

817

57+0

► 1 29 android/graphics/Rect.offset (ll)V

2.2%

573.985

2.2%

573.

985

17210+0

Find

Traceview File Format

Tracing creates two distinct pieces of output: a data file, which holds the trace data, and a key file, which provides a mapping from binary identifiers to thread and method names. The files are concatenated when tracing completes, into a single .trace file.

I Note: The previous version of Traceview did not concatenate these files for you. If you have old key and data files that you'd still like to trace, you can concatenate them yourself with cat mytrace.key mytrace.data > mytrace.trace.

Data File Format

The data file is binary, structured as follows (all values are stored in little-endian order):

* File format:

* header

* record 0

* record 1

* Header format:

* u4 magic 0x574f4c53 ('SLOW')

* u2 version

* u2 offset to data

* u8 start date/time in usec

* Record format:

* u1 thread ID

* u4 method ID | method action

* u4 time delta since start, in usec

The application is expected to parse all of the header fields, then seek to "offset to data" from the start of the file. From there it just reads 9-byte records until EOF is reached.

u8 start date/time in usee is the output from gettimeofday(). It's mainly there so that you can tell if the output was generated yesterday or three months ago.

method action sits in the two least-significant bits of the method word. The currently defined meanings are:

• 2 - method "exited" when unrolled by exception handling

An unsigned 32-bit integer can hold about 70 minutes of time in microseconds. Key File Format

The key file is a plain text file divided into three sections. Each section starts with a keyword that begins with '*'. If you see a '*' at the start of a line, you have found the start of a new section.

An example file might look like this:

clock=global ♦threads

1 main

6 JDWP Handler 5 Async GC 4 Reference Handler 3 Finalizer

2 Signal Handler ♦methods

0x080f23f8 java/io/PrintStream write ([BII)V 0x080f25d4 java/io/PrintStream print (Ljava/lang/String;)V 0x080f27f4 java/io/PrintStream println (Ljava/lang/String;)V 0x080da620 java/lang/RuntimeException <init> ()V [...]

0x080f630c android/os/Debug startMethodTracing ()V 0x080f6350 android/os/Debug startMethodTracing (Ljava/lang/String;Ljava/lang/String;I)V ♦end version section

The first line is the file version number, currently 1. The second line, clock=global, indicates that we use a common clock across all threads. A future version may use per-thread CPU time counters that are independent for every thread.

threads section

One line per thread. Each line consists of two parts: the thread ID, followed by a tab, followed by the thread name. There are few restrictions on what a valid thread name is, so include everything to the end of the line.

methods section

One line per method entry or exit. A line consists of four pieces, separated by tab marks: method-ID [TAB] elass-name [TAB] method-name [TAB] signature . Only the methods that were actually entered or exited are included in the list. Note that all three identifiers are required to uniquely identify a method.

Neither the threads nor methods sections are sorted.

Traceview Known Issues

Threads

Traceview logging does not handle threads well, resulting in these two problems:

1. If a thread exits during profiling, the thread name is not emitted;

2. The VM reuses thread IDs. If a thread stops and another starts, they may get the same ID.

Using dmtracedump

The Android SDK includes dmtracedump, a tool that gives you an alternate way of generating graphical call-stack diagrams from trace log files. The tool uses the Graphviz Dot utility to create the graphical output, so you need to install Graphviz before running dmtracedump.

The dmtracedump tool generates the call stack data as a tree diagram, with each call represented as a node. It shows call flow (from parent node to child nodes) using arrows. The diagram below shows an example of dmtracedump output.

[ iJ andrnkl/os/H ;iikI Icr.dispalct

13J aiKlroid/vicw7VicwRoo«.handlcMcssagc ( 145. 0.4)

12] i

1

r

]4] aridroid/view/ViewRooC.pertcxmTraversais ( 143, 0. 2)

u

¡7.0. 1) [I9J andn>id/view/ViewRtxi».dniw (71,0. 2)

16] an

onMcasurc (57.0. 1 )

[20J android/widgct/FramcLayoul.draw (67. 0. 1 )

[7] am

1

r

e (57.0, 1 ) [21] aiidroid/view/View.draw (67.0. 1 )

18] ai

For each node, dmtracedump shows <ref> callname (<inc-ms>, <exc-ms>,<numcalls>), where

• <ref> -- Call reference number, as used in trace logs

• <inc-ms> -- Inclusive elapsed time (milliseconds spent in method, including all child methods)

• <exc-ms> -- Exclusive elapsed time (milliseconds spent in method, not including any child methods)

• <numcalls> -- Number of calls The usage for dmtracedump is:

dmtracedump [-ho] [-s sortable] [-d trace-base-name] [-g outfile] <trace-base-name>

The tool then loads trace log data from <trace-base-name>.data and <trace-base-name>.key. The table below lists the options for dmtracedump.

Option

Description

-d <trace-base-name>

Diff with this trace name

g <outfile>

Generate output to <outfile>

-h

Turn on HTML output

-o

Dump the trace file instead of profiling

-d <trace-base-name>

URL base to the location of the sortable javascript file

t <percent>

Minimum threshold for including child nodes in the graph (child's inclusive time as a percentage of parent inclusive time). If this option is not used, the default threshold is 20%.

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License.

Site Terms of Service - Privacy Policy - Brand Guidelines

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License.

Site Terms of Service - Privacy Policy - Brand Guidelines

0 0

Responses

  • IGGI BISRAT
    How to use graphviz and dmtracedump to draw .trace file?
    7 years ago

Post a comment