Downgrading the Nexus 7

After upgrading my Nexus 7 to Loliipop (5.0) I find that it is unusable due to lagging response times. I tried deleting the cache and other remedies I found online but nothing helped. It’s just too slow. I want to go back to KitKat (4.4.4). I found a few tutorials about downgrading that differ in a few details. Some are geared to Windows users, some are for Macs. For a number of reasons I want to do this on my Mac Mini. 

One of the issues to be considered is that the system images (the file package that updates the OS) come in various flavors: factory images and Over The Air (OTA) images.

The factory images are complete OS and firmware replacements, including boot loader, and the process will completely wipe all partitions on the device. With these, you have to unlock the boot loader but you can and should lock it later. Boot loaders, the software that loads the operating system when you power up the device, are normally locked into a read-only state to prevent downloaded malware from tampering with the OS loading process. Unlocking allows it to be replaced. When you flash a factory image you will lose all of your data on that device.

OTA images are either full replacement or incremental updates to the OS. The OTA images are OS replacements but do not wipe all partitions. Although the full packages are called OTA, they are not the same as the incremental OTA upgrades that got me to where I am now. You know, that process of pushing an upgrade Over The Air. Those incremental packages will only upgrade from one specific version to another as they only contain the differences between versions.

The full OTA images, by contrast, completely replace the OS. These are likely too big to use as true Over The Air upgrades but are fine for installing over USB. Note that while some data will survive this process, not all of it will. If there is anything you need to keep, back it up. Even with the backup you will likely lose some contextual data stored in OS directories that you might not have been aware of.

The full OTA images are recommended when you want to go to a particular version from any other version and when you have not flashed a custom build on the device. This is the option I would prefer to take. It is a simpler process than the factory image installation. I like simple.

Can I find the correct image for my device?

Download the Right Stuff

Both factory and OTA images are available at the Nexus Developer site:

On either page follow the link to the SDK platform tools and select “SDK Platform Tools for Mac”. This will download the most recent version of the tools. Unpack the downloaded zip file into an appropriate directory. For me that is ~/proj/Nexus7Downgrade. That leaves me with the directory ~/proj/Nexus7Downgrade/platform-tools which contains the fastboot and the adbprograms needed for the flashing process.

Which Image?

It turns out that I cannot find the correct OTA image for my device, the Nexus 7 2012 WiFi. In the Android vernacular, I need to find a “nakasi” image. Looking on both pages I found “nakasi” images on the factory image page but not on the OTA image page. I decided to restrict my search to the Nexus Developer site even though there are images available on other sites. So I guess I’ll be following the factory image process.

The available images cover the 4.x to 5.x versions. I need to go back to a 4.x version and it makes sense to get the highest 4.x version, 4.4.4 (KTU84P). This version includes an important SSL patch.

Download and unpack the image zip file into an appropriate folder. I chose to make it a sibling folder of the tools folder so that I can update each independently if I want to do this again six months from now. The resulting folder nakasi-ktu84p contains shell scripts, the bootloader image and the nakasi image.

The shell script will perform all the necessary flashing steps. It assumes the fastboot program is on the PATH and the image files are in the current directory. I don’t plan to use these programs often enough to put the PATH update in my login profile. So this means my process will start with opening a terminal window and entering these commands:

  • cd ~proj/Nexus7Downgrade/nakasi-ktu84p
  • export PATH=../platform-tools:$PATH

Now I am in the directory with the shell script and the image files and the PATH is updated to find the fastboot program. When I exit the shell the PATH update goes away.

But before I execute the script I have to setup the Nexus.

Setup the Nexus

In order for this process to work the Nexus must be prepared to be driven by commands issued from a USB connected computer (a Mac mini in my case). The Android term for this is USB debugging. To enable this open the Settings app and select Developer options. The Nexus must have had Developer options enabled first in order to see this option and this can be enabled through the Settings screens. Select the About tablet item and then press the Build number item 7 or 8 times until the Developer options are enabled. Return to the prior screen and select Developer options

Scrolling through the Developer options I marvel at all the things I could do if I were developing Android apps. But I ignore them as my task is to find the USB debugging option and turn it on. Now the device is ready to listen to a USB connected computer.

See this page for more details. It is written for App developers using the Android Studio but the section Set up Device for Development describes the setup for USB debugging. When using a Mac the setup is simply what I have outlined above.

Connecting the Device

When I plug the Nexus into my Mac mini I get the Android File Transfer app started on my Mac. Why? Oh yeah, I downloaded that app a few months ago to load music onto my phone. OK, so this is my last chance to copy out any data I might want to save. But no, I’m done with that. I quit the app. This app actually restarts and I quit it a few times before I realize that I should just leave it alone. I hope it doesn’t interfere with the flashing process.

Just to be sure the connection is established, in the Terminal window I set up earlier I enter the command:

$adb devices -l

The response is about starting up a daemon and it shows a list of all connected devices (but only one now) and their qualifiers. In my case I see product:nakasi model:Nexus_7 device:gouper and some device identifiers that I don’t care about because I have only one device connected. When I look in the nakasi-ktu84p folder on my Mac I see that the boot loader image file has the name grouper in it. This gives me a warm and cosy feeling that I have downloaded the right stuff.

Flashing the OS

So now I am ready to flash the KitKat OS onto my Nexus 7. According to the instructions I first need to restart the Nexus in fastboot mode using the command:

$ adb reboot bootloader

So it reboots to a bootloader screen. The next step is to unlock the boot loader. But I notice the script begins with the fastboot oem unlock command so I reason that the script will take care of this. Now I take the plunge:


But I get the message < waiting for any device > and my Mac mini is getting warm. What’s that sound? Oh the mini has a fan. When was the last time I heard that? Running top shows fast boot running at 96.3 cpu. WTF is this a spin loop? ctl-c that mother. Wait! That doesn’t work; it just respawns another fastboot. Kill it. No it respawns !@#$%! I give up and reboot the Mac.

What Went Wrong?

At this point there are only two things I can think of that might explain the failure to connect. One is that there may be a war between Android File Transfer and fastboot/adb. The other is that I may have not followed the instructions after the adb reboot bootloader command. Now that I think about it, I did not keep the Nexus at the boot loader screen, but let it reboot the OS. Why did I do that? That would probably put the device into the wrong state to complete the protocol. My bad. Let’s try again. But first, I should make sure that the Android File Transfer app is not interfering with the ADB protocol.

See my post Android File Transfer – Magic Begone!

Flashing Again

Now I set up a new terminal environment as described previously and issue the command:

$ adb reboot bootloader

This time I pay more attention. At the bottom of the screen in tiny letters it says lock state - locked. Last time I think I pressed the power button when I picked it up to read the tiny fonts and that caused the OS to load. This time I leave it alone and go back to my Mac terminal and type:


Now I get this draconian warning screen asking me if I really want to unlock the bootloader. It says to use the volume rocker to select Yes or No then press the power button to continue. The default is Yes so I press the power button. My Nexus has a flakey power button. Sometimes you have to wiggle it to get a response. I wiggle it to be sure. At first I don’t see any change and wonder if I have to press it again but then a few lines in teeny-tiny font show up in the top left corner of the screen, then disappear. Now at the bottom of the screen it says lock state - unlocked. For a minute or so it does nothing but then I can see it it rebooting.

The Welcome screen appears. Yay! I go through the new machine process. The tablet does not remember a thing about me, but that’s what a factory reset should do. I verify that the tablet is at Android 4.4.4. So now I have to reinstall the apps that I had on the device before the flash. But first it has about 30 updates it has to go through.

Locking the Bootloader

Now I have a fresh KitKat 4.4.4 system with all the apps up to date. The bootloader is still unlocked leaving me open to the possibility of malware modifying the bootloader so I need to lock it. As before I need to reboot to the bootloader environment:

$ adb reboot bootloader

The response is error: no devices/emulators found. Why? Oh yeah, I’ve got a fresh OS and Developer options is not enabled. That means no USB debugging and the ADB protocol will not work. So, I go to the Settings screen, select the About tablet item and then press the Build number item 7 or 8 times until the Developer options are enabled. Then back up to select Developer options and turn on USB debugging. Now I reissue the reboot command.

It reboots into fastboot mode and the lower left of the screen states load state - unlocked. The following command will lock it:

$ fastboot oem lock

The command response is (bootloader) Bootloader is locked now and the lower left of the Nexus screen now states load state - locked. All I have to do now is press the power button (the Start option is selected by default). Now I’m good.


I suppose if I had done a full OTA image flash instead of the factory image flash I wouldn’t have to reinstall everything but I couldn’t find an OTA image for my device. Except for one stupid mistake it was a fairly easy process. Having been through it I feel like I could repeat the process with another version in 15 minutes or so.

BTW amid all the updates and notifications it tells me that I need to upgrade to a new version of the OS, Lollipop 5.5.5. LOL. Fortunately it tells me I don’t have enough available memory to download it. I think I’ll keep it that way.

Leave a Reply

Your email address will not be published. Required fields are marked *