I intended to do this for a long time now, since Android Debugging goes hand in hand with Linux debugging. I’ve noticed, during my trolling on the >InsertCoin forum, that people that start messing around with their Android mobile (read: start rooting it), don’t know what to do if something fails.

The minimum tools needed for any debugging are:

  • The Android SDK
  • Windows Command Prompt
  • USB Cable (the one that came with your Android device will do just fine)
  • Notepad (or, better yet, Notepad++)

As I said, these are the minimum tools needed. It would be excellent if you would be able to run a Linux machine for the debugging purposes, especially since there’s no “cat or grep directly under WindowsOS. This is the reason why these tools are not included in this How-To. We will be using them, however, under the Android Debug Bridge shell.

So, after you install the SDK (Warning: for Windows7 x86_64 users it’s not simple), you can connect your phone to the USB.

First thing to check is how the phone is connected:

  • Under Settings / Connect to PC / Default connection type -> Charge only
  • Under Settings / Connect to PC / Ask me -> unchecked
  • Under Settings / Applications / Development -> USB debugging -> checked

Preparing your Command Prompt is also important.

You want stuff to be done as easy as possible. For this, make sure you have on your desktop a link to c:\windows\system32\cmd.exe. Right-click it and go to properties. Under “Advanced” in the “Shortcut” tab, select “Run as administrator”. Under “Font” select “Lucida Console” and under “Layout” change the “Screen buffer size” width to something more in the area of 100 and the height to 3000. The “Window size” width set it the same as above and the height to 50-80 (what you feel comfortable with). In the “Options” tab check the box labeled “Insert mode” and “QuickEdit mode”.

Now your command prompt window should be larger, stuff more easily to spot, plus you can now copy by just selecting the text and right-clicking it.

Last thing to do is making sure all your Android SDK tools are in your working path. For this right-click “My Computer” and go to “Properties”. Under Windows7, select the “Advanced system settings” on the left of the window. Make sure you’re on the “Advanced” tab of “System Properties” and select “Environment Variables”.

In the “System Variables” area scroll down until you find “Path” and double-click it. Add at the end:

;C:\Program Files (x86)\Android\android-sdk-windows\platform-tools;c:\Program Files (x86)\Android\android-sdk-windows\tools

You will need to relog in Windows for these changes to be applied to your working environment.

Still here? Good, because now the fun part starts.

Start your command prompt and type:

C:\Windows\system32\>adb shell

You will see the small hash (#). It means you are with root (superuser) rights.

In another command prompt, type:

C:\Windows\system32\>adb logcat

There will be about 2,000,000,000,000 scrolling lines, just wait a few seconds util it’s settled. This is the phone log, it should tell you if anything is actively wrong with it.

Back to the shell, what you need to find out is:

  • what filesystems are mounted
  • what processes are running
  • what kernel is running

To see what is mounted, just type:

# mount
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mtdblock3 on /system type yaffs2 (ro,relatime)
/dev/block/mtdblock5 on /data type yaffs2 (rw,nosuid,nodev,relatime)
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nosuid,nodev,relatime)
tmpfs on /app-cache type tmpfs (rw,relatime,size=8192k)
/dev/block/mmcblk0p2 on /system/sd type ext4 (rw,noatime,nodiratime,barrier=1,stripe=64,data=writeback)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,relatime,size=0k,mode=000)


The lines that are usually generating problems in any custom ROM are the ones that start with /dev/block/mmcblk0pXXX, where XXX is the number of the partition. For this, I will take the line 15. of my example to explain the meaning:

/dev/block/mmcblk0p2 on /system/sd type ext4 (rw,noatime,nodiratime,barrier=1,stripe=64,data=writeback)

The first part, /dev/block/mmcblk0p2, is the source. More on the /dev filesystem here.

The second part is where that source can now be accessed, or the destination (in our case, the directory /system/sd).

The third part is the File System (ext4) and in brackets you find the options that were used by the operating system when mounting. By searching online, you will find a lot of information about these options.

Running processes you can see with the command ps w. The list will be pretty long, but full of interesting information.

The first column contains the process ID, followed  by the UserID (the user that started the process), memory size, status and process name.

The information is useful, for example, if you want to kill a process. The command is

kill -9 PID

Replace the PID with the ProcessID from the ps w command.

Another useful way to see what is running, but also to see what is taking all those CPU cycles at that moment, is the command top:

# top -m 20 -n 1 -s cpu -t
top -m 20 -n 1 -s cpu -t

Almost always, the first command that will show up in the output is top itself, as it takes quite some CPU to get the information and display it.

Please ignore the system_server app. It’s the core of the Android system as described here.

Last point on today’s list, is the running kernel:

# uname -a
uname -a
Linux localhost #1 PREEMPT Thu Dec 16 13:00:48 CET 2010 armv7l GNU/Linux

As you can see, the kernel is

I will probably write some more posts about what to do with this information that one can gather, how to understand it.