User:Dhylands

Here's some information about me

Samsung Galaxy S2

I wrote up a page on creating a serial adapter for the Samsung Galaxy S2. And a page on getting the kernel console on the serial port.

Ubuntu 12.04

Here's a page with notes about using ubuntu 12.04.

Tools

ack

I found a really great search tool called ack. It's bascically grep but better. It automatically searches directories and knows about source files (which it looks through), and source repository files (which it ignores).

I normally install the standalone version (the command below assume you have a ~/bin directory)

curl http://betterthangrep.com/ack-standalone > ~/bin/ack && chmod 0755 !#:3

You can use the ACK_OPTIONS environment variable to make ack automatically search idl, ipdl, and jsm files:

export ACK_OPTIONS="--type-set idl=.idl --type-set ipdl=.ipdl --type-set webidl=.webidl --type-set jsm=.jsm --type-set rc=.rc"

colored logcat

This is a script I've been carrying around for a while. It takes the output from adb logcat -v threadtime and colorizes it.

On my otoro and unagi, I find that the default logcat output is a tad verbose. I currently change line 114 from:

input = os.popen("adb logcat -v threadtime")

to be:

input = os.popen("adb logcat -v threadtime memalloc:I ONCRPC:S EventHub:I OMX.google.mp3.decoder:V")

If you have a recent adb (I'm using 1.0.29), you can get help for logcat commands using

adb logcat --help

logcat

logcat is Android's utility for printing logs. Some useful options that I find myself using all the time are:

• -c (causes the log to be cleared). Useful if you stop/restart b2g alot and don't want to see output from previous runs).
• -d (exits logcat after dumping the log, rather than hanging and waiting for more log data)
• -v threadtime (causes the thread id and timestamp to be printed)

Regular output:

V/EventHub( 2857): /dev/input/event1 got: t0=48357, t1=198669, type=0, code=0, value=0
V/EventHub( 2857): /dev/input/event1 got: t0=48357, t1=335544, type=1, code=102, value=0
V/EventHub( 2857): iev.code=102 keyCode=122 flags=0x00000000 err=0
V/EventHub( 2857): /dev/input/event1 got: t0=48357, t1=335550, type=0, code=0, value=0
I/power   ( 2857): *** set_screen_state 0

-v threadtime output:

06-05 09:47:04.360  2857  2885 V EventHub: /dev/input/event1 got: t0=48357, t1=335544, type=1, code=102, value=0
06-05 09:47:04.360  2857  2885 V EventHub: iev.code=102 keyCode=122 flags=0x00000000 err=0
06-05 09:47:04.360  2857  2885 V EventHub: /dev/input/event1 got: t0=48357, t1=335550, type=0, code=0, value=0
06-05 09:48:04.370  2857  2857 I power   : *** set_screen_state 0

With -v threadtime you can see that the EventHub messages come from the same process (2857) as the set_screen_state message. The set_screen_state message comes from the main thread (since the process id and thread id are the same). The EventHub messages are being issued from a different thread (2885).

And you can use logcat through adb from the host (i.e. adb logcat) or from a shell on the phone (i.e. adb shell, ssh, etc).

pathlist

I wrote a little utility called pathlist, which shows each element of your PATH variable, but puts each path on a separate line. It also highlights paths which exist by coloring them in green and highlights paths which don't exist in red.

#!/bin/bash
#
# This script prints out your PATH, one subdirectory per line.
#

RED="\033[1;31m"
GREEN="\033[1;32m"
NO_COLOR="\033[0m"

IFS=:
for dir in ${PATH}
do
   if [ -d ${dir} ]
   then
      echo -e "${GREEN}${dir}${NO_COLOR}"
   else
      echo -e "${RED}${dir}${NO_COLOR} - doesn't exist"
   fi
done

Typical output looks like:

ueventmon

ueventmon is a command line tool which will report uevents as they occur. It reports the event as well as the individual parameters.

Typical output looks like:

root@android:/ # ueventmon
Socket opened
change@/devices/platform/sec-battery/power_supply/battery
  ACTION=change
  DEVPATH=/devices/platform/sec-battery/power_supply/battery
  SUBSYSTEM=power_supply
  POWER_SUPPLY_NAME=battery
  POWER_SUPPLY_STATUS=Full
  POWER_SUPPLY_HEALTH=Good
  POWER_SUPPLY_PRESENT=1
  POWER_SUPPLY_ONLINE=1
  POWER_SUPPLY_TECHNOLOGY=Li-ion
  POWER_SUPPLY_VOLTAGE_NOW=4182500
  POWER_SUPPLY_CAPACITY=100
  POWER_SUPPLY_TEMP=280
  POWER_SUPPLY_CURRENT_AVG=-1
  SEQNUM=1767

Debugging Android

Finding out who is holding a Mutex

Sometimes you wind up in some code which is blocked trying to obtain a Mutex and you'd like to know who is holding it. One way to do this is to enable something called PTHREAD_MUTEX_ERRORCHECK. This will cause the Mutex class to encode the tid of the mutex owner into the value.

You'll need to edit the file: frameworks/base/include/utils/threads.h

Find the contructors (around line 268), which look like this in their original form (for ICS)

inline Mutex::Mutex() {
    pthread_mutex_init(&mMutex, NULL);
}
inline Mutex::Mutex(const char* name) {
    pthread_mutex_init(&mMutex, NULL);
}

and change them to look like this instead:

inline Mutex::Mutex() {
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
    pthread_mutex_init(&mMutex, &attr);
}
inline Mutex::Mutex(const char* name) {
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
    pthread_mutex_init(&mMutex, &attr);
}

Now when you're in the debugger, you can examine the mMutex (which is a pthread_mutex_t) and grab the value field (the only field inside the pthread_mutex_t). The upper 16 bits will contain the thread id of the mutex holder. In gdb, you can use "info threads" to see all of the running threads, and you can use the "thread number" command to switch between threads (to examine the backtrace etc).

Running updater xpcshell tests locally

I was working on the updater, and its useful to be able to run xpcshell tests locally. So here's my updater xpcshell page.

Mentoring

This is my collection of mentoring links that I use when mentoring people.