Working on CyanogenMod
Those of you who have been following my GitHub repos in the past few months will have noted a large influx of Android related commits. While I was supposed to be working on my M.S. project, I took a lot of my free time to work on a port of CyanogenMod to my Android phone at the time, the HTC Sensation, device codename “Pyramid”. Since this was pretty much my first real go at working on the Android system (app development isn’t quite the same), I managed to learn quite a bit.
The starting point for any device supported by CyanogenMod is the device tree is the device tree, that typically lives in the /device/<manufacturer>/<device codename>. (where / is the top of the Android source tree) This repo is where device specific configuration options live. This repo can inherit from a device-class repo as well. (eg. htc/msm8660-common, for all HTC MSM 8660 devices) Most of the configuration actually lives in two main files, device_<codename>.mk (sometimes simply <codename>.mk), and BoardConfig.mk. BoardConfig.mk is where the description of device and hardware specific features goes. This includes defining the device name, CPU flags, display flags, sound flags, etc. The complete file ends up as a description of the device to the Android build system. Where BoardConfig.mk is responsible for defining a device, device_<codename>.mk is responsible for defining what packages and files go into the final device build. The Android build system largely defines targets as modules, and listing a module in the device_<codename>.mk file as a product package will cause it to be built and included in the final output. This includes all the HAL files (audio.primary, audio.policy, hwcomposer, camera, etc) as well as apps such as live wallpapers. This is also where additional files, such as those necessary for the ramdisk, configuration, etc are copied. Proprietary libraries that are extracted from the original device software are not copied here however. Due to various issues, proprietary files extracted from the original device software actually go to a directory hierarchy under /vendor/<manufacturer>/<device>. Typically a nice script will create the directories, generate the makefiles, extract the libraries, and copy them the correct place. All that is necessary is to tell the script which libraries are to be extracted. The most common method uses the proprietary-files.txt file to list all libraries needed.
Once a suitable device tree has been defined, and the appropriate files have been extracted, we can begin building. On a new device or class of devices, this typically means bringing in the corresponding HAL and other associated libraries. Typically these will come from upstream, bring provided by the chipset manufacturer themselves. (Qualcomm for the MSM series, TI for the OMAP series, Samsung for the Exynos/SMDK series, etc) This code tends to live in the /hardware/<qcom/samsung/ti> directories. Once this platform code is integrated into the build framework, work can proceed on working out the build process, and eventually on to adding device specific support. This is typically necessary as each chipset manufacturer has their own forks of the Android framework which they have then proceeded to hack up to better support their hardware. Since the patches released generally target development boards, real shipping devices (phones, tablets) typically have slight differences, either in additional DSPs for image or audio processing, or just different hardware revisions. All of this must be accounted for in the CyanogenMod hardware repositories. This is typically where all the problems lie in getting new devices supported. This is also again, why a support for a single device usually brings support for many other devices in short order. As they all share the MSM8660/Snapdragon S3 chipset, work on the pyramid device helped enable doubleshot (MyTouch 4G Slide), shooter (Evo 3D), and even Samsung Galaxy S2 US variant support.
The major shortcomings lie primarily in the lack of code and documentation for many of these devices though, making it difficult to get things working for which no code has been provided. This typically means the camera, and sometimes the RIL (radio interface layer). Camera support in particular, continues to be the bane of CM developers, as nearly everything necessary remains proprietary, and hidden.
As is with any software project, once you become familiar with the infrastructure, work proceeds much faster, as the ville (HTC One S) port I’m working on currently is closing in on full functionality, while the pyramid port took a bit more time. Currently I continue to work on the pyramid as well as the ville, and am working to improve MSM8960/Snapdragon S4 support in CyanogenMod. You can keep up to date with my work on my GitHub, as well as the CyanogenMod Project code review tool. Additionally, you can learn more about this from the man himself, as Cyanogen gave a talk recently on this very subject.
Originally published at www.intervigil.net.