1. Introduction
As we all know, Android * developers are often referred to as designers, programmers, and so on, and often referred to as fault repair engineers. Errors in the Code cannot be avoided. Therefore, whether or not you cause errors at the beginning or not, it is important to understand debugging tools and how to quickly and effectively track and resolve errors. Now, Android Developers must master effective debugging skills. This article provides a simple tutorial on debugging tools for Android apps. It is used to help beginners of Android SDK and related tools quickly get started and solve faults more effectively on the Android x86 platform.
2. SDK application debugging tool
The Android SDK provides most of the tools required to test applications. If you want to perform operations such as one-step debugging code, viewing variable values, and suspending the application, you need to be compatible with JDWP debugging programs. If Eclipse is used, the JDWP-compatible debugging program is included, and you do not need to set it. If you are using another IDE, you can use the debugging program that comes with it and connect the debugging program to a special port so that it can communicate with the application Virtual Machine on your device.
If you use the ADT (Android Development Tool) Plug-in for development in Eclipse, you can use the built-in Java * debugging program and use the DDMS (Dalvik debugging monitoring program server) to debug the application. To facilitate access to debugging programs and DDMS, Eclipse displays debugging programs and DDMS functions in the form of views. These are custom Eclipse views that display specific tabs and Windows based on your view. Eclipse can also start the ADB (Android Debug Bridge) host daemon for you without running the tool manually. If you use other ides for debugging, you can use all the debugging tools provided by the Android SDK, such as ADB, DDMS, and Java debugging programs.
Figure 1 Dalvik debugging monitoring program server
With DDMS, developers can view the heap usage of processes, track the memory allocation of objects, use the File System of simulators or devices, check thread information, obtain method configurations, and use network traffic tools (in Android provided in 4.0) use LogCat to track code information and simulate mobile phone operations and locations. For more information, see http://developer.android.com/guide/developing/debugging/ddms.html. The Android SDK also provides Hierarchy Viewer and layoutopt to help developers debug layout problems.
The Hierarchy Viewer application allows you to debug and optimize your user interface (UI ). It visually presents the View level (View Hierarchy port) of the layout and provides a magnified display View (Pixel Perfect window ).
Figure 2. Hierarchy Viewer)
The View Hierarchy window displays the View object that forms the UI of the activity running on your device or simulator. You can use it to view each view object in the context of the entire view tree. For each View object, the View Hierarchy window also displays rendering performance data. When selecting a node, the extra information of the View appears in the small window above the node. When you click a node, You can see information about the image, view count, and rendering time.
Figure 3. View Object Information Window
Pixel Perfect is a tool used to check Pixel properties and deploy the user interface through the design diagram. The Pixel Perfect window displays enlarged images of the screen visible on the simulator or device. In this window, you can check the properties of each pixel in the screen image. You can also use the Pixel Perfect window to deploy the application's user interface based on the bitmap design.
Figure 4. Pixel Perfect window
The layoutopt tool allows you to analyze an XML file that defines the user interface of the application to find out improper points at the view level. To run the tool, open the terminal and start layoutopt from the SDK tool/directory. . Variables are a list of resources to be analyzed separated by spaces. They can be uncompiled resource xml files or directories of these files. The tool loads specified XML files and analyzes their definitions and levels based on a set of predefined rules. The following is an output example from the tool:
$ layoutopt samples/ samples/compound.xml 7:23 The root-level <framelayout> can be replaced with 11:21 This LinearLayout layout or its FrameLayout parent is useless samples/simple.xml 7:7 The root-level <framelayout> can be replaced with samples/too_deep.xml -1:-1 This layout has too many nested layouts: 13 levels, it should have <= 10! 20:81 This LinearLayout layout or its LinearLayout parent is useless 24:79 This LinearLayout layout or its LinearLayout parent is useless 28:77 This LinearLayout layout or its LinearLayout parent is useless 32:75 This LinearLayout layout or its LinearLayout parent is useless 36:73 This LinearLayout layout or its LinearLayout parent is useless 40:71 This LinearLayout layout or its LinearLayout parent is useless 44:69 This LinearLayout layout or its LinearLayout parent is useless 48:67 This LinearLayout layout or its LinearLayout parent is useless 52:65 This LinearLayout layout or its LinearLayout parent is useless 56:63 This LinearLayout layout or its LinearLayout parent is useless samples/too_many.xml 7:413 The root-level <framelayout> can be replaced with -1:-1 This layout has too many views: 81 views, it should have <= 80! samples/useless.xml 7:19 The root-level <framelayout> can be replaced with 11:17 This LinearLayout layout or its FrameLayout parent is useless </framelayout> </framelayout> </framelayout> </framelayout>
Traceview is a graphical viewer of execution logs. These logs are created when you use the debugging class to record tracing information in the code. Traceview helps you debug applications and outline their performance. Traceview can load a log file and display its data in the window, which is shown in Figure 5 and figure 6 to visualize your application on two panels:
Figure 5. Timeline panel describes when each thread and method starts and stops
Figure 6. The Profile Panel provides a summary of all the time spent in the method.
Dmtracedump is a tool that provides you with an alternative method to generate a graphical call stack diagram from the trace log file. This tool uses Graphviz Dot utility to create graphical output. Therefore, you need to install Graphviz before running dmtracedump. The dmtracedump tool generates call stack data in the form of a tree chart. Each call is represented as a node. It uses arrows to display the call process (from the parent node to the child node ). Figure 7 shows an example of dmtracedump output.
Figure 7. dmtracedump
3. NDK application debugging tool
Because Android NDK is based on the GCC tool chain, Android NDK contains GDB and GNU debugging programs, allowing you to start, pause, check, and modify programs. On Android devices, GDB is configured in Client/Server mode, which is more common on embedded devices. Programs run on devices as servers and remote clients. The developer's workstation is connected to it and sends Debugging commands similar to local applications. GDB is a command line utility, which is cumbersome to use manually. Fortunately, GDB can be processed by most ides, especially CDT. Therefore, you can directly use Eclipse to add a breakpoint and check the program, provided that it is correctly configured first!
By clicking the left side of the text editor, Eclipse can easily insert breakpoints using Java and C/C ++ source files. Java breakpoint can be used immediately with the ADT plug-in, which manages debugging through Android Debug Bridge. But this is not true for CDT. CDT cannot perceive Android. Therefore, inserting breakpoints will not work unless we configure CDT to use GDB of NDK, GDB itself needs to be bound to a native application for debugging. The support for debugging programs has been improved in the NDK version (for example, native threads cannot be debugged before ). Although NDK is more and more suitable, NDK R5 (and even R7) is still not perfect. However, it is still useful! Now let's take a look at how to debug native applications.
First, use the following steps to enable the debug mode in our application:
1) One step is very important, but it is easy to ignore, that is, activating the debugging tag in the Android project. This operation is completed in the AndroidManifest. xml application list. Do not forget to use the applicable SDK version for native code:
...
2) enabling the debug flag in the list will automatically activate the debug mode with native code. However, the APP_OPTIM tag also controls the debugging mode. If you have set it manually in Android. mk, check whether it has been set for debugging (not publishing) or directly delete it:
APP_OPTIM := debug
3) Now let's configure to connect to the GDB client of the device. Recompile the project and insert the device or start the simulator. Run and exit the application. Ensure that the application is loaded and Its PID is available. You can monitor the process by using the following command (Cygwin in Windows:
$ adb shell ps |grep gl2jni
A row should be returned:
app_75 13178 1378 201108 68672 ffffffff 80118883 S com.android.gl2jni
4) Open the terminal window and go to the project directory. Run the ndk-gdb command (located in the Android NDK folder, such as the android-ndk-r8 ):
$ ndk-gdb
This command does not return messages, but will return messages in the objlocal? Create three files in the directory (for the arm Device directory objlocalarmeabi ):
- Gdb. setup: This is the configuration file generated for the GDB client.
- App_process: this file is retrieved directly from your device. It is a system executable file, started at system startup, and can form a branch to start a new application. GBD needs this reference file to find its mark. In some ways, it is the binary input point of your application.
- Libc. so: This file can also be retrieved directly from your device. It is the Android standard C library (usually called bionic) used by GDB to keep track of all native threads created during runtime.
5) in your project directory, copy objlocal? Gdb. setup and name it gdb2.setup. Open it and delete the following lines that request the GDB client to connect to the GDB server running on the device (which will be executed by Eclipse ):
target remote :5039
6
)In the Eclipse Main Menu, go to "Run (Run) | Debug Configurations (Debug configuration )... and create a debugging configuration in the C/C ++ application project named GL2JNIActivityDefault. This configuration will start the GDB client on your computer and connect to the GDB server running on the device.
7
)On the Main (Main menu) tab, use the Browse button to set the project as your project directory, set the C/C ++ application to point to objlocal x86app_process (absolute or relative paths can be used ).
Figure 8. debugging configuration for C/C ++ applications
8
)Use the "Select other (Select other)..." link at the bottom of the window to switch the Startup Program type to "Standard Create Process Launcher (Standard Process Startup Program )":
Figure 9. Select the preferred Startup Program
9
)Go to the debug program file and set the debug program type to gdbserver, and set the GDB debug program to android-ndk-r8 oolchains? -4.4.3prebuiltwindowsini686-android-linux-gdb.exe or set the GDB command file requirement for the arm platform as a android-ndk-r8 oolchainsarm-linux-androideabi-4.4.3prebuiltlinux-x86inarm-linux-androideabi-gdb for the arm platform to point to the objlocal? Or the gdb2.setup file in objlocalarmeabi (both absolute and relative paths can be used ).
Figure 10. debug program settings panel
10
)Go to the Connection tab and set the type to TCP. The default values are retained for the host name, IP address, and port number (localhost d 5039.
Figure 11. Link settings on the debug program settings panel
11
)Now let's configure Eclipse to run the GDB server on the device. Copy the android-ndk-r8 dk-gdb and open it in a text editor. Find the following lines:
$GDBCLIENT -x `native_path $GDBSETUP`
Since the GDB client will be run by Eclipse itself, comment on it:
#$GDBCLIENT -x `native_path $GDBSETUP`
12
)In the Eclipse Main Menu, go to "Run (Run) | External Tools (External Tools) | External Tools deployments (External Tools)
Configuration)... ", and create a new configuration GL2JNIActivity_GDB.
This configuration starts the GDB server on the device.
13
)On the Main (Main menu) tab, set the location to point to the ndk-gdb we modified in the android-ndk-r8. Set the working directory to your application directory location
You can also set the Arguments text box:
Verbose: View in detail what happened in the Eclipse console.
Force: automatically terminates all previous sessions.
Start: Let the GDB Server start the application, instead of connecting to the application after the application starts. This option is useful when you only debug native code, not Java code.
Figure 12. External tool Configuration
14
)Now, start the application as usual.
15
)Once the application starts, you can directly start ndk-gdb on the console or start an external tool to configure GL2JNIActivity_GDB. This configuration will start the GDB server on the device. The GDB server receives Debugging commands sent by the remote GDB client and debugs your applications locally.
16
)Open jnigl_code.cpp and set the breakpoint in setupGraphics by double-clicking the left side of the Text Editor (or right-clicking and selecting Toggle breakpoint )).
Figure 13. breakpoint settings
17
)Finally, start GL2JNIActivity. The default C/C ++ application is configured to start the GDB client. It will relay the debugging command from Eclipse CDT to the GDB server through a socket connection. From the developer's point of view, this is very similar to debugging local applications.
There are also some dedicated tools for debugging graphics performance, such as Intel®GPA System Analyzer is intel®Graphic Performance Analyzer (intel®(GPA), adding support for intel-based Android devices, and providing dedicated applications and driver engineers to optimize their OpenGL * ES workload.
This section provides information about how to configure intel GPA and use it on your Android device through a USB connection. When connected to an Android device, Intel GPA System Analyzer provides OpenGL es api, CPU, and GPU performance standards and helps analyze the performance of OpenGL ES applications by providing State rewriting of multiple graphics pipelines.
To use intel GPA System Analyzer on Android x86 devices, check the target machine and firmware/version from the documentation.
To start collecting standards, you need to install intel GPA System Analyzer on the client System and connect it to the target device:
1
)Install intel GPA 2012 R3 on a Windows */Linux * client.
2
)Start intel GPA System Analyzer.
3
)Make sure that the Android device is connected to the client through a USB cable.
4
)The client system can wait up to 10 seconds to detect the target device. The detected devices are displayed in the dialog box. The target device list is refreshed every 5 to 6 seconds.
5
)Find the device you want to Connect to and click Connect )". Intel GPA System Analyzer copies required components to the target device and generates a list of installed applications. You can click Stop to Stop the connection process.
Figure 14. Select connected devices
6
)Select the desired application from the list of available applications. The "Application List" screen displays all users and all system applications installed on Android devices.
Figure 15. Application List
7
)The application is started and you will see its data in the Intel GPA System Analyzer window.
8
)To switch to different applications, click Back )". Note that the running application will be forcibly disabled.
9
)To switch to different targets, click Back )".
The PowerVR graphics architecture consists of the following core modules that convert submitted 3D application data into rendered graphics: Tile Accelerator (TA), Image Synthesis Processor (ISP) and Texture & Shading Processor (TSP ). The intel GPA standard in the GPU group corresponds to one of these core modules. The standard order in the Metrics List depends on the order of the core modules in the graphic pipeline.
Figure 16. Intel GPA System Analyzer window
Perf is a useful tool in Linux from Linux 2.6.30 and can be used for performance analysis related to hardware and software at the same time. Although Android is built on Linux, it does not contain perf, just like other Linux components and libraries. You must push the static build perf to it. If you already have this tool, you only need to place it under/system/bin/to make it effective. For a brief description, basic usage, and tutorial on perf, visit https://perf.wiki.kernel.org/index.php/main_page.
With traceview, developers can obtain Java code performance information. With perf, developers can obtain performance information about native and system-level code, as shown in 17.
Figure 17. Performance Statistics
Figure 18. function call stack
UxTune is a engineering tool used for Android user interaction analysis and optimization. It is an enhanced pyTimeChart tool.
UxTune design features include: