[HOWTO] Build CyanogenMod 11.0 for Nexus 7

11-5-13 -- See here for the start of the CM 11.0 (based on Android 4.4 KitKat) discussion.



7-27-13 --- See here for my build instructions for CyanogenMod 10.2 (based on AOSP 4.3)...

Hey all,

So I've ported my "Build CyanogenMod" instructions (Nook Color, Nook Tablet, and HP Touchpad) to the Nexus 7.

The doc basically covers unlocking the N7, getting the build environment ready, downloading source, building, installing, and updating the source. The walkthrough is for Linux, but you should be able to do it via a virtual machine running on OS X and Windows such as Virtualbox (free).

The idea is that building Android from scratch should be possible for almost anyone to learn. So this guide walks you through it.

If you're running into difficulties, this thread is a place to exchange info, tips, questions, etc.

It's also a good place to proclaim loud and clear to the world...

"I'm running an OS I built myself from source!"

Thanks to eyeballer for reviewing.

CyberCitizen said:

Sorry for my ignorance, but besides bragging rights, what is the whole point of self compiling stock cm10 for your device?

Click to expand...

Click to collapse

Off the top of my head...

• You never, ever have to wait for a nightly
• You can add or remove as-yet uncommitted features with ease.
• You learn how Android works under the hood
• You learn how to use Linux
• You'll learn how to use git
• You may, even accidentally, pick up a little C, Java, C++, and learn about the build system.
• You can personalize Android-- make your own tweaks, replace kernels, modules, graphics, add or remove projects, overclock, underclock etc. In other words, you have control over every aspect of your device's functionality. Your build is custom to you.
• You can audit the code for potential security issues such as back doors or trojans (as opposed to just trusting a random person who posts a build). Since CM10 source is open, you can examine every commit, and there are many eyes looking at the code. (does not apply to proprietary blobs, but these are pulled from your device, so you have and are using them already)
• You can contribute features/fixes back upstream
• You can start ports to other as-yet-unsupported devices (start by copying folders from similar devices to devices/manufacturer/model)
• You come to really understand that Android phones and tablets are full-fledged general-purpose computers just like laptops and desktops.
• AAAAND....you get huge bragging rights

The extent to which you delve into the above is entirely up to you. The walkthrough is just an introduction to that world. If N7 is anything like the NookColor/NookTablet/TouchPad, some people will build once and never do it again... but others will start to tinker and make changes to their own build and want to share them with others, and soon some will start making contributions back to official CM10 upstream... or port to new devices... and by fixing bugs and all this... everyone benefits.

Plus...

• It's fun.

ALSO: Here are some little bits that resulted from this thread:

• Dealing with build errors
• What's where in the CyanogenMod source folder
• A little about make clean and make clobber

Update: A lot of the above info, as well as much more original articles, can now be found on the CyanogenMod wiki. So check there, especially the dev center.

That's it! Happy building!
How to Build CM10.1 Instructions for the Nexus 7 (CM Wiki version)
Addendum for CyanogenMod 10.2

About the directories...

kirdroid said:

On my Ubuntu VM using 4 CPU's and 2GB ram, it took around hour. I have retina mbp with 16 gigs ram. I will probably increase the ram on my VM to 4 gigs and see if any improvements in build time.

Sent from my Nexus 7 using Tapatalk 2

---------- Post added at 06:39 PM ---------- Previous post was at 06:18 PM ----------

@fattire - How do I start looking at the CM source? I want to look at some code and try to understand. Is there some kind of tutorial on where to start for looking at the CM source?

Click to expand...

Click to collapse

Yeah, so a newer computer is definitely going to give you an advantage over an older one...

As for the cm source-- 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...

Again, I typed this quickly, so it's probably not as well said as it could be.

/bionic -- 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...

/build -- 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.

/bootable -- among other things, the source for clockworkmod recovery is in here.

/dalvik -- this 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.

/device -- all (okay, most of) the stuff that's particular to a unique device (a particular model of phone or tablet) is in the /device folder and is organized by /device/manufacturer/model. So the Nexus 7 is in device/asus/grouper, the NookColor is in device/bn/encore, the Nook Tablet is in device/bn/acclaim, the HP Touchpad is in device/hp/tenderloin, etc. 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. I could talk at length about just this folder-- xml files in device/hp/tenderloin/overlay, for example, will override system-wide settings in the frameworks folder, so you can customize Android to behave differently for this device than for any other...

/docs -- I've honestly never even looked in here before, but it looks like there may be more documentation on how stuff works. Jeesh i wish I knew about this before Read docs/source.android.com/README for instructions on how to make a directory full of .html docs that I haven't read.

/external -- 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 CM10) and just have the Android.mk make files to work with the Android build system.

/frameworks -- this refers to the Android java 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. Some of the .xml configuration and string files here may be overridden in the device/manufacturer/model/overlay section of the device.

/hardware -- lots of platform/hardware-specific libraries and such go in this folder. For example, the stuff in hardware/ti is used to support devices by Texas Instruments. There are folders for qualcomm devices, stuff for the radio interface layer (used by the phone), and the libhardware folder and more is here. If you're just starting to tinker with Android itself, you probably don't wanna mess with this.

/kernel -- like the device folder, the kernel folder is organized like kernel/manufacturer/device and inside there you'll find the source for the kernel. This source may be downloaded "on the fly" by the cyanogenmod build system.

/ndk -- 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.

/out -- the output of your build will go in here. 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 recovery.img and 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 whatever's in /out

/packages -- 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.

/prebuilt (and /prebuilts) -- these folders contain prebuilt toolchains for cross-compiling on linux and darwin (os x) and other specific OSes. If I'm not mistaken, CyanogenMod adds the prebuilts directory with newer compilers. Cross-compiling allows you to build Android for another architecture (such as ARM-based CPU) from a totally different computer (such as Intel).

/system -- lower-level linuxy system stuff such as netd, fastboot support, the shell, etc. are here. I'm not sure when something is promoted from /external to /system, but maybe more essential stuff goes here. Or maybe someone else can fill me in on this.

/vendor -- the vendor folder contains stuff particular to a vendor build such as cm. It's also the place where proprietary blobs are extracted from the device, again using the same manufacturer/device convention as in the device folder.

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 indicitive of what you'll find inside, and the best source of documentation is the code itself.

Good luck! I do invite anyone with corrections and additional insight/notes to let me know and I'll try to update the above.
ft

Finished 5 minutes ago... scroll down for walkthrough...



7-27-13 ---

BUILD INSTRUCTIONS FOR 10.2
By fattire

NOTE: This assumes you have built 10.1 for grouper previously and have a build tree available already. If not, follow the instructions in the wiki to get your 10.1 build going and become familiar with the process.



Other caveats (from early-morning build on 7/27/13. Probably outdated by now)

• No gapps included. Find for 4.3 on your own.
  [*] MTP doesn't seem to be working yet. Haven't looked into it yet, but something something is crashing when you try to access media storage over USB. No clue if this is something on the device, or something in the CM repo that may have been already fixed or what.
• The cm 10.2 tree is very active and things may break. If so, try repo syncing again in a few hours or check gerrit for possible fixes.
• Things that seem to work include bluetooth, wifi, backlight, accelerometer, camera, sound... nfc not tested.. other stuff not tested.
• While I am sharing the /device and /kernel tree I'm using, they may lead to all kinds of instability. Nothing is tested.
• Read the instructions fully before you consider building and make sure you understand what you're doing. Also, only follow these instructions if you're willing to fully break everything on your device. In other words, try at your own risk. Proceed at your own risk.

1. All these commands should be issued from the root of the source tree (~/android/system if you've used the wiki instructions). So cd to ~/android/system or type croot or do whatever you do to get to the source code's main directory.
   
   
2. Now re-initialize the repository to use the 10.2 source by typing this:
   
   $ repo init -u git://github.com/CyanogenMod/android.git -b cm-10.2
   
   
3. Make sure you remove any old local manifests for 10.1 by getting rid of .repo/local_manifest.xml and anything in the .repo/local_manifests directory that may not belong.
   
   
4. repo sync to get the source. (You may see some warnings about repositories that don't have cm-10.2 branches. Ignore them.)
   
   
5. While the source is loading, you can, from the main source directory, mv vendor ../vendor-old-10.1 to move the 10.1 vendor blobs out of the way. You can find the sparkling new blobs for grouper here. Download each of the .tgz files to the main source directory, ungzip/tar them to get the install .sh script. Then chmod a+x each shell script so they are easly runnable, run them from the Terminal (sh [filename].sh), agree to the terms by typing "I AGREE" and the blobs should automatically be placed in the vendor directory.
   
   
6. So now we'll assume the 10.2 source is all in place. You probably don't really need to do this again if you're re-using your source from 10.1, but just in case, cd ~/android/system/vendor/cm and then ./get_prebuilts.
   
   
7. Now to get the 10.2 grouper-specific stuff. Make sure you have entered source build/envsetup.sh to get the commands like brunch and breakfast. . I guess you should set everything up to use grouper starting with the official repo, which doesn't as of now even have a cm-10.2 branch. After that, we'll replace it with the VERY UNOFFICIAL repos that I am using. So start with breakfast grouper. After that does its stuff, change .repo/local_manifests/roomservice.xml to look like this:
   
   
   <?xml version="1.0" encoding="UTF-8"?>
   <manifest>
   <project name="fat-tire/android_device_asus_grouper" path="device/asus/grouper" remote="github" revision="cm-10.2" />
   <project name="fat-tire/android_kernel_asus_grouper" path="kernel/asus/grouper" remote="github" revision="cm-10.2" />
   </manifest>
   
   
   Again, the above are my personal repositories that I am using for testing.
   
   Update 8/12/13: The CM repositories now have the cm-10.2 stuff.
   
   * The /device tree is basically 10.1's device plus a bunch of cherry-picked stuff from AOSP 4.3, plus newer SELinux rules, plus my own minor changes.
   * The /kernel tree is currently AOSP 4.3 stock with a cyanogenmod_android_defconfig added. None of the customization from 10.1 are here yet.
   
   
8. Repo sync again to get my two repositories for the kernel/device. Then try brunch grouper and see what happens.

Again, good luck. Make sure you back up, and try at your own risk. My /device and /kernel stuff are probably not really up to par and I was gone all day and haven't really tested anything. This was a quick go to get it building, but I wanted to share it with everyone who might be interested.

I probably screwed up some of these instructions, since I haven't actually tried it beginning to end. So this is where YOU come in, to help each other. If you post corrections, I'll try to update the list above....

Cheers,

ft

CM 11.0 Build Instructions

Well folks, it's that time again. The new source for cm has dropped, and it's time for you adventurous folk to start 'abuilding.

Some tips, if you've built the latest CM already...

1. cd ~/android/system (or wherever your source is) then

repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0

2. check your .repo/local_manifests/roomservice.xml to make sure the following are there

<project name="CyanogenMod/android_device_asus_grouper" path="device/asus/grouper" remote="github" revision="cm-11.0"/>
<project name="CyanogenMod/android_kernel_asus_grouper" path="kernel/asus/grouper" remote="github" revision="cm-11.0"/>

The above should be set up when you do the "breakfast grouper" command as well. (I don't think the revision="cm-11.0" is necessary any more btw since that's the default branch you're on.)

3. the 4.4 binary blobs/proprietary files are available here.

4. repo sync to grab the new CM 10.4 source.

5. If you plan on using gapps for 4.4, I guess find those yourself.

6. DO NOT USE JAVA 1.7 if you want this to build. You need Java 1.6, preferably sun's. If you're using ubuntu, you can do this to select the default java:

sudo update-alternatives --config java

7. Then try brunch grouper and cross your fingers.

Also, if you follow this thread a few more steps, you'll see more build info, including some screenshots and a screencast from kitkat running on n7 2012

And finally, if you turn off the Dalvik VM and turn on the ART (Android Runtime) alternative-- you may have screwed up your device. Here's how to fix it.

make clobber, make clean, and make

leventccc said:

I have only 1 more question left thanks for answering all my questions quickly should i delete out folder everytime when I want to make a new build or can I just compile without cleaning old files?

Click to expand...

Click to collapse

If you want to do a start-everything-new build, first type

make clobber

and then this will remove all of $OUT so that a rebuild while re-create the whole thing from scratch. You might want to do this if changes are made to the BoardConfig.mk file in device/asus/grouper, for example. It's also not a bad idea to do a make clobber build every few weeks just to be absolutely sure everything is being built anew.

Most of the time, for incremental changes and whatnot, you just need to do a repo sync and then build again. The build system should notice which source files have changed and need rebuilding, and should only build the new stuff.

However, as i said above though, some Makefiles such as BoardConfig.mk may contain flags in it that actually affect the build system-wide, and the Makefile system doesn't really check the actual source code to see if a variable change in one place may affect the build in the code somewhere else. So a totally fresh make clobber build, which takes significantly longer than an incremental build, is the best way to be 100% sure you've got everything that's changed in the source code across every part of the system. For this reason, all nightlies posted by official CyanogenMod sources are "make clobber" builds.

There is also make clean, which is a less dramatic/complete way to clean your build. It doesn't kill all your output files, just intermediary files used by the build. Here is an explanation of the difference between make clean and make clobber. It recommends doing a make clean between all builds, although I haven't found that to be necessary for minor day-to-day builds. Although, in fairness, I generally make clobber about once a week anyway.

Hope this sufficiently answers your question.