Status 7 error: what’s the problem with Android OTA updates and how to fix it?

The latest Nexus devices are normally the first to receive the newest Android versions. When a new firmware version is ready for release to general public, its full image is located at Shortly after that, firmware starts to be distributed over the air. According to one of Google developers, Dan Morrill, (, the first few OTA updates are sent to 1 % of devices. It happens at random, regardless of the location or point of sale of a phone/tablet. During this time, bugs are identified allowing the updating process to be put on hold if any critical errors are registered with a large number of users.

After that over a couple of weeks, updating is provided to 25, 50, 100 % of users, i.e. at the initial stage only one device out of a hundred stands a chance of getting an upgrade. If the update is not received, the device drops from the list, and subsequent repeated clicking on the button ‘check for updates’ automatically sends the device to the bottom of the list. When a new stage of distribution starts, clicking on the button get a 25 % chance of receiving the update. Since the device checks for updates on its own once a day (upon reboot), clicking on the button might ‘jump the gun’ before it may run its course. But whatever the outcome, only one check will be made. Subsequent clicking will not help matters. This is not a situation where ‘first press, first receive’ (first come first serve). In any case, the over the air update will be available to everyone within a couple of weeks. The most impatient user could update their devices manually (some more details on that aspect are given below).

Notification of the update

Notification of the update

Force-marching the update

The updating process can be accelerated in two ways. The first one – clean data from the Google Services Framework and then reboot the device. This method is the one to be avoided [frown upon even by Google engineers] ( It causes many negative effects, the worst one being is the change of GCM identity (Google Cloud Messenger). This identifier is required in all Google and many other applications using the push notification feature. And while in some programs those effects can be remedied fairly easily, while in many others implications may be far more serious. All applications will just be unavailable for GCM-based push notifications until they have been provided with a new identifier. Some applications performs checks often, some don’t. For some applications data cleaning will help. And worst affected can be those applications that use GCM ID as an identifier on their servers.

Stock recovery

Stock recovery

The second is manual updating through the recovery console. Shortly after the launch of OTA files like appear in profiles at XDA and 4PDA with the file names featuring file hash, device brand and firmware versions involved in updating (original and updated ones). In their computers, the user has to keep a folder containing ADB and fastboot utility apps. I, for one, use the latest versions of Android SDK. The archive set the OTA-update should be placed in the same folder. Also, the user should have available properly installed drivers for devices that may conflict with previously installed drivers for other devices.

The device itself should be put in the recovery mode (recovery). To do that, you press the < Power + VolDown > buttons together on your deactivated device and get access into the boot loader selecting the Recovery mode with the volume button and get into it with the Power button. The Inactive Android sign followed by the exclamation mark will show up. Don’t be afraid, it is not a bug. Short-push < Power + VolUp > on the screen to download stock recovery. There you should select the ‘apply update from ADB’ on the menu list using the Volume buttons and validate using the Power button. Next, you hook up your phone/tablet with the computer. Let’s start the console, move over to the folder with ADB and the update archive and enter the following command (for the file above):

This will cause OTA to be installed on your phone and get it restarted.

How to download the update over the mobile network

Update notification can arrive when your device is not connected to Wi-Fi. In this case, the mark will appear that the file is available for download via Wi-Fi for a specified period (about a week), while the “Download” button itself will be disabled. It is all done to save the user’s money. If you are not going to connect to Wi-Fi in the near future, then you can deceive you handset by downloading the update via 3G/4G, putting back the date in your gadget in relation to the date indicated in the notification and restarting the device.

Modified firmware

If your boot loader is unlocked, you have customized recovery and root that actively uses various applications and various modifications have been made, then the likelihood of you failing get an update is 99 %. Even upon return of stock recovery, the Status 7 error will be flashed if the firmware is upgraded via ADB. Customized recovery will also signal an error rejecting modified files. This problem can be resolved by recovering the factory firmware in your Smartphone, but it is not our method. Let’s deal with it by picking at the update file, pinpointing and removing the stumbling block, using the largest Nexus 5 update from version 4.4.4 (KTU84P) to 5.0 (LRX21O) as an example.

Operation procedures

So, the update from 4.4.4 to 5.0 was the largest one with the archive weight reaching 491 MB. Nearly the entire code had been modified while Dalvik was replaced with ART. So what does the archive contain? As you can see in the ‘Archive Files updated to 5.0’ screen shot, the archive contains boot loader images (various sections) and META-INF directory, patch and system catalogs.

Archive files updated to 5.0

Archive files updated to 5.0

In order to minimize the amount of traffic and reduce the load on servers, as well as to cut the end-user costs the update is designed in such a fashion that files with massive changes or written from scratch are located in the system catalog and changed from the ground up. While files with a low percentage of changes by Google’s standards, rather than replaced, are patched, i.e. only parts of the code inside the file are modified. These files are located in the patch catalog and have r extension. This is clearly visible when you compare files in/system/bin and/patch/system/bin. In this case, the patch is created by bsdiff well known to UNIX geeks, allowing two binaries to be converted to delta (a file with a difference between files).

The magic is initiated by the updater script located in/META-INF/com/google/android. We’ll get a detailed view of it. The file weighs 463 Kb and contains code lines responsible for the OTA updating process (as a matter of fact, it is the scripting language Edify who interpreter is located in the same catalog and is named ‘update-binary’. – Editor’s note.). In our case, it has the following content. First, we install the section/system (fairly standard line for Linux, similar to those located in /etc/fstab):

Next, the script checks the device model and firmware version using the system variable read (please note that it does not take it from the file/system/build.prop file, and requests ‘recovery’ itself, therefore updates cannot be made through a customized recovery console, although it was possible to prior to 5.0). Here and further on ellipsis denote abbreviated lines:

As you can see above, the update will not be successfully installed onto a non-proprietary device, but it can be reloaded onto version 5.0. The script checks to see whether the firmware is authenticated by Google’s official keys (release-keys). This is what causes many users troubles. Next, we start checking for the availability and integrity of individual files using SHA-1 hash verification. For this purpose we need two features: sha1_check() that accepts the file name and hash as arguments and apply_patch_check() that accepts three arguments: file name and two hashes. The first one is simply used to verify file integrity, while the second one checks if the file is already patched. For simplicity’s sake, coded long hashes below have been replaced with ellipses:

Only two checks have been illustrated by way of example. In reality all files to be replaced or patched-change are checked. The code shows that the update will produce an error if, for example, the file/system/app/Drive.apk has been modified or extracted. Toward the end of the check, the script examines the kernel and available space in/system and radio:

Please subscribe to read full article

1 year

for only $5

With subscription you are free to read all of the materials of
Read more about the project

Please subscribe to view comments

Only subscribers can participate in the discussions. You may login in to your account or sign up to Hackmag and pay a subscription to access the discussions.