Some Thoughts on Android & Nokia's Lost Oppertunity

After working on Nokia's Symbian OS for around 4 years, I've recently started exploring the Android platform from a technical architecture perspective. The more I explore, the more familiar it seems. One reason of course, is that below the Java layers - what is known as "native" software in Android - it's all regular C/C++ based embedded software on a Linux kernel. Maybe it seems even more familiar to me because my work in Nokia involved a little bit of Maemo/Meego integration also. Indeed, below the Java layers, once could theoretically mix & match code from AOSP (Android Open Source Project) and Meego, and yet have a device that works!

The picture below is an over-simplified system architecture diagram, but helps explain a very high level view of Android.

Android architecture from developer.android.com

The Java layers, which I refer to are the top two layers in blue. The rest (libraries & kernel) is regular C/C++  software running on a Linux kernel. 



Here, is where I feel Nokia missed a great opportunity. As some readers would have guessed, these non-Java layers are quite similar - from a software development point of view - to Meego. The software skills needed are the same, the development tools are largely the same, the HAL (Hardware Abstraction Layer) API's are very familiar to both Meego & Symbian engineers (OpenMAX IL, OpenGL-ES). If only Nokia had diverted all of their Meego staff, and some of their Symbian engineers into Android development, we would have had many great Nokia Android phones by now. Nokia had always been plagued by unacceptably long time-to-market for any new software platform. Be it Meego, Meltemi, or even a new & improved Symbian^3 version. Android had the potential of solving this, with a proven software stack, which can be customized according to Nokia.

 One of the criticism's of Android (at the lower layers, not talking about the fragmentation issue) is that any changes in the kernel come under GPL license and not Apache license. Which means that semiconductor vendors or OEM's who have differentiating, proprietary algorithms for, say, radio/modem communication, audio, or multimedia, would have the risk of open sourcing them, when their drivers are ported to the Linux kernel. However, there's a good working solution to this... the drivers are broken down into the user side & kernel side. The differentiating algorithms can be placed in user side, with simple one-to-one inter-processes communications with a thin layer in the kernel. User side code can be kept closed source. 

Simplified view of Android drivers split into thin layers in the kernel and rest in user side.

But this is something that Nokia and other OEM's already know, given that Meego was also based on the Linux kernel. Nokia has a lot of differentiating software in the lower layers, and this splitting of user-kernel drivers helps assuage any fears of open source contamination of software IP.

A good starting point for Nokia to make an Android device would be the N9, which already has the kernel-side drivers in place. Of course, the layers between the Android HAL, and the kernel drivers is different in Meego, but they can be replaced. For e.g., Meego uses Gstreamer for multimedia, while Android uses StageFright. It seems that the software is modular enough to be able to plugin-plugout one library for another.