http://www.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations http://www.mentor.com/ http://www.androidx86.org/
On Thursday 15th October 2009 Matt gave a very entertaining presentation (that subsequently won the presentation of the show award) on the state of Android from the potential integrators perspective. The talk looked at why people are so interested in Android and detailed what happens when you take Google’s phone OS and put it on a device that isn’t a phone.
- Android is a hugely popular topic at the moment.
- Android does not adhere to standard Linux principles.
- Android has been designed with phone devices in mind and not much else.
- Hard coding and bad design decisions make it harder to do anything different with it.
Matt pointed out the obvious, Android is a hugely hot top at the moment. Every manufacture is interested in bring Google’s operating system to their particular device. The problem lies with the fact that Android was only really designed for phones, not the plethora of weird and wonderful devices that are now the focus of attenton.
What is Android?
- Linux kernel + Android patches (around 115 patches).
- Ashmem for common shared memory.
- Android specific power management.
- Bionic which is Googles replacement for libc.
- Dalvik VM.
- Many other tailored components.
Bionic is Googles replacement for libc derived from BSD and only supports ARM and x86 out of the box. It has partial thread support but no SysV IPC or STL support. The prelinker is also uniquely tailored to Android. There are no linux-headers and only minimal ‘scrubbed’ headers available for new binaries to use.
Other Missing Bits
Another problem Android porters face is that there is udev. Instead Android’s init does a somewhat poor job (all hardcoded) of setting up the device nodes in the /dev directory.
Hotplug support via ‘vold’, not HAL, only extends to MMC devices. Other types of devices need some modifications to work. Similary, input devices are also limited to keyboard, trackball and touchscreen support. Again, other devices need modifications.
Screen size support is also limited by default. Anything above 1024×768 runs out of video memory rather quickly.
Another aspect that manufactures fail to realise is that the UI is designed for a mobile phone. Certain things can look terrible at higher resolutions and many apps are designed with an absolute rather than relative layout. Other problems with the UI are caused by the OS expecting certain peripherals such as telephony support, wifi, and other handset related bits. Similary, peripherals that alot of over devices have such as ethernet are not supported.
More problems for non-handset makers
One of the big draws of Android is the Android Market Place. This is a central hub for Android applications and guess what, its not available for customized Android installations.
The Dalvik VM that Android uses extensively (derrived from Apache’s Harmony project) is very Endian specific so moving that to another platform with a different Endianness proved to be tricky.
Finally to drive the point home, Matt gave an example of the bad coding decisions made by the Android developers. He showed many examples of hardcoding which was just bad practice.
Matt concluded with a few points.
- Android is not like a traditional Linux.
- Android departs from accepted user-space components and techniques.
- Android is tailored for the handset with little thought into any other form factor.
- Android has many hardcoded elements and bad practices.