[HOWTO] Build CyanogenMod 11.0 for Nexus 7

Search This thread

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
On blobs...

Edit: got it from a stock rom I guess this is cause I'm using EOS build.

Not sure if this is your issue, but the google-provided blobs don't give you all the props that you have on the device. Any build using only google's props may be missing funcitonality like camera and possibly some other stuff. To get all the props you must pull them from your stock device (or the factory image, I assume) using the extract-files.sh and setup-makefiles.sh scripts.
 

Rafase282

Senior Member
Oct 25, 2006
1,573
326
Bronx
I will try to go to stock rooted them. Either way I'm still unable to build and I still don't know why the computer shutdown, is it over heat or what?
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
The whole computer just shut down... as it restarted? Do you mean the vm or the whole machine?

It shouldn't do that. Sounds like overheating or hardware failure or something... what OS?
 
  • Like
Reactions: rocky12345678900

Rafase282

Senior Member
Oct 25, 2006
1,573
326
Bronx
The whole computer just shut down... as it restarted? Do you mean the vm or the whole machine?

It shouldn't do that. Sounds like overheating or hardware failure or something... what OS?

Ubuntu 12.04 64 bits Desktop 6 cores amd/ati 16 gb ram

The whole machine would shutdown. It doesn't always do it. But since yesterday it has been 3 times when trying to build.

host Executable: rsg-generator (out/host/linux-x86/obj/EXECUTABLES/rsg-generator_intermediates/rsg-generator)
out/host/linux-x86/obj/EXECUTABLES/rsg-generator_intermediates/rsg_generator.o: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [out/host/linux-x86/obj/EXECUTABLES/rsg-generator_intermediates/rsg-generator] Error 1
make: *** Waiting for unfinished jobs....
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Kernel panic maybe? Are you overclocking? Use something like gkrellm to monitor the system before it goes down and check the logs after you reboot...
 

Rafase282

Senior Member
Oct 25, 2006
1,573
326
Bronx
Still a no go. I'm not getting the shutdown, it is very random i guess. But I still cant compile. I used the stock image to get the files but still no build.

Also the first error I notice is the src directory not found.
 

Valkyrie743

Senior Member
Nov 19, 2011
290
43
i know this is a random question but i have downloaded one of the official nightly builds off of cyanogenmod's site.

i want to know how to disable the software key fuction of holding the home key bringing up the recents app menu. im trying to use google now but it keeps bringing up recent apps menu and its driving me insane
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
i know this is a random question but i have downloaded one of the official nightly builds off of cyanogenmod's site.

i want to know how to disable the software key fuction of holding the home key bringing up the recents app menu. im trying to use google now but it keeps bringing up recent apps menu and its driving me insane

To use google now, I believe if you simply swipe up from the apps icon to the "google" icon which will appear, that should take you to google now.

As for two posts up, your computer should NEVER just shut down spontaneously. Can you do a memtest or stress test (download and run mprime's stress test) and see if you have bad memory or perhaps a bad cpu?
 

rsxtypes72

Senior Member
Mar 14, 2009
224
25
Not sure if this is your issue, but the google-provided blobs don't give you all the props that you have on the device. Any build using only google's props may be missing funcitonality like camera and possibly some other stuff. To get all the props you must pull them from your stock device (or the factory image, I assume) using the extract-files.sh and setup-makefiles.sh scripts.

This is correct. I have been compiling AOSP for my GN and for the N7 and on the N7 the camera and gyro did not work on my builds. I figured out how to get the camera working but still need to extract files for gyro fix. I have compiled CM9 in the past but still haven't tried CM10.

Sent from my Galaxy Nexus
 

dsuycott

Senior Member
Aug 10, 2010
203
16
evanston, il
uhg...have everything downloaded and running on VBox/Linux on a Win7 Compaq 6910p 2Ghz duo 2gig ram @32bit...sluggy(ish) but working...i have another one of these laptops with a dead drive, i think i'm just going to buy a 500gb SSD/Hybrid and install just Ubuntu on it. regardless, very exciting thread! will there be a Q&A thread started for this or is this going to be it?
 

gigoo25

Senior Member
Jul 29, 2009
199
256
Hmm I have followed your guide carefully I seemed to be able to sync the repos and all the code but when I try to compile it gives me an error of not finding the "src" file or directory. The compiling process seems to keep going but does not completely finish and in my out folder I do not have any .zip files. Any help would be greatly appreciated! Thanks in advanced :)
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
build log, please?

Hmm I have followed your guide carefully I seemed to be able to sync the repos and all the code but when I try to compile it gives me an error of not finding the "src" file or directory. The compiling process seems to keep going but does not completely finish and in my out folder I do not have any .zip files. Any help would be greatly appreciated! Thanks in advanced :)

Can you paste a bit of your log to pastebin.com and provide the link...? I'm not sure which project is missing a src directory (usually it's Android java apps that have a /src directory, fwiw) Also, try to repo sync and then build again just to make sure it wasn't a momentary break in the source upstream (that hopefully, if it was the case, has been fixed)...
 

gigoo25

Senior Member
Jul 29, 2009
199
256
Can you paste a bit of your log to pastebin.com and provide the link...? I'm not sure which project is missing a src directory (usually it's Android java apps that have a /src directory, fwiw) Also, try to repo sync and then build again just to make sure it wasn't a momentary break in the source upstream (that hopefully, if it was the case, has been fixed)...

Thank you for the reply :) I have sync the repo once again as you will see in the pastebin link that I will post, it seems to complete just fine. Here is the link to the pastebin http://pastebin.com/P9XVLGwi also after it gives me a bunch of

frameworks/base/core/res/res/values/public.xml:####: warning: No comment for public symbol android:(with different results where the red text is)

P.S. Not sure if this matter but I am running on Ubuntu 11.10 JDK 6 on virtual box 8GB RAM and 6 Cores Dedicated
 
Last edited:

CyberCitizen

Senior Member
Jul 15, 2012
74
7
Sorry for my ignorance, but besides bragging rights, what is the whole point of self compiling stock cm10 for your device?

Sent from my Nexus 7 using xda app-developers app
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
On errors...

Thank you for the reply :) I have sync the repo once again as you will see in the pastebin link that I will post, it seems to complete just fine. Here is the link to the pastebin http://pastebin.com/P9XVLGwi also after it gives me a bunch of

frameworks/base/core/res/res/values/public.xml:####: warning: No comment for public symbol android:(with different results where the red text is)

P.S. Not sure if this matter but I am running on Ubuntu 11.10 JDK 6 on virtual box 8GB RAM and 6 Cores Dedicated

That actually looks okay... does the build continue or does it stop? If it continues, it's normal to see the occasional warning pop by... let it go all the way to the end and see if you get a cm-[whatever].zip file :) If it stops generally you get a message at the end that says something about an error, and then if you scroll up (or do a reverse-search for "error" from the end), you'll get the actual line that causes the error.

I usually run into one of four types of errors, although there are more:

  1. A missing file error -- when the build first starts, the build system takes a look at all Android.mk files (and all the .mk files that those include, such as cm.mk or BoardConfig.mk). These Makefiles contain info about each of the projects ("modules") that are going to be built. Some of these files, such as device/asus/grouper/device.mk, specify that as part of the build, certain non-compiled or pre-compiled files such as .gifs or binary blobs should be directly copied to a directory in $OUT (the target directory where the build goes). If the build system can't find the file, you'll get an error, usually really early because this stuff usually happens before other stuff is compiled. The solution is to find the missing file and supply it.
  2. An error in the build system itself (as opposed to the code once the compiling starts)-- sometimes (very rarely) there are syntax errors in the .mk file itself... usually this type of error will occur very very early in the build, and you can get a clue of what's wrong from the error. If it's not a typo, it could be a missing build tool on your system, but the errors are usually pretty helpful in indicating the issue. If you don't know what's up, someone in the forum or on IRC can generally help. Also, if you type git log from within the directory, you can see a list of all the changes that have been made recently to the repository. If you say git show [LONGSTRINGIDOFTHECOMMIT], it will show you what changed recently. This can help figure what the deal is.
  3. a code-related error that happens during the build. This is the bulk of errors. Programming errors and such that happen as the build is going. Syntax errors and that kind of thing. The problem might be in a Java (.java) file, or in a C (.c) file, or in a C++ (.cpp) file or a header (.h) or whatever. This is just a regular building bug that needs to be fixed in the code, and may require some programming knowledge, although simple typos and such can be figured out just by looking at surrounding code. The error usually says something like "error 1" and then you have to scroll back (do a reverse-search if you can) for the word "error", which should then show you the exact file and line # containing the error as long as a description of what the error is. This is your basic programming issue and not an Android specific thing.
  4. linking error-- sometimes the files themselves compile fine, but there's a linking error when various constituent files are combined together to create one binary (which may be an executable or a library or whatever). Sometimes this is the hardest one to solve, but again, people in the forums can usually help. Errors like this usually appear at the end when something depends on something you've built previously, but it doesn't work right. And again, this is nothing specific to Android. It's a basic programming thing.

I should say that unless you're doing your own hackery, 99% of the time you do a repo sync and build a fresh version, the system will be stable and there shouldn't be any show-stopping errors that halt the build-- code usually isn't checked into upstream unless it's been thoroughly tested. That said, sometimes bugs sneak in, especially in the days following a Google code drop. So if you find a bug and are able to fix it, be sure to submit the fix back to review.cyanogenmod.com so that it can be quickly incorporated into the build.
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Why in the world would you ever do this?

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

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 any-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 the individual. The walkthrough is 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.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 199
    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.

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

    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:


    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
    41
    About the directories...

    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?

    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 :p 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
    21
    Finished 5 minutes ago... scroll down for walkthrough...

    RnlV5WAl.jpg


    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
    18
    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.
    16
    make clobber, make clean, and make

    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?

    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.