Wednesday, September 19, 2012

Android debugging using the framework source

When writing Android apps, it is helpful to be able to read the implementation of the framework to clarify a point.  This might be when the documentation is incomplete, or if you want to learn from canonical classes like ListView.

Nexus devices contain this framework code unmodified. This allows you to trace your application flow down to the framework level, either to learn how the platform works or to find a bug. Today, the cheapest Nexus device is $199, so having an additional Nexus device is an excellent tool for Android developers, even if you do most of your development for non-Nexus devices.

It is easy to get the source code from the Android Open Source Project (AOSP). You need the following:
  1. A good Internet connection. The full AOSP tree is well over 8 gigabytes of data. If you have more than one Android developer, you could download the tree for a single developer, and then mirror it locally.
  2. A fast computer. AOSP is a lot of code and Eclipse chews a lot of CPU and RAM with large projects. A computer with two CPUs and about 4GB of RAM should do perfectly, you might get away with lesser RAM.
  3. Disk space. If you choose to build the code, you're look at 30 gigabytes of disk space.
  4. Eclipse, some recent version and Sun's Java 1.6.
  5. Linux or Mac. The instructions work for Ubuntu 10.04/11.10/12.04 and some Mac version.

Here are all the steps:
  1. Set up your computer: This can be done on all developer computers simultaneously. This will install all the development tools. At the end of this, you have all the tools but no AOSP code.
  2. Download all the AOSP source: This uses your internet connection to download all the source. The AOSP source has everything going back to the earliest releases of Android. You get all source history, the framework, the open source applications, the kernel, all open drivers, everything. There are instructions on that page to set up a local mirror. Follow those steps to download the source once and then share it over your local network. This conserves bandwidth, and saves time. You might want to start this download over a weekend, depending on your network connection and other users' needs. I will assume that you are putting the source in /usr/local/aosp.
  3. Build the source. Here, you have two options. You could follow the AOSP instructions. However, if you just want to include the source in an eclipse project, those instructions are overkill. You can get a much smaller project if you follow these alternate instructions. If you have trouble with java versions, read the bottom of this post.
    $ cd /usr/local/aosp
    $ source build/
    $ lunch full-eng
    $ # The following step takes time. -j<num jobs> increases parallelism.
    $ make -k -j2 sdk
  4. Create the Eclipse classpath. By default, we can create a project with all the Android source code. This is beneficial if you want to have access to all the AOSP code for reference. If you want just the framework, you can reduce the size of the project significantly. To do this, first create a file in the directory containing the following:
    $ cd /usr/local/aosp
    $ cat excluded-paths 
    This file allows you to reduce the size of the Eclipse project, which improves Eclipse's performance significantly. Now, we can generate the Eclipse classpath as follows:
    $ cd /usr/local/aosp
    $ ./development/tools/idegen/ 
    Read excludes: 3ms
    Traversed tree: 781ms
    $ ls -l .classpath
    -rw-rw-r-- 1 user group 16938 Sep 18 21:50 .classpath
  5. Create the project in Eclipse. First you need to start Eclipse with increased heap size and virtual memory:
    $ eclipse -vmargs -Xms128m -Xmx512m -XX:MaxPermSize=256m
    Now, create a new Eclipse project (File -> New Java Project -> Next). In the dialog, under the "Libraries" tab, click the "Add Library" button -> Add System Library -> Add JRE system library. This will help resolve the references to core libraries like Integer and String. Adding the system library is not required, but it reduces the number of syntax error Eclipse finds with the framework. Click "Finish" when done.
  6. Done! Try your setup by searching (Ctrl-Shift-T) for FragmentManager. You should be able to see its source code, and navigate through its code. Some handy commands are: Ctrl-Shift-G to look for references of a class, and F3 to look for a method's implementation.

JDK version pain: You might encounter a problem with JDK versions. You need Sun Java 1.6 to compile the AOSP source code, while your Eclipse setup might require a different version (OpenJDK?). One solution is to use sun-java only to compile the AOSP, and switch back to the previous version after the compilation has finished. On Ubuntu, this is done with the commands shown below. Select the number that corresponds to sun-java before the compilation, and run these commands after running to switch back to your previous version of jdk.
$ sudo update-alternatives --config javac
There are 2 choices for the alternative javac (providing /usr/bin/javac).

  Selection    Path                                         Priority   Status
  0            /usr/lib/jvm/java-6-openjdk-amd64/bin/javac   1061      auto mode
  1            /usr/lib/jvm/java-6-openjdk-amd64/bin/javac   1061      manual mode
* 2            /usr/local/sun-java-1.6/jdk/bin/javac         1         manual mode

Press enter to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/lib/jvm/java-6-openjdk-amd64/bin/javac to provide /usr/bin/javac (javac) in manual mode.
$ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
  0            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      auto mode
  1            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manual mode
* 2            /usr/local/sun-java-1.6/jdk/bin/java             1         manual mode

Press enter to keep the current choice[*], or type selection number: 2

Sunday, September 16, 2012

Where are you from?

When Indians meet, one of the first question is, "Where are you from?" Depending on the parties involved, the answer can have varying degrees of detail.
  1. Born in different states: the name of the city, if it is well known: "I'm from Madras". The name of the state if the city is not well known: "I'm from Assam" rather than "I'm from Duliajaan"
  2. Born in the same state: the name of the city: "I'm from Satara".  Perhaps a locality within the city if the city is popular: "I'm from Old Delhi". This is especially true if the locality has racial/religious connotations.
  3. Born in the same city: the region where you are from, but now you specify your mother's and father's place as well: "We live south of the Yamuna, but my mother's family is from Satara".
I hate this question. People trace your origin so they can find a familiar prejudice to apply. If you are from Madras: you are immediately perceived as a Hindu, most likely vegetarian, lover of rice and hater of wheat. Your Hindi is perhaps terrible, you enjoy spicy food and worship your Reader's Digest. This question finds differences without finding any common ground. It doesn't lead to any insight, it doesn't make you understand the person any better.

It is awkward if this question is quickly followed by total silence, as if your place of birth is the only noteworthy information about you.

I have always considered this question quirky. My parents were born in a city that I have never visited, and I have only visited the state once, many years ago. My parents traveled often, so the entire question makes little sense. I have grown up in five cities, and I am an alien to all of them. I'm not really from any city. For many people in my generation, this question is pointless.

I would rather discuss people's interests, their aspirations and their passions. It is our common interests that bring us together, not our differences.

(Image courtesy: Samaritan's Purse)

Saturday, September 15, 2012

Experiences with Human Resources

In any software engineering shop, good engineers are the biggest asset. A Human Resource department is supposed to manage this critical asset. In my experience, even exceptional companies have lousy (or downright inethical) Human Resources teams. Here are some experiences, in no particular order. They are all from top tier software firms from the San Francisco Bay area.
  1. The cheapskates: After a campus interview, the HR recruiter offered to give me a gift card for the company's store. The company was well known, but I did not use their store, so I declined the offer. The recruiter persisted, she said I could give it to a friend. Hesitatingly, I accepted the card. The denomination on the card was One Dollar. The company had printed cards for a single dollar and was handing it to candidates who were being interviewed. This was in 2008, when a cup of coffee cost two or three dollars. I considered giving her a ten-dollar bill so she could give the next sorry contestant something substantial.
  2. The lazy: After successfully making it through the interview process, I was unable to contact the recruiter for a month. In the intervening time, I started interviewing at a different company, was offered a position, accepted, and had signed formal papers. Much later, the recruiter contacted me again, suggesting she could send me the formal offer. By now, it was too late.
  3. The shameless: After contacting me and setting me up with technical interviews, the HR recruiter decided to join another company. While I was still interviewing at her previous company, she started hounding me for positions in the new company she was now working for.
  4. The unethical: After I declined to join a company, a recruiter from the same company contacted me under the pretense of discussing the failed offer. A few minutes into the conversation, she started asking me all sorts of probing questions about my current compensation and internal details of my project. Both of these are confidential, so I declined. At this point the recruiter said that she was a contractor and her company also hires for several other top tier software firms, and offered to set me up with them.
  5. The mugger: At a well known developer conference, this recruiter was waiting in the shadows. She struck up a conversation with engineers as they left the talks, asking them about their work. A few minutes into the conversation, she mentioned how she was a recruiter and was hiring for a well known firm.
  6. The comatose: After receiving a question about compensation when changing roles at a company, this HR business partner decided not to answer for another two months. By this time, the role change had already happened. When asked again, she said she didn't know anything about compensation when changing roles. If HR doesn't know such things, what do they know?
Human resources are the public face of the company to candidates. If they act poorly, a candidate suspects that such behavior is ingrained in the company culture. The image and brand of a company can be tarnished by the sloppy behavior of their recruiters and human resource staff.

Conversely, a considerate and thoughtful human resource personnel improves the image of a company. I interviewed at a company that I would have never considered joining due to personal reasons. However, their HR personnel were exceptionally caring and understanding. Declining their offer was a very difficult decision only because of their wonderful HR team.