Howto Build Android AOSP for Google Nexus 4

January 12, 2013

Android AOSP Running on the Google (LG) Nexus 4

Update: this is no longer the preferred approach. Building for Android Jelly Bean MR2 (4.3) is covered here: Howto Build Android 4.3 for Nexus 4

There’s a lot of articles on the Internet saying that Nexus 4 (code named “mako”) isn’t supported in AOSP: Google “can’t comment“; and the factory images at a point had disappeared from Google’s website. (Update: factory images are back on the Google website.) True, maybe it’s not officially documented, but it’s pretty easy to build. All you need are some cajones. No I’m just kidding. It’s not bad.

Note: If you’ve never built an Android image before, start from the standard Google documentation, “Initializing a Build Environment.” Otherwise, keep reading.

General Notes

The mako target is present in Jelly Bean MR1 (4.2.1) so building the system image is exactly like building anything else. The kernel sources are not included apropos, but they are in the Qualcomm MSM repository referenced in Google’s “Building Kernels” documentation.

Building the Platform (“System”) Image

First, initialize the tree with the 4.2.1_r1 AOSP manifest project, as per usual:

mkdir mako && cd !$
repo init -u -b android-4.2.1_r1
repo sync -c -d

Now, you need to ensure you have copies of the proprietary files needed by the Nexus 4. The complete list is in proprietary-blobs.txt. You can either obtain them from somewhere (see further down this page), or if you have a working Nexus 4 on hand, you can copy them off the phone.

This script should work to copy most of the files from the phone:

# By Jameson Williams, modifications by Ben Weigand

function die_on_err() {
    if [ $? -ne 0 ]; then
        exit 0

while read item; do
    [ -z "$item" ] && continue # skip blank lines
    [[ "$item" == \#* ]] && continue # skip comments

    mkdir -p ${base_dir}$(dirname $item)
    die_on_err adb pull $item ${base_dir}$item
done < $blob_list_file

Note: that script has been checked in.

Note 2: Two files will fail to be copied, due to permissions. They’re in the vendor project I’ve created, but you’ll have to find another way to pull them off the phone (e.g. root the phone, and chmod them and their parent dirs.)


Then, you need to put them in the tree at vendor/lge/mako . For an example, checkout the (small, simple) vendor_lge_mako project I ganked (“forked” in github langauge) from @konstantinkeller.

To use these proprietary files, comment out this line in device/lge/mako/


Alright. You’re finally ready to build the image:

. build/
lunch full_mako-userdebug
make -j10

Cool. So, now you see that there is a $ANDROID_PRODUCT_OUT/system.img, the system image.

Build the Kernel

Get the source:

mkdir -p ~/mako/kernel/lge && cd !$
git clone -b android-msm-mako-3.4-jb-mr1 ~/mako/kernel/lge/mako
cd ~/mako/kernel/lge/mako

Setup your environment:

# Assume you still have build/ and lunch, if not, do it again.
export CROSS_COMPILE=arm-linux-androideabi-
export ARCH=arm
export SUBARCH=arm

Build the thing:

make mako_defconfig
make -j10

This builds a file at arch/arm/boot/zImage, which can be flashed with fastboot flash:raw boot.

But don’t; read the next section instead.

Bonus Points (Recommended Method): Building Everything Together

I offered the above information to talk about the problem, and the solution. But you don’t want to do all of that. So, I made a few *small* infrastructural patches, to enable single make call.

You’ll notice that the kernel project has an file, which probably does a better job of setting up and building the kernel than we have, above. So, let’s see if we can use it.

It’s also inconvenient to prepare the vendor directory more than once. So it’d be nice to include that, too.

The goal here is to simplify the checkout/build process, and generate all the files we want with one “make“.

There’s a few ways to skin a cat, but if you make a few changes to the manifest, kernel, and device projects, building becomes greatly simplified. Oh, and the vendor project.

A summary of these changes:

So, now you can just:

repo init -u git:// -b android-4.2.1_r1
repo sync
. build/
lunch full_mako-userdebug
make -j10

After a while, you’ll see several partition files, including:


Actually Deploying The Image

Note: My assumption is that you’re starting from a clean install of the Google Nexus 4 JOP4D (4.2.1) factory image. If you’re starting from something else, your mileage may (or may not) very. Anyway, my recommendation is to go back to that (just one time), with clean data and cache partitions, if you’ve received a 4.2.2 OTA for example. (At time of writing, 4.2.2 code for mako has not been published.)

But hey wow, the stuff we built actually works. In particular, try the kernel without flashing it, to build confidence:

adb reboot-bootloader
fastboot boot boot.img


Now, let’s actually install the stuff. I definitely recommend clearing data and cache partitions first. You can do this from CWM (Clockwork Mod) Recovery:

fastboot boot recovery-clockwork-touch-
# Optionally, actually install it 
# fastboot flash recovery recovery-clockwork-touch-

Now, just push the system and boot images:

fastboot flash boot boot.img
fastboot flash system system.img
fastboot continue

More Bonus Points (More Notes on Deploying)

If you inspect the output of the build, you’ll find a bunch image files, actually. Everything but the bootloader and radio, which are proprietary and need to be obtained directly from Google.

# The boot image

# The system image

# Default user data parition

# Google's recovery image

# And two more... I'm not sure what these ones are.

If you zip’d up the first four, you’d essentially have the file from Google’s factory image release. Although you’d be missing an android-info.txt file. Anyway, suppose you had it. You could then install it like they do:

zip \
    $ANDROID_PRODUCT_OUT/system.img \
    $ANDROID_PRODUCT_OUT/boot.img \
    $ANDROID_PRODUCT_OUT/userdata.img \
    $ANDROID_PRODUCT_OUT/recovery.img \

fastboot -w update

BUT WAIT. The Android Makefiles already do this for you (and probably do a better job.) Instead of doing a plain “make”, do:

make updatepackage

Oula. Lo, and behold, you get the zip file output at:


So to deploy, you can simply:

make updatepackage
fastboot -w update $ANDROID_PRODUCT_OUT/$TARGET_PRODUCT-img-eng.$

Next Steps

There’s basically nothing installed, so you probably want to obtain the Google Apps, and install them via recovery (Request for link: can you get these directly from Google and not “rootzwiki”?)

Happy hacking!


20 Responses to “Howto Build Android AOSP for Google Nexus 4”

  1. bob says:

    This is awsome, i got the n4 because i wanted to get into rom dev! But people keep telling me that i need to extact
    The properitery files/blobs from the phone, but i dont see a step 4 this?
    Did i get that wrong? I use a extract script when i build cm roms back in the days.

  2. Andrew says:

    I have followed building the android source to the t and when I flash it using flashbooot flash system system.img the phone wont boot past the google splash screen. Why?

  3. frank ferro says:

    I really want to start doing this. I’m not a noob. but I can’t figure out how to properly use adb I her it but don’t know how to write commands or where the files need to be placed. All I need is someone to visually site show me just once even through log me in or what ever. Of you ever got time hit me up

  4. yokuniasahi says:

    I do as it ,and flash system system.img,but my phone can’t boot ,WTF!,what’s wrong with google?

  5. Jameson says:

    Hey guys, @Bob was right, I forgot the “vendor proprietary blobs” step. It is only a little extra work.

    I have updated the document with information on that.

    It should work fine now.

  6. B Weigand says:

    Great write-up Jameson!

    One caveat, since I don’t necessarily trust downloading pre-packaged binaries from unknown sources (no matter how legit “rootzwiki” sounds); so let me add how I acquired some sweet google apps.

    1) Download the the factory image for the Nexus 4:

    The most recent image is ‘occam-jop40d-factory-ca7602f0.tgz’.

    2) Grab a copy of the script ‘’, for unpacking system.img files. The source for this script can be found:

    Paste this into ‘’ on your linux host (you will need linux file tools and ext4 support to use the script).

    3) Uncompress the factory image:
    ‘tar -xzf occam-jop40d-factory-ca7602f0.tgz’

    4) Extract the system.img file ‘unzip occam-jop40d/’ (or something similar)

    5) Uncompress the system.img file into a normal ext4 disk image:
    ‘python system.img’
    This will create an uncompressed ext4 volume ‘tmp.img’ in the same directory

    6) Mount this disk image:
    ‘sudo mount -t ext4 -o loop tmp.img somedir/’

    7) Your apk riches await you in ‘somedir/app/’, and you didn’t have to run a single untrusted binary (you can and should read the python script before you run it though).

  7. AJ says:

    I’m trying to build 4.2.2 for my nexus 4 but there is no device/leg/mako directory. Am I doing something wrong? Its my first time truing to build AOSP.

  8. Jameson says:

    @AJ hey, I looked the other night (briefly) at trying to build 4.2.2 for the Nexus 4, but as you note, the Device project has no android-4.2.2_r1 tag.

    So the best method for custom builds is still 4.2.1_r1 (or r1.2 as most “bleeding edge.”)

    My guess is that the device project will be tagged in the next couple days, but I couldn’t say for certain.

    It may also be possible to get 4.2.2 going without the tag, but the delta between 4.2.1 and 4.2.2 is so trivial that it doesn’t seem worth the research.

    All I can say is that it didn’t build, when I tried pulling the “master” devie revision against other 4.2.2 projects.

  9. DE says:

    I tried to build a Kernel for the Nexus 4 under Ubuntu,
    everything works fine, but when I run make -j4, it runs throw sometime. Then it stops suddenly and there is no zImage in arch/arm/boot. I also get a Warning:
    “fs/cifs/transport.c: In function ‘SendReceive2′:
    fs/cifs/transport.c:653:5: warning: ‘midQ’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    error, forbidden warning: transport.c:653″

    can someone help me?

  10. Vincent says:

    Thank you Jameson, your repo is a great help and it works perfectly.

  11. Me! says:

    Thank you for the guide, this is exactly what I needed!

    I just built 4.2.1 following the guide, and all seems to work, except screen auto rotation. I don’t even know where to begin on this one. Help!

  12. Me! says:

    Fixed it. It was a result of having the 4.2.2 modem/radio/baseband instead of the 4.2.1 version. It breaks the sensors.

    For anyone going from 4.2.2 to a custom 4.2.1, grab the JOP40D radio from and flash it with fastboot flash modem radio-mako-m9615a-cefwmazm-2.0.1700.33.img

  13. Jameson says:

    @Me, #12 Good info! I had someone contact me with a similar problem. I’ll update the document to include the recommendation.

  14. Bobby Tacofeet says:

    @B Weigand [#6]

    That’s a great idea, but I don’t think all the proprietary blobs are in the image from Google. For instance, I could not find /system/bin/PktRspTest (or about a half dozen others) in an image I just downloaded from Google. I can post a complete listing of files not found in Google’s image that are in Jameson’s forked list.

  15. ableeker says:

    Google has put the official binaries on the web. These should be all that’s needed to compile AOSP, shouldn’t it?

  16. Jameson says:

    @Ableeker: No, you’re misunderstanding what compilation is. The official binaries are one possible set of outputs from the software compilation process.

  17. ableeker says:

    I may have used an unclear term… I mean the drivers, the missing files that aren’t compiled, and are supplied by a number of manufacturers (not Google) as binary files. These files can be retrieved from the phone. They are called proprietary files on this page, and are listed in file proprietary-blobs.txt. The source code for the Nexus 4 was pulled for a time by Google, and then reappeared later. The binaries weren’t available either, and were absent even longer, but have recently reappeared as well, and can be found once again at
    So if I use the binaries and put them in the source code, I should be able to create a working build, right?

  18. Jameson says:

    @Ableeker Ah yes! Definitely. You mean to mount the Google provided image in loopback, and extract the files of interest. Sounds like a fine approach.

  19. Przemek says:


    How to add to sources, my own folder which contain my bin scripts? I need those scripts in my android application.

    I try to make changes in vendor/cm/config/ (PRODUCT_COPY_FILES += ….) , but nothing was changed


  20. carepack says:

    Hi There,

    thanks for this tutorial. There is one thing I want to know. The described way clones the google repo to your local harddisk. I want to fork the aosp sources for my device to my git and clone them from git to my hard disk. How do I get the sources to my git? Which repositories I have to fork? Thanks in advance!

Leave a Reply