Profiling Applications on Android Devices


To work with NVIDIA System Profiler, the target Android device should be configured for USB debugging in the Developer options settings menu. Please refer to Android development documentation to learn how to configure the device for USB debugging.

On the Windows host, a compatible USB driver should be installed. Please refer to device manufacturer's documentation to learn how to obtain and install the driver.

Connect your target device via a USB cable and power it on (or wake it up). Make sure that you have the adb command available (it is part of Android SDK Platform Tools package). NVIDIA System Profiler can only connect to devices that are marked as device in the output of the adb devices command. Make sure you can enter the ADB shell of the target device by running adb shell on the host.

Launch the NVIDIA System Profiler application. On the first launch, a new project called Project 1 is created automatically.

Project settings

When connecting to the target device, NVIDIA System Profiler will validate it and install its daemon into the following location on the device:

/data/local/tmp/com.nvidia.tegraprofiler.tools/

Once the daemon and all required files are installed correctly, a green check mark will appear and Device is ready text will be displayed:

Device is ready

System Profiling Options

System profiling options

Trace all processes — on compatible devices (with kernel module support version 1.107 or higher), enables trace of all processes and threads in the system. Scheduler events from all tasks will be recorded.

Collect PMU counters allows to choose which ARM PMU (Performance Monitoring Unit) counters NVIDIA System Profiler will sample. Enable specific counters when interested in correlating cache misses to functions in your application.

Target Sampling Options

Target sampling options

Currently NVIDIA System Profiler can only sample one process. Sampling here means that the profilee will be stopped periodically, and backtraces of active threads will be recorded.

Sampling rate defines how often the profilee will be interrupted in order to collect backtraces. This option has to be used carefully: perfect value depends on many factors.

Low sampling rate requires longer profiling session to produce statistically significant information. This is especially important when additional time-based filtering is then applied in the report view to analyze smaller periods of time.

High sampling rate, on the other hand, produces higher overhead. For some applications, it might hide performance issues related to waiting other work to complete, such as waiting to acquire mutex locks, waiting for GPU synchronization or waiting for network or disk-based IO to complete.

In some cases, forcing to use frame pointers as unwind algorithm is a viable option to reduce performance overhead. Unwind (backtracing) algorithms can be configured using the Choose modes... button.

Most applications use stripped libraries. In this case, many symbols may stay unresolved. If unstripped libraries exist, paths to them can be specified using the Symbol locations... button. Symbol resolution happens on host, and therefore does not affect performance of profiling on the target.

Additionally, debug versions of ELF files may be picked up from the target system. Refer to the corresponding section of the documentation.

This sections allows you to choose which application to profile. All information will be collected about the main process of the selected application, except when the Trace all processes checkbox is enabled.

For non-rooted Android devices, the list of applications only shows information about debuggable applications. By default, applications that are being developed using the Android SDK already contain the debuggable option in their manifests.

On rooted Android devices, profiling of all applications is allowed.

For convenience, the application list also shows the process identifiers (PID) of processes correlated to the listed packages. To refresh this information, use the button in the upper right corner of the list.

The two checkboxes below the application list are important to ensure that the correct launch or attach behavior is configured.

Allow sending intent to launch the default activity, when unselected, forces the profiler to attach to a running process. If no processes are found to correlate to the specified application name, the profiling session fails to start with an error message. When selected, NVIDIA System Profiler may launch the default intent of the selected application to make sure it is running and appears on top of the screen on the target device.

In some applications, especially in early stages of development, common bugs related to handling the lifecycle of activities can be found. In such cases, sending the default intent may lead to undesired behavior or even crashes of the profilee. Leaving the checkbox unselected ensures that the profiler does not affect the application.

Restart application if running is a convenient option in two cases:

  1. When profiling from the very beginning of the application is desired.

  2. When using some of the trace features described below. They require that a special library is injected into the application in runtime, which happens when the application is paused by the Android runtime's virtual machine just after starting. In this case, enabling this option helps ensure that the application is always restarted and the injection always happens, as opposed to potentially attaching to the application's process without injection.

Collect NVTX trace. See NVTX Trace for more information.

Collect OpenGL trace. See OpenGL Trace for more information.

 


 

NVIDIA® System Profiler Documentation Rev. 3.9.170817 ©2017. NVIDIA Corporation. All Rights Reserved.