Each of the main directories has different stuff in it. Here are just a few off the top of my head to get you started. The description is fairly flippant and incomplete and perhaps inaccurate, and I’m going to skip some directories because it’ll get unwieldy (and I don’t know necessarily what every directory does), but it’s just to give you a vague idea of some of the more important folders…
This is seriously all just typed off the cuff, without really much thought. It’s certainly an incomplete description. The best way to discover what to play with is just to start exploring, changing stuff, and building. The directory names are usually indicative of what you’ll find inside, and the best source of documentation is the code itself.
Bionic is the Android mobile-friendly version of libc. You generally don’t need to touch anything in here. Lots of cpu-specific stuff and better not to stick your nose in here, although Linaro did manage to speed up performance on some devices by tweaking various things. If you’re a coding ninja, you can play with this. But on the other hand, if you were a coding ninja you probably aren’t reading this.
The scripts and various files that are used for the actual build process. Take a look in here if you’re curious what steps are taken to make all the parts of Android compile, as well as various “
make” commands. (Some of the flags used for compiling have been further enhanced by CyanogenMod for Google non-supported platforms.) Some familiarity with GNU make and the Makefile build system are helpful. There’s also documentation here and here.
Among other things, the source for ClockworkMod recovery is in here.
Dalvik is the virtual machine that runs the java apps. It’s how you can write an app and it’ll run on any android machine, regardless of the underlying architecture. In the “Lollipop” 5.0 version of Android, Dalvik was replaced with ART, the Android Run Time.
ART (Android RunTime) is a replacement for Dalvik introduced in Android 4.4 (KitKat). Rather than “just-in-time” compilation, ART pre-compiles every app in advance for faster execution later.
device/ contains part (if not all) of the board support packages and configurations for a ‘particular’ device, and is organized as
device/<vendor>/<codename>. So the files for the Nexus 7 tablet are under
device/asus/grouper/, the files for Nexus 4 phone are under
device/lge/mako/, etc. The
device/ folder, therefore, is where to put the customized stuff for EACH particular device running Android. So– if you want to do a port of Android for a particular device that currently has no source, you should probably start by finding a similar device (with a similar underlying platform) and use it as a “base” for modifying for that device. Do take a peek into
device/asus/grouper to see the various files that are used to build for the Nexus 7 and compare with other devices.
Many of the xml files that control Android core functionality and verbiage (strings) can be overridden by new .xml files that you place in the device-specific
Just downloading the source code for CyanogenMod does *not* download the
device/ directories for every single device that has been ported to CyanogenMod (that would be a LOT of extra folders you probably don’t need or want). To get the device folder for a particular device, use the
breakfast command from the root of the source code. So to get the
grouper device (and kernel) folders, you’d type
breakfast grouper and then
repo sync and it should appear.
Contains the source code for the Android Open Source website.
This is where non-android specific utilities go. Lots of the stuff in here are just regular open source projects that are used by Android (or CyanogenMod) and just have the
Android.mk make files to work with the Android build system.
This refers to the core Android frameworks. It’s the stuff that makes Android, Android. The frameworks contain the Android user experience and the abstracted “hooks” that programmers use to build Android apps. So, for example, this folder contains the Java windows-manipulation and activity stuff and java sound support and Android graphics layers and Android media stuff and UI as well as services and basically the Android API in general. There are also some platform-specific optimization here as well that CyanogenMod adds for Qualcomm, OMAP, and other manufacturers to get the best performance out of specific architectures. This folder has many different parts, but if you want to play with the Android platform itself and its basic functionality, this is probably the place to look.
Platform/hardware-specific libraries and such go in this folder. For example, the code in
hardware/ti is used to support devices using a chipset by Texas Instruments.
kernel/ directories are organized like
kernel/<vendor>/<codename> and inside there you’ll find the source for the kernel. This source may be downloaded “on the fly” by the CyanogenMod build system. See the note in the
device/ section above about using the
breakfast command to auto-include a particular device’s
kernel/ directory when you
repo sync to auto-update the codebase.
See here. Tools for allowing cross-platform C code to be included in Android apps (as JNI shared libraries, apparently). Used if you’re writing C-based apps, but I’ve never used any of this or even poked my nose in there. See
/ndk/docs/OVERVIEW.html for more.
The output of your build will go in here by default. When you type
cd $OUT after building, you’re actually getting a shortcut to
out/target/product/<devicename>. This is the only folder that should have stuff added to it (or changed) when you’re doing a build. stuff that will become the system folder on your device goes in system. Stuff that will become your ramdisk goes in root. The various stages and temporary scripts used to create your
boot.img and your kernel go here as well. The object files get built into the
obj directory. And there are generic compiler tools and other build (such as from the ndk) and such that get built in
out/ as well. When you do a
make clobber, you’re just getting rid of
packages/apps/ is where Android standalone apps, such as the Settings app, the Browser, the Launcher (in CM10’s case it’s called Trebuchet), and other apps go. Note that many of these apps are integrated directly with functionality within the
frameworks/ directory. So the settings changed in the Settings app will correlate to stuff in the
frameworks/ folder. Non-app packages such as input methods and wallpapers go here as well.
These folders contain prebuilt toolchains for cross-compiling on linux and darwin (MacOS X) and a few tools for Windows. Cross-compiling allows you to build Android for an architecture (such as ARM-based CPU) from another architecture (such as x86_64).
Lower-level linuxy system stuff such as netd, fastboot support, the shell (which you can use to type commands into your device), etc. are here.
/vendor folder contains stuff particular to a vendor build such as CyanogenMod. It’s also the place where proprietary blobs are extracted from the device, again using the same vendor/device codename convention as under
Content of this page is based on informations from wiki.cyanogenmod.org, under CC BY-SA 3.0 licence.