I switched from using Windows Mobile Phone devices to the Android platform a couple of months back with the Google Nexus One. With Microsoft following the lead of Apple in closing everything they’ve kept open for so long, there wasn’t much to look forward to with Windows Phone 7 (I was almost going to work on that team had I moved to the US a couple of years ago). Though, I’ve started writing for the new WP7 series via work, I’ve felt it was time to move on. Android is a breath of fresh air, I’ve toyed around with the G1 but the Nexus (whilst still a HTC device) is a joy to use as is the operating system. I actually have two Nexus’s these days, one is kept stock as my primary phone, whilst the other is using the Cyanogen mod.
Windows Mobile was never touch friendly – and rightfully so, as the operating system was written for stylus usage as a primary goal, then later HTC (via TouchFlo3D) bolted on a new UI to bring touch friendly UI candy for Windows Mobile. Though Windows Phone 7 brings this to the table (with touch being a primary design goal), I’m ashamed to say they’ve taken what WinMo was good for – being easy to customise and cook ROMs for and turned it to the Apple-esque closed ecosystem and Jobs likes being in control of his herd.
The great thing about the Android is that its got potential and its constant source of updates are very welcome (probably the fastest growth for a platform thus far!), the AppStore has increased exponentially the past few months (which is good and bad – useless app count increases) as users begin to crawl out of the rotting Apples and the stained Windows phones. Another key is that all your Google services are integrated nicely. I’ve given up most of my daily things to Google – email, calendar, contacts… They’re all “in the cloud” and (for now) synchronisable and safe (not that you couldn’t do this with the iPhone or Windows Mobile).
The next release of Android (2.2) is dubbed Froyo and brings some very funky new updates.
JIT Compiler
Probably the biggest addition in this release but first and foremost, the design and architecture of the Android platform is a bit different to others. Forgetting the native development paradigm for Android, you write applications utilising the Java language.
From the Android Developer Guide:
Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. This file is the vehicle for distributing the application and installing it on mobile devices; it’s the file users download to their devices. All the code in a single .apk file is considered to be one application.
In many ways, each Android application lives in its own world:
- By default, every application runs in its own Linux process. Android starts the process when any of the application’s code needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications.
- Each process has its own virtual machine (VM), so application code runs in isolation from the code of all other applications.
- By default, each application is assigned a unique Linux user ID. Permissions are set so that the application’s files are visible only that user, only to the application itself — although there are ways to export them to other applications as well.
It’s possible to arrange for two applications to share the same user ID, in which case they will be able to see each other’s files. To conserve system resources, applications with the same ID can also arrange to run in the same Linux process, sharing the same VM.
In order to achieve this, the Android platform uses the Dalvik Virtual Machine (which is register based as opposed to the more common stack based machines) suited for embedded devices – low memory footprint, run multiple VMs by offloading the process isolation, memory, threading and IO management to the operating system (Android).
The caveat with the Dalvik VM is that the performance is not ideal (it has no JIT compiler) and (by the looks of it) needs to improve garbage collection process (fragmentation is a concern currently). If you’re keen on understanding more about the Dalvik VM, checkout a talk from 2008′s Google I/O about Davik VM Internals (1:01:34). They also realise the performance implications of the runtime.
However, back in November 2009, Bill Buzbee commited the Dalvik JIT code to the Android platform bringing JIT compilation which (if you’ve been using any of the CyanogenMod’s lately) makes a very noticeable and welcome performance boost to all applications.
The (trace-based JIT) compiler detects frequently executed traces (hot paths & loops) and emits optimised code for the platform as necessary, ensuring that minimal heap memory is utilised without the use of any persistence storage – which is what you want in an mobile device! Trace based JIT compilers are very common today, the TraceMonkey engine in Firefox is an example where dynamic languages (like Javascript) have had a boost through their use. Take a look at SPUR which is a Microsoft research project to bring trace-based JIT Compiler for CIL.
Whilst included in Android 2 it was never enabled, and by the looks of it, Android 2.2 will see this being enabled and stable 
Linux Kernel update 2.6.32
The upgrade from 2.6.29 to 2.6.32 should bring a trimmed memory foot print and some performance tweaks as well as 802.11n support on devices such as the Google Nexus (yay!)
Flash 10.1 Support
There’s lots of hoo-haa about Flash support on iP*’s and other devices, I’m not too concerned about having it on my phone (less annoying ads browsing the interwebs) but it seems Google will bring Adobe Flash 10.1 support to Android. For some, it was a deal breaker when it came for choosing a phone. I guess now its a matter of ooh-ah!
Automatic application updates
Currently, updating Android applications is quite tedious – updating one application at a time, but it seems a newer update will automatically ensure that your applications are up to date – which is good and bad, I’d like to control when and where it decides to eat up my 3G data for updates (Eg. Update when on wireless)
Hopefully a rollback feature will also be implemented in case the newer versions break things.
Other updates
- OpenGL ES 2.0 enhancements which game developers will find enticing.
- The ability to control the color of the trackball (which currently flashes white)
- Enabling of FM Radio
- Fixes for resolution and “crazy screen” woes.
When will we be getting this? No-one knows, but suggestions are around the time for the Google I/O event on May 19th.
Next up, I’ll write about some of the applications that I’ve come to use daily, in the meantime you can see the apps running on my Android by checking my AppBrain account. Later some development articles on Android too
