Unlock and Root your Nexus device - Logically!

Unlock and Root
your Nexus Device - Logically!

Do you need to Root your Android Phone or Tablet? Read this for a simple How and Why of unlocking and rooting - but only for Google Nexus and other devices that are not restricted by their manufacturers.

The idea behind the magic


Be aware that unlocking and flashing software to your device will open the possibility of damage to, or destruction of, the device. In some cases the device manufacturer may consider your warranty to have been voided by your actions. Please make sure you try to understand what you are doing and be aware that there is always the possibility of bugs in the software and mistakes being made. In the worst cases the device may become Bricked or entirely destroyed. If you are not willing and able to accept these risks and the associated possibility of problems: I recommend you refrain from unlocking your device.

If you are a teenager and you want to try flashing a device that your parents gave you: I recommend that you purchase used devices from a flea market. This will allow you to gain some experience, probably destroying a few devices in the process, without getting into trouble.

Most of the documentation about Rooting an Android device revolves around the process of exploiting bugs in the OS to gain root privileges. Look around the web a bit and you will see that this can degenerate into a tedious and difficult exercise involving waving your arms around, typing magic incantations on your keyboard, running scary scripts downloaded from file sharing sites in far away lands - no fun at all for a rational person. This is the expected consequence of manufacturers selling devices without developer support.

Google does offer developer support for their Nexus family of Android reference devices. If you have a Nexus device your hair will not turn grey as you try to tinker with it.

In this article we will look specifically at the relatively simple Unlocking and Rooting of a Nexus device.


The unlock process simply involves sending the OEM Unlock message to the bootloader. As a security precaution Google has decided to code the bootloader to wipe the flash memory when it gets this message. As such you may need to complete a backup of any important information you may have on your device before you send the unlock message.

Once you have unlocked your device it will remain unlocked. You won't need to unlock it again unless you manually lock it first.


Rooting involves adding the Super User (su) binary to the OS. If you are already using Linux you probably know that the su command is used to allow a normal user to gain root user privileges. Android devices are basically small computers that are running Linux - but they ship without the su binary.

By default the system part of the operating system is mounted read-only by the OS. To write the su binary into the system folders we need to remount the filesystem as read-write - but we need root privilege to do that and, by default, we can't get it using the tools provided in the stock OS.

Fortunately we are blessed with a world full of intelligent and industrious people who have written open-source firmware. All we need to do is find what is known as a Recovery image in Android parlance. This image can be flashed to the device and the device can be told to boot into that image. The recovery image will then have full control over the available hardware. It can easily perform functions such as mounting a filesystem writing to it.

So let's get started:

Software to Download

Before you begin you will want to make sure you've collected the following packages:

Check the instructions on the Android.com SDK page to figure out which package you want to download and install on your system. At the minimum you will want to download and install the SDK Tools.

If you are using Microsoft Windows you will need to check the documentation from the manufacturer of your device. Follow the download and installation instructions for the Windows device drivers for your device.

When you get to the ClockworkMod RomManager page you will see a table with a list of devices on the left side. Find your device.

For most devices you will see links to normal and the Touch recovery firmware images. They all recognize the Volume up/down buttons to change selections and the power button to activate a menu item (if the buttons exist on the device.) The main difference between the two recovery images is that the Touch recovery can also recognize finger activity on the touch screen. Select one of the two recovery images from the table and download it.

Finally you will want to download the Superuser installation package (not the binary) for your device. In Theory you should follow the instructions listed here to find the appropriate package - but it's not always so simple. In any case, try this:

  • Click on the Download ROMs link for your device (still on the RomManager page of the ClockworkMod site.) This will bring you to a long page with links to all the various ROMs that are available for your device.
  • Go to the bottom of the page and you will find a link for the Superuser binaries that are available for your device. Click on that link.
  • Next, you will be looking at a list of Superuser downloads. All the downloads are all ZIP files. The one you want is a zip package that can be installed by the recovery firmware. Move your cursor over the Logo/Icon on the right side of the table to see the filename of the download in your status bar. The package files should have a name which is formatted like this: Superuser-x.x.x-<arch>-signed.zip. The x.x.x will be a version number, the <arch> will be the CPU architecture for your device.

    Select the Superuser Installation Package which corresponds to the Android version you are running and the CPU architecture for your device (If you are not sure which architecture you need I recommend getting some help.) Remember to pay attention to the notes that you find in the table and choose a package that is compatible with the version of Android you are using on your device.


So, you remember that I said In Theory you should follow the procedure listed above. In practice there are problems from time to time. I followed the above procedure exactly and got a Superuser package with a filename of Superuser-3.1.3-arm-signed.zip. I then followed all the steps documented below, loaded Titanium Backup from the Play Store and... it did not work. Titanium Backup reported that it was not able to gain root privileges.

Such problems do arise. The complexity of the software and the number of relevant variables virtually guarantees that such things happen fairly regularly. No biggie - we get used to these little interruptions in our work-flow. We learn to push through them by being systematic. We learn to resolve these problems by working step-by-step through the issues that constantly confront us as we try to move forward. Or we can just search the forums and find out how somebody else did it.

In this case I had just installed the stock Android 4.2.1 update from the Google Factory Images for Nexus Devices page. Out of curiosity I had been browsing file listings was aware that a special Superuser Installation Package had been released for another Nexus Device, the ASUS 7, which also uses an ARM CPU. As soon as I saw that the Superuser 3.1.3 binary was not working I thought "perhaps it's related to the changes in 4.2," and decided to try the ASUS 7 Superuser package.

Unfortunately I couldn't find it. I knew I had seen it somewhere but I couldn't remember where. Finally I clicked on the ClockworkMod link which is just above the Superuser Link on the RomManager page for the ASUS 7 and there it was: a fix which was written for Android 4.2. I downloaded the file, Superuser-jb-4.2-fixed2.zip, flashed it into my device and found that it works fine.

Why was this file not in the Superuser page? I'm guessing it's considered to be an untried bug-fix. Hopefully by the time you read this it will be posted in the Superuser package list.

Moving along

Now that you've found everything you need you can start unlocking your device. Of course the device will be wiped clean when you send the Unlock command. If you have important information on your device you will have to make sure you've backed-up that information.

Backup before Unlocking

If you have never before unlocked your device and have lots of information on it you will probably want to start with a full backup. The entire device memory will be wiped when you send the unlock command so you will want to take steps to ensure that you don't lose anything important.

In general it's not convenient to make an easy-to-use backup of an Android device which is not rooted (which is why you are reading this now, right?) The best advice that I can offer is simply this: Remember that the restore operation is far more important than the backup operation. While you are trying to figure out how you will backup your information you should spend more of your time thinking about how you will get the saved information back into your device after it has been wiped.

For this purpose the Google Cloud infrastructure can be very helpful. There are plenty of things you may not need to backup. These include your Google Contact List, your Google Calendar and the images from social networking sites like Google+, Flickr, Picasa, Twitter, Facebook, PInterest, etc. In fact, if you try to Zip your Android Data folder using a tool like ZArchiver, you will find that the photos that are cached from the social networking sites amount to a significant percentage of the overall backup operation.

That being said: Please do not rely too much on the cloud-based automated Android backup provided by Google. While this service is indeed very helpful there are many apps that do not interface with it for specific bits of information. Your Account ID's and Passwords, for example, are often not saved by many apps to the Google Cloud infrastructure. So, when you boot your device after wiping it, the Google Servers will automatically re-install your apps - but not the many bits of data that the apps did not save as part of the Cloud Backup Services.

There are many examples of missing details. Screenshots and other images that are taken when auto-upload to the cloud is disabled, for example, are lost during the wipe and can't be retrieved from the device.

Many apps save information to the filesystem but not to the Google Cloud. In some cases you know about these (such as when you make a backup of your Nova Launcher settings,) so you manually upload the file to your Google Drive or Dropbox account.

In other cases it's not so obvious. Some VOIP software, for example, allows you to save phone numbers to your contacts. It looks like the phone numbers are being added to the Google Contact information but, when you visit your Gmail account on the web, you can't see the information. That's because it's cached within the VOIP software and not actually written to your Google Contacts.

Another example is the file store for your Kindle for Android app. If you manually copy ebooks and other documents into your device they will not be backed-up in the Google infrastructure or the Amazon infrastructure. This makes perfect sense because the ebooks that you purchased are always available on the Amazon Cloud. After a wipe the Kindle for Android app will be restored from the Google Cloud - but the wipe removed all the documents that you manually loaded and there is no way to restore them if you don't have any other copies.

If your device is a phone you might want to take special steps to save your SMS messages and call logs. There are non-root apps in the app store that can do this for you. If you are using Fancy Widgets, Nova Launcher, etc., you will have spent a great deal of time setting up your environment - so you will want to use the Backup Settings features of these apps to save their settings. Note that the free versions of some of these apps do not support making backups of settings so you might want to purchase the paid versions to get the job done more easily.

All in all this will be a tedious exercise so be careful. Go through your app drawer systematically and keep written notes about how you plan to execute your Restore procedure. The first few times you wipe your device you will probably make a few mistakes (What? You lost your gold coins and high scores in Ski Safari?) Once you have a bit of practice under your belt you will be able to execute the process more smoothly.

Install the SDK Tools & Connect to your Device

Once you know you can safely erase everything on your device you will want to verify your ability to communicate with it. Again, you will need to install, at least, the Android SDK Tools. If you haven't already done so you can visit the Android developer web pages, here:


Follow the instructions to get everything working. You will be using the fastboot tool to lock and unlock the device and flash images. You will also be using the Android Debug Bridge (adb) tool to reboot into the bootloader and recovery firmware.

If you are using Linux this should be a fast and easy process as the necessary drivers are most likely already included in your distribution.

If you are using Windows you will be prompted about drivers. Follow the instructions from the manufacturer for your device. For example, if you have a Samsung Galaxy Nexus you will want to follow the instructions on the Samsung pages where you download the Samsung drivers.


Realistically most users these days will get the SDK tools working very quickly but it's not always going to be smooth sailing. Many Windows XP users will have to tinker a bit to get their drivers working properly, some users will mix-up their data-only cables with their regular and power-only cables and, unfortunately, there may be more complicated bumps in the road.

You will know you got things working reasonably well when you get an appropriate response, as shown below, to a command such as this one:

$ sudo adb devices
List of devices attached
0123123123123123        device

The device query will cause ADB to return a list of the Android devices that are currently connected to your PC. If your device is plugged into your computer and you don't see a device listed it indicates that, somewhere between your Device and your PC, there remains some problem. Start with the device and work your way to the PC:

  • Is the device configured for debugging? If not: Go to the Developer Options in the Settings app and enable debugging.
  • Can't find the Developer Options? Check the documentation to find out how to enable Developer Options for your device. In Android 4.2 it's done by visiting the SYSTEM: About Tablet page in the Settings app. Click seven times on the Build Number at the bottom of the page to activate the developer features.
  • Did you get a <waiting for device> message that just sat there? USB devices are often not directly accessible to normal users on a Linux system - you probably forgot to use the sudo command to gain root privilege for the operation.
  • Plug the device into your PC. You should see the debug mode icon in the notification bar of the device. You should also see some indication in your task tray (or other appropriate place for your OS) of a newly connected device.
  • If, after connecting your device to your PC, nothing happens on the device or the PC: I suggest you try another cable.
  • If you see the debug icon and/or the battery charge indicator on the device but no activity on the PC you probably have a problem with your drivers. However, there are many cables that are being made these days that have power wires but no data wires. Such "power only" wires are usually labeled but the labels can fall off fairly easily. Again: try another cable.
  • If Windows keeps asking about drivers and you keep installing them there may be a more difficult problem to solve. Search the web for information about removing all drivers so that you can try again. Search also for software tools that can help you clean-up unwanted registry entries.

If you have tried going through the more basic troubleshooting steps above and are still having trouble you may be looking at a more difficult problem. To resolve it you will need to search the net for helpful reference, procedure and solution information. Take the time to solve the problem systematically. Don't be impatient or careless as troubleshooting is all about working step-by-step through the many details.

Okay, so now that you can talk to your device the remaining steps are relatively simple and should not take much time:

Unlocking the Device

Once again the Unlock operation is very simple: Just send the message and the bootloader will do the work. Here's how:

  • The unlocking code is hidden in the bootloader. Most likely your device is generally booted into the Android OS. As such you will need to use ADB to tell the device to reboot into the bootloader, like this:
    $ sudo adb reboot-bootloader
    rebooting into bootloader...
    OKAY [  0.006s]
    finished. total time: 0.006s

  • Once the device boots into the bootloader you will see a green START arrow pointing at the power button. Now you can use the fastboot tool to send the unlock message:
    $ sudo fastboot oem unlock
    OKAY [  9.231s]
    finished. total time: 9.231s

    (In the text above you see that the operation took 9 seconds but, in fact, it was waiting for me to approve the unlock for most of that time.) After sending the unlock message you will see a confirmation screen on the device and three dots on your PC. Confirm on the device that you would like to proceed with the unlock operation by pressing the volume up and down buttons. Once you have selected your Yes or No answer you can press the power button to, as per your answer, either execute the approved unlock or cancel the operation.

  • After unlocking the device the bootloader will sit and wait for another command. If you want to proceed with the installation of the ClockworkMod recovery image you can skip this reboot-into-Android step. If you want to reboot your device at this point you need to tell it to reboot.

    One caution: if you reboot your device and enter your Google Account credentials immediately after unlocking/wiping the device the device will try to download apps and data off the Google Cloud. You will need a good network connection for this process to complete quickly. Still, your device might easily be busy for an hour or more:

    $ sudo fastboot reboot
    finished. total time: 0.005s

Rooting the Device

Rooting the device will involve only a few simple steps:

  • If your device is still running the bootloader (ie: because you just finished unlocking your device device,) you can skip this step.

    If you unlocked and rebooted your phone into the Android OS you will not be able to talk to it until you enable debugging again. Do that first (see Connect to your Device above.) If you are in the Android OS and have just re-enabled debugging you can use the opportunity to copy your Superuser Installation Package into your device (which is otherwise the step after the next one.)

    So, if your device is not running the bootloader firmware you need to get it there before you can flash the new recovery firmware. This is done with the same reboot into the bootloader command that we used when unlocking the bootloader:

    $ sudo adb reboot-bootloader
    rebooting into bootloader...
    OKAY [  0.006s]
    finished. total time: 0.006s
  • At this point we can flash the ClockworkMod Recovery Image. For this purpose you will use the fastboot utility. Change to the directory where you've downloaded your recovery image. Please do not copy and paste the command below; replace the recovery image name below with the name of the image for your device. The resulting command and output will look something like this:
    $ sudo fastboot flash recovery recovery-clockwork-touch-
    sending 'recovery' (5990 KB)...
    OKAY [  0.733s]
    writing 'recovery'...
    OKAY [  0.819s]
    finished. total time: 1.552s
    rebooting into bootloader...
    OKAY [  0.006s]
    finished. total time: 0.006s
  • Next, if you have not done so already, copy the Superuser package into the device. This will allow us, later, to boot into the Recovery firmware to install the package. If your device has a MicroSD card slot you can go ahead and insert an SD card with the Superuser zip file on it. Otherwise you will need to perform the following few steps:
    • If the device is still in the bootloader you will need to reboot back into the Android OS. Use fastboot as follows (or use the power button on the device.)
      $ sudo fastboot reboot
      finished. total time: 0.005s
    • Next, copy the Superuser package to the device. The device that I used has a folder called /sdcard/ but your device might have a slightly different name. Just to be safe, you can have a look at the /sdcard/ folder to see what's there: [azer@ibm backup-gnex]$ sudo fastboot reboot rebooting...
      $ sudo adb shell ls -l /sdcard/
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Alarms
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Android
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 DCIM
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Download
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Movies
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Music
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Notifications
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Pictures
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Podcasts
      drwxrwxr-x root     sdcard_rw          2012-12-04 01:53 Ringtones

      If you see an error message because the folder you specified does not exist, you will want to use adb to shell into the device and look around until you find the name of the SD Card folder. If you prefer to use a GUI you can try the ES File Explorer or the File Manager to find the path name that you need.

      As the above directory listing looks good to me I'll go ahead and put the Superuser package there:

      $ sudo adb push Superuser-3.1.3-arm-signed.zip /sdcard/
      $ sudo adb push Superuser-jb-4.2-fixed2.zip /sdcard/
      4035 KB/s (1324669 bytes in 0.320s)
  • Now we can reboot into the ClockworkMod Recovery firmware to flash the Superuser package, like this:
    $ sudo adb reboot recovery
  • When the Recovery firmware boots you will see a menu with a number of options. Select Install zip from sdcard. If you are using the Touch recovery the screen will flash quickly but your finger may have clicked on the wrong item. Verify that, after touching the screen, the title of the page now reads, Apply update from .zip file on SD Card.. If it does not you can click the Go Back option at the bottom of the page and try again.

  • Select Choose zip from sdcard. This will bring you to a super simple file browser. Yes, it does look strange, doesn't it? In the directory listing that we made a few minutes ago we saw a few directories in /sdcard/. Now that we are browsing with the recovery firmware we see a few strange folders like 0/ and legacy/. What's going on? The recovery firmware is mounting the filesystem in a way that is slightly different from the Android OS. The difference is relatively minor - just rummage around a bit until you find the Superuser binary and click on it. In my device it is in the folder called /sdcard/0/.

    This brings us to a confirmation screen. The page is full of NO response lines; there is one YES response line that, when clicked, will install the contents of the zip file to the locations specified in the manifest within the file. Select Yes to proceed or No to stop the process.

    Finally ClockworkMod will open the zip file and perform the installation. You will see a log of the activity as it progresses (which only takes a second or two.) Then ClockworkMod waits for you to continue.

  • Click on the Go back option from the top of the menu. Then click Reboot system now.

Congratulations, your device is rooted! Now you can run software like Titanium Backup with root privileges.