Android and device computing

I have been playing all the sample code from Android SDK in the last couple of weeks. Being voted as the best supported plugin for Eclipse, ADT works very well for me. (Just for the sake of completeness, you can find the set up using emacs for Android here.) What I particularly like about is the debugging and testing support. The emulator looks pretty cool and you can view all the live process in the Device window. Other than the standard, basic thread monitoring, you can monitor and trace the heap memory after you triggered the heap update on the selected process, similarly for threads contained in that process. You can trace the call stack on each thread. The only pity is that you do not have the full source code for Android library with the SDK, although you can get them from here. LogCat seems to pretty handy as well for dumping the system messages. The other debugging tools have been summarised in developer guide.

I quite like the simple view designer comes with ADT and how xml files are organised as resources. The magic AndroidManifest.xml has also a nice application editing view where you can define your activities, process, tasks and permissions etc. Although there are a few low priority usability bugs such as adding nodes.

As far as testing is concerned, it does not seem to be that straight forward to automate test other than via host os scripts using adb shell command. There are some good discussions on test project on emulator, and here. Within SDK, there are a built-in test framework and mock templates to be used which come quite handy with additional support tools such as emulator control. It would be really helpful to have the full support for all the other peripheral I/O as well, such as USB, Bluetooth, motion sensor etc. At the moment emulator control only offers interface for test input to telephony (with options could be set for different network latency and speed settings) and location based service.

There was one incidence while I was playing with the thread creation. The notepad sample project failed with an exception telling me that thread has stopped from updating UI unexpectedly (I have always had difficulties in understanding what exceptions are expected.). Again, Eric has already caught this out.

In general, HW test for me for Android is quite nice. With another big player joining in the mobile device platform, there is no question that much more interesting applications will come out fairy soon. Although it might need some smart minds to create profitable products. There are news already that manufacturers like Samsung, Skystone and others are looking to adopt open source platform like Android in other embedded system products. The mobile computing device should be able to benefit from this significantly, I think. Apparently, Android has been successfully ported to X86 architecture as well for ASUS.

Rebuild Android kernel seems to be only possible on Linux yet claimed on this well-referenced post. What I have not realised that there are crazy folks actually re-built Mono for Android, to which I would really want to try. It would be fun to see me recompile some of the MS .Net apps using Mono and port to Android. You might have noticed by now that Android is not just a SDK from which you can build smart phone apps. The Linux nature of Android actually offers OS level support for apps development. To enable on-target development, HTC has recently published Android system image (1.5) to help curious developer build a device from scratch. Although there is a discrepancy between developer phone (Android Dev Phone 1) and real one, the latest SDK was setting to reconcile this. I guess I would never know until I try!