Command Line Android application debugging

http://codeseekah.com/2012/02/16/command-line-android-development-debugging/

I personally has a distaste towards IDEs, preferring lightweight solutions, with maybe less convenience. I addition to saving resources and have direct control over the what happens and what doesn ' t, I find it by doing things t He low level is the better understand how do things work.

Sure, Eclipse would-let-you-debug in 2 clicks, and what does you learn besides so you application have a bug? There should always is time to learn a thing or both about the underlying technologies. What if the one day, you had to SSH into a server and debug a Java application right there and then? If you've never seen anything beyond Eclipse in your life you ' re on for some hair pulling. So let's learn some low level stuff.

The Dalvik VM adheres to the Java Debug wire Protocol, although it does no support all of the Protocol features. This means, any jdwp-compliant debugger should is able to attach itself to an Android application. The Eclipse debugger uses this protocol. But there's a Java debugger which ships with the JDK and would usually is already installed.

It's called Jdb–the Java Debugger, a command line Debugger, and just like GDB.

Debugging Android applications with JDB
In order to attach jdb to a Android application, which is running inside the Dalvik VM, we had to use ADB, the Android D Ebug Bridge. ADB bridges the gap between an application and a development/debugging environment. The Dalvik VM creates a JDWP thread for every application to allow debuggers to attach to it on certain ports/process IDs.

In order to find out the JDWP ID of a debuggable application, issue the ADB JDWP command. This would return a list of currently active JDWP processes. The very last number corresponds to the JDWP, the last debuggable application launched.

To attach jdb to the remote VM, we have an ADB forward the remote JDWP port/process ID to a local port. This is do with the forward command, like so:adb forward tcp:7777 Jdwp:jdwp_port. ADB would open a local TCP socket that's can connect to, and would forward all data sent to the local TCP socket to the JD WP process running on the device/emulator.

Next, attach jdb like So:jdb-sourcepath/your/project/src-attach localhost:7777. The SourcePath is the path to your project's SRC directory, if you ' re launching jdb from your project directory simply stat E-sourcepath src or-sourcepath./src. Press RETURN and you should is attached to your application.

As an example of the full procedure, I ' ve built (don ' t forget to add android:debuggable= "true" to your application ' s Andro Idmanifest.xml file) and launched the WordPress Android application:

[Email protected]:~/code/wordpress-android/2.0.5$ adb jdwp
5384
6385
7051 # <-last launched
[Email protected]:~/code/wordpress-android/2.0.5$ adb forward tcp:7777 jdwp:7051
[Email protected]:~/code/wordpress-android/2.0.5$ jdb-sourcepath Src-attach localhost:7777
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
What is now? The application is running, there's nothing to debug. By default Jdb won't set any breakpoints. It'll break on Exceptions only. In order to add breakpoints you issue stop in and stop at commands, the former would break on entering a method, while the Latter'll break on a specific line in a class:

> Stop in org.wordpress.android.AddAccount.onCreate
Set Breakpoint Org.wordpress.android.AddAccount.onCreate
>
Breakpoint Hit: "Thread=<1> main", Org.wordpress.android.AddAccount.onCreate (), line=67 bci=2
Super.oncreate (savedinstancestate);

<1> main[1] list
the private int blogctr = 0;
arraylist<charsequence> ablognames = new arraylist<charsequence> ();
@Override
protected void onCreate (Bundle savedinstancestate) {
Super.oncreate ( Savedinstancestate);
Setcontentview (R.layout.add_account);
This.settitle
("WordPress-" + getresources (). GetText (R.string.add_account));

wordpress.wpdb = null)
<1> main[1]
I ' ve set the breakpoint on the OnCreate method of the ADDAC Count Activity class. The breakpoint was hits when I tapped "Add self-hosted WordPress Blog". The list command gives us the source listing. We can advance by issuing step (execute from line, step to), next (step over), step up (step until current method ret Urns). Remember you can issue help anytime for a quick look at the available commands.

I order to automate breakpoint position settings, especially if you ' d like to set a breakpoint in the OnCreate method of T He main Activity, you'll have the use of either. JDBRC or Jdb.ini files. You can create these in the directory of you ' re launching jdb from. These files can contain any valid JDB commands. These'll be executed upon attaching.

In order to freeze the application if launching, use the Android.os.Debug.waitForDebugger () method. The application would freeze and wait for a debugger to attach itself before continuing.

Ddms
The Dalvik Debug Monitor Server allows you does quite a lot of neat stuff, like take screenshots from Android device. The DDMS would also forward JDWP ports to local TCP ports automatically.

Logcat
Logcat is another very important command line tool. It shows debug output from all applications. Highly useful to view tracedumps before positioning breakpoints. Although JDB should break on caught Exceptions.

Conclusion
If you ' re racing against time, Jdb won ' t help you get things do quickly. But know it's there when you want to get more intimate with your application and the Dalvik VM. There is lot of visual jdwp-compliant debuggers out there, which can is used if you don ' t want to install a whole IDE jus T for quick debugging, like me. One jdwp-compliant debugger I like and use when I am racing against time is Jswat.

If you had any debugging tips and tricks you ' d like to share with the rest of us I wholeheartedly encourage I-do, Using the comments below.

Command Line Android application debugging