Dealing With Build Errors

During a build, 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

But 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 files (and all the .mk files that those include, such as or 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/, 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 well 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.

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 so that it can be quickly incorporated into the build.


Content of this page is based on informations from, under CC BY-SA 3.0 licence.