Sunday, January 2, 2011

#android dropped from /staging in december 2010.

(following this post by G.K.-H.)
i guess i'm a bit too late, but it seems the android drivers were dropped from the linux kernel staging tree due to lack of maintenance, which basically means that google no longer has the chance (for now at least) to go upstream with android and keep it up to date with the latest kernel.


this pretty much leaves them maintaining a kernel snapshot which is becoming more and more incompatible with the official linux tree.

i think that this might be a company decision to not spare the resource for the integration or perhaps hope that someone will magically do the work for them without even understanding the driver specifications, security models and etc.
one other thing is that there has been public criticism that google (apart from andrew morton) does not contribute much to the kernel (and same goes for canonical).

the above post by G.K.-H. explains some of their reasons but i think that the longer they wait with the android code the more difficult it would be to be merged, considering what they are constantly adding to the os.

some notes on android


i must admit i haven't even seen an android phone (not much "smart phones" where i live), but i'm fairly interested in the android platform specification wise. here are my impressions:

- linux kernel based os
nicely done. as mentioned above, unless they keep upstream they are going for the route of tv manufacturers, gaming consoles and embedded systems in general - taking snapshots of kernel.org and modding it and maintaing for years, which will eventually leave them behind as they will have to spend more resource to keep up with newer hardware (and in relevance cannot compete with the kernel.org development cycle).

- c++ libs?
not sure exactly what is included but looks like according to the Android NDK the c++ support is "minimal".

- java api for gui in userspace
this is great for a modern machine, as java is very easy to write on and will allow a lot of freedom for developers. not so good for older chips as the JVM is quite slow to be frank (like the flash AVM), it is however possible to use the Android NDK to compile native code. on the other hand the ram usage of the JVM is sometimes out of proportion...considering that the average hardware configuration might have 256 mb a slightly more complicated interface will probably take like 80% of the ram...and i'm not sure how well would a modern interface run with the JVM on a 800hz cpu.

- it has a cool logo


0 comments: