Home ›

debug

Debugging database

Fri, 03/12/2010 - 02:25 | by gabor

When I first tried to manage an sqlite database on an adroid device I was not sure about where I fail in it. Can I even insert the records into the database, or I fail only to read the data from it? So I started to search for possibilities to debug the database lifecycle.

The system stores databases in the /data/data/package_name/databases folder by default.

In a command line using the adb (Android Debug Bridge - found in the android sdk tools library) you can access the databases on a running emulator like below:

  1. adb -s emulator-5554 shell
  2.  
  3. sqlite3 /data/data/package_name/databases/database_name

After this you can type normal SQL commands to test the content. For example:

  1. SELECT * FROM table_name;

This will list the table content (in an ugly format), or say that it does not exists.

Tags:

How to debug a Service?

Sat, 12/12/2009 - 09:47 | by akos


debugIntroduction

When you start a project with a service in it in debug mode, and you placed a breakpoint in a method of the service, the debugger will not stop. 

Solution

The solution that works in almost all situation is to wait declaratively in the code for the debugger to attach. To do this, you have to make a call to:

  1. android.os.Debug.waitForDebugger();

The breakpoint can be inserted at any line after this call. 

As a complete example, the SoftKeyboard tutorial is enhanced with the call above:

  1. public class SoftKeyboard extends InputMethodService
  2.         implements KeyboardView.OnKeyboardActionListener {
  3.        
  4.     @Override
  5.         public void onConfigurationChanged(Configuration newConfig) {
  6.         Log.d("SoftKeyboard", "onConfigurationChanged()");
  7.  
  8.         /* now let's wait until the debugger attaches */
  9.         android.os.Debug.waitForDebugger();
  10.        
  11.         super.onConfigurationChanged(newConfig);
  12.        
  13.         /* do something useful... */
  14.                
  15.         }

As you can see in the code, the first call in the method is a call to the logger, with which we can see in the Log output when our method was called. This can be an other way of tracking our method calls, without the need to stop at a breakpoint. But usually this is not enough for detailed debugging.
Then the second statement waits for the debugger to attach, as it is also noted in the comment. After this line the breakpoint can be inserted anywhere in the method.

Debugging a Service in case an Activity is also part of the application is even easier. In that case the activity has to be started first, then the debugger is able to stop at the breakpoint in the service as well, without the need of an explicit waitForDebugger() call.
Tags: