How to debug Android * x86 applications and the tools to be used

 

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:

    • Vertical correlation: maps cross-layer system events to user-level activities, such as events, gestures, and frames.
    • Horizontal correlation: Associate runtime activities between entities of different systems (for example, a thread triggers garbage collection.
    • Visualization Based on pyTimeChart.

      To use UxTune's analytical response capabilities, developers need to be familiar with some important processes of the Android system (shown as rows in pyTimeChart), namely:

      1. InputReader row: This row displays all touch events in touch coordinates. The event is sent to InputDispatcher.
      2. InputDispatcher row: InputDispatcher packs consecutive touch events and sends them to uiThread of the application.
      3. UiThread row: This row displays the main touch events of the packets received from InputDispatcher. UiThread will plot (render) its surface based on specific operations. "D" indicates the drawing process.
      4. Surface line: uiThread locks the Surface at the beginning of the painting and unlocks the Surface after the painting is complete. "S" and "E" indicate the start and end of application rendering.
      5. SurfaceFlinger row: After rendering the application, the application will notify SurfaceFlinger to synthesize and update the screen. "S" indicates that SurfaceFlinger starts to process application requests, and "E" indicates that the merging is completed (the frame buffer swap is completed ).

         Figure 19. UxTune analysis window

         Meter-FPS is a tool used to measure the FPS value of the system. It captures the video processing path to obtain records for each frame. It also contains other standards, for example, maximum frame time, frame time change, # long frame and drop frame rate. The fps monitor has two modes. Real Time Pattern (Real-Time mode) displays the fps of all running applications in Real Time. Measure Pattern (Measurement Mode) allows you to Measure fps and other parameters at user-defined start and stop times. To use this tool, you must obtain the highest permission for the device.
Set the environment:
Setprop debug. graphic_log 1
Stop zygote
Start zygote

         Figure 20 shows the configuration page in which developers can configure the tool for debugging targets.

         20. Meter-FPS Configuration

         In Real Time mode, click the monitor button. The fps tool monitors all running applications and updates fps in floating windows on the screen.

         Figure 21. Meter-FPS real-time mode

         In Measurement Mode, click the monitor button. A floating window is displayed, where "Click to start (Click to start)..." is displayed; Click the floating window to start monitoring.

         Figure 22. Meter-FPS real-time mode 1

         The current measurement mode is running:

         Figure 23. Meter-FPS real-time mode 1

         Click the floating window to stop monitoring. The result is displayed:

         Figure 24. Meter-FPS analysis result list

         Click each item in the list above to obtain detailed records:

         Figure 25. Detailed Meter-FPS analysis record

         Refer:

         Http://developer.android.com/guide/developing/debugging/index.html
         Http://www.eclipse.org/sequoyah/documentation/native_debug.php
         Http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/
         Http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-debugging/
         Http://packages.python.org/pytimechart/userguide.html
         Https://perf.wiki.kernel.org/index.php/Main_Page

         Related Articles and resources:
         • Android-Intel Developer Zone
         • Android INDE
         • How to use intel XDK to create an application
         • Using HAXM to accelerate the Android simulator on Intel architecture

           Xiaodong Wang is an Application Engineer in Intel's Software and Services Division. He focuses on ISVs on Intel-based platforms using Android operating systems. The PRC Plus project (ISV enabled for Android tablet) That Xiaodong provides technical support has successfully enabled the first 50 NDK applications as technical interfaces. Xiaodong recently participated in several intel innovation projects and played an important role in the development process. In particular, one of the projects was selected as the demonstration project of the Intel Information Technology Summit, and Xiaodong successfully provided technical support. Before joining intel, Xiaodong worked on framework and application development in MediaTek. Xiaodong is a master's degree from Peking University. During his studies at Nanyang University in Singapore as an access scholar, he published a technical paper in the IEEE Computer journal. He is interested in mobile Internet technologies (such as LBS and nfc ar) and innovative designs.

            

           Statement

            

           This document contains information about Intel products. This document does not constitute authorization for any intellectual property rights, including express, implied, or based on the Anti-statement principle or others. Intel is not liable for any other responsibilities. Intel hereby disclaims: this document does not constitute any express or implied warranty of Intel regarding the use and/or sale of its products, including) any liability or warranty for the applicability of a specific purpose, the (ii) merchantability and (iii) Infringement of any patent, copyright or other intellectual property rights.

           Intel products are intended for or used for the following applications without the prior written consent of Intel: In such applications, personal injury or death may be caused by faults of Intel products.

           Intel has the right to change the product specifications and descriptions at any time without notice. The designer shall not trust any feature that is not available to any unique product, nor shall the designer trust any feature marked with a reserved license or undefined license or feature description. In this regard, Intel reserves the right to define it in the future. At the same time, Intel shall not assume any responsibility for conflicts and incompatibility arising from its subsequent changes to such descriptions or feature descriptions. The information provided here can be changed at any time without notice. Do not design a product based on the information provided in this document.

           The products described in this document may contain design defects or errors that make them inconsistent with the declared specifications. These defects or errors are included in the error table and can be obtained upon request.

           Before placing an order, contact your local intel business department or distributor to obtain the latest product specifications.

           To obtain a copy of the document with serial numbers or other intel literature involved in this article, call 1-800-548-4725, or visit: http://www.intel.com/design/literature.htm
           The software and workload used in performance testing may only be available at Intel®Performance is optimized on the microprocessor. Tests such as SYSmark and MobileMark are based on specific computer systems, hardware, software, operating systems and functions. Changes to any of the above elements may lead to changes in the test results. Refer to other information and performance tests (including running performance when used in conjunction with other products) to fully evaluate the target product.
           The provision of software source code contained in this document is based on the relevant software license and any use and reproduction of such source code shall be subject to the terms of the relevant software license. The Intel and Intel logos are trademarks of Intel in the United States and/or other countries.
           Intel©Copyright: 2012. Retain ownership.
           * Other names and brands may be assets of other owners.