This page documents progress and issues about the new 'unified' build.

Background

The project aims to

• provide a single device tree for all instead of one per device "group" and thus reducing the number of possible images to one (although in reality we want to provide one image which is SSE3-enabled/Atom-optimized and one which only requires SSE2)
• make it possible to patch the base system image at boot time through the use of AuFS
  

Motivation

There are some major advantages we hope to achieve by this:

• reducing the number of different images to "try out" for new devices
• making it possible to add system services or custom binaries after the installation without re-installing the system
• eventually providing an update mechanism similar to phones

It is also beneficial for developers because

• much broader user base for feedbacks
• better to see "best practice" for adding new devices
  

Implications

Having one device tree means

• including all GPU drivers
• already possible
• including all standard kernel modules
• already possible
• including potential out-of-tree kernel modules
• possible, but needs to modprobe them based on dmi/pci device numbers
• including all available RILs
• possible, but needs to setprop the correct libril implementation
• including all available hardware libraries
• liblights - only one available, probably sufficient?
• libsensors - at least two implementations available, how to handle?
• libcamera, gps, audio - only one available, unlikely to have more than one?

Considerations

• how can system overlays be handled in a generic way?
• storage definitions can be "maxed out", if one of the storage methods (e.g. real SD card slot) is not available on one device, it will simply not appear
• default/initial system parameters could be handled by an Android app which sets them during the "device provisioning" phase
• how can the init.rc be extended on a per-device basis?
• set androidboot.hardware in cmdline during installer - this could then also be used to symlink the hardware libraries to their correct implementations
• inclusing mechanism of additional .rc files and overlay them via AuFS
• vold.fstab
• probably best to auto-detect during installer and then overlay via AuFS or bind-mount
• can we use the recovery image which we currently do not use to change hardware parameters after the installation?
• could be used to adapt in case the hardware has changed
• could be used to install updates