Remote debugging of applications on the Android * Operating System

 

Android * remote debugging of Operating System Applications

Android * Debug Bridge

Android Debug Bridge (ADB) is a command line tool that can process debugging programs (usually GDB * or DDMS * (Dalvik * debugging monitoring program server) and ADT) on the host) debugging communication with the Android * image running on the target. The target image can run On a simulated device or a physical development device that communicates with it through a USB-OTG (On-The-Go) or a USB to Ethernet adapter. In short, ADB is a bridge that makes debugging apps on Android * possible.

The device you connect to or simulate involves many shape factors. The device may be a smartphone or tablet. It can also be a medical tablet or an embedded device for industrial, Home Energy Management, warehousing, or any number of SMART system applications.

Set Android Debug Bridge to enable intel-based®The remote debugging of the lingdong TM processor platform is not much different from that of other architectures.

First, install the Android * SDK containing ADB * on the Development host. For more information, see http://developer.android.com/sdk/installing.html.

Set ADB *

If the target image runs on a physical device, you first need to support USB-OTG or USB to Ethernet. To support USB to Ethernet, you need to re-build the Kernel configuration. If necessary, your original device manufacturer will provide you with the necessary information.

The standard way to debug remote applications is to use existing USB-OTG interfaces for most Android devices. This setting is described on the Android * developer website at http://developer.android.com/guide/developing/device.html.

Here are the main steps

1. Declare your application as "debuggable" in Android Manifest ".

Skip this step when using Eclipse, because debugging is automatically enabled when running an application directly from Eclipse IDE.

InAndroidManifest.xml In the fileandroid:debuggable=true Add Element.

NOTE: If debugging is manually enabled in the inventory file, you must disable it before building for release (the application you publish should generally not be debugged ).

2. Enable "USB debugging" on the device ".

On the device, go to "Settings> Application> development" and enable "USB debugging" (on the Android 4.0 device, set the path to "Settings> developer options ").

3. Set the system to detect the device.

O if it is developed on Windows, you need to install the adb USB driver. For links to the installation guide and original device manufacturer Drivers, see the oem usb Drivers documentation.

O if it is developed on Mac OS X, no operation is required. Skip this step.

O if it is developed on Ubuntu * Linux *, you need to addudevRule file, which contains the USB configurations for each device to be developed. In the rule file, each device manufacturer is represented by a unique supplier ID.ATTR{idVendor}Attribute. To view the list of Vendor IDs, see USB Vendor IDs. To configure Device Detection in Ubuntu Linux:

Log On As a Super User and create the file:/etc/udev/rules.d/51-android.rules.

Add a vendor to a file in the following format:
SUBSYSTEM==usb, ATTR{idVendor}== , MODE=0666, GROUP=plugdev

Note: The Rule syntax may vary slightly depending on your environment. You can refer toudevDocumentation. For an overview of the Rule syntax, see the Guide to udev rules.

Run the following command:
chmod a+r /etc/udev/rules.d/51-android.rules

During USB insertionSDK platform-tools/ Directory executionadb devicesVerify that the device is connected. If the device is connected, the device name is listed as "device.

For Android operating systems booted on CDK, connect A USB-OTG cable to the (USB micro B) port on the CDK and Connect the other end of the cable (USB A) to the development host.

If everything works, you can run the following command to see the connected device:

$ adb devices

* daemon not running. starting it now *

* daemon started successfully *

List of devices attached

0123456789ABCDEF device

Note: to know which device name is assigned to the connection on the Linux development host, you can view dmesg to find "usb-storage: device found And then go to the "ls-l/dev/bus/usb/*" list to find the number.

 

ADB on Windows *

Download and install Eclipse Classic from http://www.eclipse.org/downloads/

Download the Android * SDK package for Windows * from the http://developer.android.com/sdk/index.html. (Android-sdk_r18-windows.zip or installer_r18-windows.exe ).

After the Android * SDK is installed, adb.exe will Android-sdkplatform-tools

 

ADB host-Client Communication

So far, we are concerned about installing ADB on the Development host. In reality, it is a client-server program with three components:

A client runs on the Development host. You can call the client from the shell by executing the adb command. Other Android tools such as ADT plug-in and DDMS can also create adb clients.

A server runs on the Development host as a background process. The server manages the communication between the client and the adb daemon on the simulator or device.

A daemon runs as a background process on each simulator or device instance.

When you start the adb client, the client first checks whether the adb server process is running. If no, the server process is started. When the server starts, it is bound to the local TCP port 5037 and listens for commands sent from the adb client. All adb clients use port 5037 to communicate with the adb server.

The server then establishes a connection with all running Simulators/device instances. It scans ports ranging from 5555 to 5585 (the range used by the simulator/device) to find the simulator/device instance. Locate the adb daemon and establish a connection with the port. Note that each simulator/device instance obtains a pair of serial ports-an even number port is used for console connection, and an odd number port is used for adb connection. For example:

Emulator 1, console: 5554

Emulator 1, adb: 5555

Emulator 2, console: 5556

Emulator 2, adb: 5557 ...

As shown in the example, the simulator instance connected to adb on port 5555 is the same as the instance listening to port 5554 on the console.

Once the server establishes a connection with all simulator instances, you can use the adb command to control and access those instances. Because the server manages connections to simulators/device instances and processes commands from multiple adb clients, you can control any Simulators/device instances through any client (or script.

 

Start ADB

Type adb shell. You will get a # number to indicate that the connection is successful.

$ adb shell

 

Main ADB device commands

The commands listed below help to migrate applications that have been debugged from the command line to the target device or a simulated device. This is very useful, especially when there is no ssh terminal connection.

adb push - copy file/dir to device

adb pull [ ] - copy file/dir from device

adb sync [ ] - copy host->device only if changed

(-l means list but don't copy)

(see 'adb help all')

adb shell - run remote shell interactively

adb shell

 
- run remote shell command<

adb emu

 
- run emulator console command<

adb logcat [ ] - View device log

adb forward - forward socket connections forward specs are one of:<tcp: >

localabstract: name>

localreserved: name>

localfilesystem:

dev:

jdwp: (remote only)

adb jdwp - list PIDs of processes hosting a JDWP transport

adb install [-l] [-r] [-s] - push this package file to the device and install it

('-l' means forward-lock the app)

('-r' means reinstall the app, keeping its data)

('-s' means install on SD card instead of internal storage)

adb uninstall [-k] - remove this app package from device

('-k' means keep the data and cache directories)

For more information about adb settings and usage, see http://developer.android.com/guide/developing/tools/adb.html

 

Debug C/C ++ native code with GDB *-The GNU Project Debugger

When GDB is used for debugging, gdbserver running on the device is used to process debugging communication, but you can still use the basic USB to Ethernet adapter for ADB to process the communication transport layer, at this layer, gdbserver communicates with each other when GDB runs on the Development host using the TCP/IP protocol.

There is a gdbclient application that can set the debugging communication environment and start gdbserver on the device where the program is debugged.

usage: gdbclient EXECUTABLE :PORT [PROG_PATH]

EXECUTABLE executable name (default app_process)

PORT commection port (default :1234)

PROG_PATH executable full path on target (ex /system/bin/mediaserver)

If PROG_PATH is set, gdclient tries to start gdbserver and attaches it to the running PROG_PATH.

To enable gdbserver explicitly, run the following command:

# gdbserver :1234 --attach 269

Attached; pid = 269

Listening on port 1234

 

The following step-by-step debugging session startup commands demonstrate how ADB uses GDB instead of ADT or DDMS for debugging as the basis for debugging communication. Let's assume that port 1234 is used.

Start Process:

gdbserver :1234 /system/bin/executable

Or attach to an existing process:

gdbserver :1234 --attach pid

On your workstation, use adb to forward port 1234 to the device:

adb forward tcp:1234 tcp:1234

Start the special version gdb in the prebuilt area of the source code tree:

prebuilt/Linux/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (for Linux)

prebuilt/darwin-x86/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (for Darwin)

 

If neither of the two Special versions of gdb can be found, run the find prebuilt-name i686-android-linux-gdbin your source tree to find and run the latest version.

Be sure to use a copy of executable files in the symbolic directory instead of the main android directory, because the copies in the main directory have removed the symbolic information.

In GDB, tell GDB where to find the shared library to be loaded:

set solib-absolute-prefix /absolute-source-path/out/target/product/product-name/symbols

set solib-search-path /absolute-source-path/out/target/product/product-name/symbols/system/lib

Absolute-source-path is the path of your source code tree.

 

Make sure to specify the correct directory-if you make a mistake, GDB may not tell you.

Connect to the device by issuing the GDB command:

(gdb) target remote :1234

: 1234 informs gdb to connect to the local host port 1234, Which is bridging to the device through adb.

Now you can use GDB to start debugging C/C ++ code running on Android * in the same way.

For more information, see GDB *-The GNU Project Debugger.

 

Use the ADT * plug-in of Eclipse * to debug Android * Applications

For®For more information about architecture devices, see http://developer.android.com/sdk/eclipse-adt.html#installing.

For®Architecture simulators and target devices. The ADT * plug-in can provide complete application debugging integrated with Eclipse * IDE. It uses different feature sets to provide two different debugging views.

You can select one of them as needed. Both of them provide different strength when debugging the application.

Debugging view in Eclipse *

The debugging view in Eclipse allows you to access the following tabs:

Debugging-display the Android applications that have been debugged and their running threads

Variable-when the disconnection point is set, the variable value during code execution is displayed.

Breakpoint-display the breakpoint list set in your application code

LogCat-allows you to view system logs in real time. The LogCat tab can also be used in the DDMS view.

 

You can access the debugging view by clicking Window> Open Perspective> Debug. For more information about the Eclipse debugging program, see the relevant documentation.

 

DDMS View

The DDMS view in Eclipse allows you to access all DDMS functions in Eclipse IDE. You can use the following DDMS components:

Device-displays the list of devices and avds connected to ADB.

Simulator control-enables you to perform device functions.

LogCat-allows you to view system logs in real time.

Thread-displays the currently running threads in the virtual machine.

Heap area-displays the usage of the virtual machine's heap area.

Allocate tracker-display the memory allocation of objects.

File Manager-allows you to explore the file system of your device.

 

Runtime Environment of the Application for debugging

Debugging is based on Intel®The Android * application designed for devices in the architecture differs in the time when the target device is set for debugging.

Use the Android * Virtual Device Manager, which is part of the Android * SDK, to select the target device and go to Window> AVD Manager (AVD Manager) in the Eclipse * IDE drop-down menu ). Here you need to make sure that you select Intel Atom as the EABI target for operating system images and device simulation.

If you follow the steps outlined in this article about setting ADB * and creating a debugging bridge pointing to a physical device, you will see the device selector interface in Eclipse IDE, you can select the target for application development and debugging.

In addition®Android * applications designed for architecture devices and Android * applications designed for ARM * architecture do differ in debugging.

The content outlined in the http://developer.android.com/guide/developing/debugging/index.html is suitable for your reference.