Android Emulator

Last week I visited Grinnell College talking about the work that my research groups has been doing on mobile sensing applications. I had a wonderful time. The Computer Science Department is top-notch. Lots of interesting discussions about ongoing work at Grinnell in systems and programming languages. Below is the abstract of my talk and my slides:

Mobile sensing applications are an emerging class of mobile applications that take advantage of the increasing sensing, computational, storage, and networking capabilities of mobile devices. Chipara’s research focuses on the systems, networking, and software engineering aspects of developing mobile health (mHealth) systems that continuously monitor and infer the health status of patients. His work combines the design of communication protocols, middleware, and programming tools with large-scale real-world deployments of working systems.

In this talk, Chipara will describe AudioSense – a novel mobile sensing application that allows audiologists to assess the performance of the hearing aids in the real-world. A key limitation of traditional laboratory and survey methods employed by audiologists is that they fail to predict when a hearing aid user will be dissatisfied with its performance in the real-world. In contrast with these techniques, AudioSense jointly characterizes both the user’s auditory context and the performance of the hearing aid in that context. The second part of the talk will cover some of the tools his team has created to simplify the development of mobile sensing applications. The focus is one of coordinating when different hardware resources (e.g., WiFi, 3G) are turned on and off to save energy without hindering user experience. A lightweight annotation language and middleware service will be presented that can be used to build energy-efficient mobile sensing applications for Android.

While the above tutorials give you a pretty good idea of what to do, they are terrible at providing guidelines on what to do when something goes wrong. Here are a few common issues:

Wrong source version: make sure that you checkout the right version of the software. If you are going to rebuilt the kernel make sure to use the checkout using the sha1 hash. The hash of the kernel currently running on your device is included in the kernel name. For example, my kernel version was 3.4.0-gfe3bd61[more stuff]. You can checkout the kernel sources used to build the kernel version using the fe3bd61 hash.

Build environment:I am a happy mac user. At the time of writing this post, the current Xcode toolchain (v 6.4), cannot be used to compile the android sources. I have used Ubuntu under Parallels to do much of the development. This solution worked mostly okay. However, if you are not careful you might run out of memory and Ubuntu will kill your compilation process. You can tweak either the amount of RAM dedicated for your VM or configure the lower the number of threads used to compile the source (i.e., make -j N).

Kernel Sins: I spent an entire day trying to figure out why my devices was rebooting after running the boot loader (the device was stuck in an infinite reboot loop). Since adb demon was not loaded yet, it was impossible to get the log to see what was happening. Luckily, Android saves the previous kmesg logs in /proc/last_kmesg that can be retrieved by booting a working kerning image (e.g., the factory images of Android). Inspecting the kmesg, I was able to determine that I was running the incorrect version on my toolchain. Note to self, use the version specified in the documentation (RFM!).