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.
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.
First, initialize the tree with the 4.2.1_r1 AOSP manifest project, as per usual:
mkdir mako && cd !$ repo init -u https://android.googlesource.com/platform/manifest -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:
#!/bin/bash
#
# By Jameson Williams, modifications by Ben Weigand
#
blob_list_file=proprietary-blobs.txt
base_dir=proprietary
function die_on_err() {
$@
if [ $? -ne 0 ]; then
exit 0
fi
}
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.)
/system/etc/firmware/wcd9310/wcd9310_anc.bin /system/etc/firmware/wcd9310/wcd9310_mbhc.bin
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/full_mako.mk:
#PRODUCT_RESTRICT_VENDOR_FILES := true
Alright. You’re finally ready to build the image:
. build/envsetup.sh lunch full_mako-userdebug make -j10
Cool. So, now you see that there is a
$ANDROID_PRODUCT_OUT/system.img, the system
image.
Get the source:
mkdir -p ~/mako/kernel/lge && cd !$ git clone https://android.googlesource.com/kernel/msm -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/envsetup.sh 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.
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
AndroidKernel.mk 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://github.com/jamesonwilliams/platform_manifest.git -b android-4.2.1_r1 repo sync . build/envsetup.sh lunch full_mako-userdebug make -j10
After a while, you’ll see several partition files, including:
$ANDROID_PRODUCT_OUT/system.img $ANDROID_PRODUCT_OUT/boot.img
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
Neat.
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:
wget http://download2.clockworkmod.com/recoveries/recovery-clockwork-touch-6.0.2.3-mako.img fastboot boot recovery-clockwork-touch-6.0.2.3-mako.img # Optionally, actually install it # fastboot flash recovery recovery-clockwork-touch-6.0.2.3-mako.img
Now, just push the system and boot images:
fastboot flash boot boot.img fastboot flash system system.img fastboot continue
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 $ANDROID_PRODUCT_OUT/boot.img # The system image $ANDROID_PRODUCT_OUT/system.img # Default user data parition $ANDROID_PRODUCT_OUT/userdata.img # Google's recovery image $ANDROID_PRODUCT_OUT/recovery.img # And two more... I'm not sure what these ones are. $ANDROID_PRODUCT_OUT/ramdisk.img $ANDROID_PRODUCT_OUT/ramdisk-recovery.img
If you zip’d up the first four, you’d essentially have the image-occam-jop40d.zip 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 mako-4.2.1_r1-image.zip \
$ANDROID_PRODUCT_OUT/system.img \
$ANDROID_PRODUCT_OUT/boot.img \
$ANDROID_PRODUCT_OUT/userdata.img \
$ANDROID_PRODUCT_OUT/recovery.img \
$imaginary_path/android-info.txt
fastboot -w update mako-4.2.1_r1-image.zip
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:
# $ANDROID_PRODUCT_OUT/$TARGET_PRODUCT-img-eng.$USER.zip
So to deploy, you can simply:
make updatepackage fastboot -w update $ANDROID_PRODUCT_OUT/$TARGET_PRODUCT-img-eng.$USER.zip
There’s basically nothing installed, so you probably want to obtain the Google Apps, and install them via recovery update.zip. (Request for link: can you get these directly from Google and not “rootzwiki”?)
Happy hacking!
© 2013 nosemaj.org.
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.
/Bob
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?
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
I do as it ,and flash system system.img,but my phone can’t boot ,WTF!,what’s wrong with google?
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.
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:
https://developers.google.com/android/nexus/images#occam
The most recent image is ‘occam-jop40d-factory-ca7602f0.tgz’.
2) Grab a copy of the script ‘simg2img.py’, for unpacking system.img files. The source for this script can be found: http://code.google.com/p/usefulshellscript/source/browse/trunk/simg2img.py
Paste this into ‘simg2img.py’ 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/image-occam-jop40d.zip’ (or something similar)
5) Uncompress the system.img file into a normal ext4 disk image:
‘python simg2img.py 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).
Hi,
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.
@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.
Hello,
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?
Thank you Jameson, your repo is a great help and it works perfectly.
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!
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 http://forum.xda-developers.com/wiki/LG_Nexus_4 and flash it with fastboot flash modem radio-mako-m9615a-cefwmazm-2.0.1700.33.img
@Me, #12 Good info! I had someone contact me with a similar problem. I’ll update the document to include the recommendation.
@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.
Google has put the official binaries on the web. These should be all that’s needed to compile AOSP, shouldn’t it?
@Ableeker: No, you’re misunderstanding what compilation is. The official binaries are one possible set of outputs from the software compilation process.
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 https://developers.google.com/android/nexus/drivers.
So if I use the binaries and put them in the source code, I should be able to create a working build, right?
@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.
Hi!
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/common.mk (PRODUCT_COPY_FILES += ….) , but nothing was changed
Bye.