When building Android AOSP, it is a common need to customize the build for adding files, libraries, services, properties (and other) to the Android device. Intel created a very convenient way for doing this kind of customizations: they called it mixin.
Let’see how customizing the build is easy with this system.
This tutorial is based on the Intel AOSP branch for Minnowboard Max.
In AOSP tree, board customization files are mainly inside the directory device: different devices are grouped by vendor. For example, when using Intel AOSP, Minnowobard Max related files are inside the directory Intel. In the same place we can also find the subdirectory mixins, which is the heart of the customization mechanism.
Lot of *.mk files are important for the build system: we have BoardConfig.mk, AndroidBoard.mk, device.mk and others. I suppose you already know the purpose of these files. If you don’t, I suggest you to read a very interesting document here. Unfortunately it seems that the official documentationhas has not been updated for a while…
Another category of important files for the device are those with extension *.rc: these are taken by the Android init process during the bootup sequence for initializing and configuring key elements of the system (like, for example, services).
Usually for customizing a device, those *.mk and *.rc files are directly modified.
The mixin mechanism
The mixin mechanism created by Intel allows the device maker to dynamically create those files, by splitting their writing into smaller, logically coherent, parts. These parts are read by a python script (mixin-update) and merged according to a configuration file (mixin.spec) for creating the *.mk and *.rc files needed during the image creation process.
Following a snip of the default mixin.spec file used for the Minnowboard Max:
[main] mixinsdir: device/intel/mixins/groups
[mapping] product.mk: device.mk
[groups] kernel: gmin64(path=gmin,loglevel=5,binary_name=bzImage, interactive_governor=false, dev-kernel=false) boot-arch: efi(uefi_arch=x86_64,fastboot=user,acpi_permissive=true,device=/dev/block/mmcblk0) sepolicy: permissive display-density: low dalvik-heap: tablet-7in-hdpi-1024 cpu-arch: slm graphics: ufo_gen7(use_opencl=true) storage: 4xUSB-sda-emulated ethernet: dhcp audio: hdmi+usb usb: host+acc
The mixinsdir is where all the parts of the customization are found (called groups): each group has a directory. For example there are: adb_net, audio, bluetooth, camera, gps, kernel, usb…
Inside the group directory it is possible to further differentiate the customization, creating other subdirectories. Here we finally find our *.mk or *.rc files that will include only the lines related to that specific group.
Let’s take, as an example, the usb group as it can be found in the Minnowboard Max official Intel AOSP package.
It has three variants:
acc host host+acc
In the mixin sample we can see that the variant host+acc is selected. Inside host+acc we can find
init.rc with the following lines:
on boot write /sys/devices/pci0000\:00/0000\:00\:14.0/power/control auto
product.mk with the following lines:
PRODUCT_COPY_FILES += \ frameworks/native/data/etc/android.hardware.usb.accessory.xml:system/etc/permissions/android.hardware.usb.accessory.xml \ frameworks/native/data/etc/android.hardware.usb.host.xml:system/etc/permissions/android.hardware.usb.host.xml
# usb accessory PRODUCT_PACKAGES += \ com.android.future.usb.accessory
Once run mixin-update these lines will be merged into the full init.rc and product.mk files for the Minnowboard Max.
It is interesting to note that the resulting file has the following warning:
# ----------------- BEGIN MIX-IN DEFINITIONS ----------------- # Mix-In definitions are auto-generated by mixin-update
meaning that the file should not be edited manually.
The build system is capable of understanding if the group customizations are not synced to the current files used in the build, in order not to continue the make process.
Once understood this mechanism, it is quite easy to add one or more groups for further customization of the device.
It would be nice to have this mechanism submitted for upstream integration into vanilla AOSP…