As we all know, in Android system, APP upgrade or OTA package upgrade, we download the completed file from the background. After the download, we will check whether the file is downloaded properly and whether there is an error in the middle by checking whether the md5 and byte size match the package hung in the background server.
if the download is normal, we will go to the upgrade process; If download error, will go to delete the wrong file, download again.
general file download data error may be due to the network outage, re-breakpoint when the continuation of the cause.
Recently encountered a very tricky question,
phenomenon described as follows: the OTA updates after the download is complete, has passed the md5 check and file byte size, confirm the identity of the package and server backstage netting, software validation is completed, will soon enter the 5 s countdown prompt the user system update, at this time in the countdown screen immediately for manual power Android devices, the Android system reboot into recovery to upgrade, you will be prompted to upgrade package data corruption error; However, if the upgrade package is downloaded and the software is verified and passed, the power will be turned off again after a while, and the upgrade will be resumed normally.

Opening update package...
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys
Verifying update package...
E:footer is wrong
I:verify_file returned 1
E:signature verification failed
Installation aborted.

After communicating with colleagues who are maintaining Recovery, they said that this situation is usually caused by corrupted data of the downloaded upgrade package, or the file to be upgraded is not the upgrade package, which leads to Footer is wrong.
When checking this problem, the log found that both MD5 and file size verification of OTA upgrade package downloaded were correct. How could the packet be abnormal when upgrading after fast power failure?
but when the recovery report data is damaged, the data size of the upgrade package is indeed several M smaller than that of the complete upgrade package in the background. Moreover, the faster the power failure is after verification, the larger the difference between the upgrade package and the complete upgrade package will be in the next upgrade. If the power failure is slower, the difference will be smaller.

1. The upgrade package was not downloaded before power failure;
2. The download was completed before power off, and the packet was read and written again before power on and upgrade, resulting in data error.

immediately after the download of the upgrade package, the permission of the upgrade package is changed to ro read-only to see if the upgrade can be successful.
can be successfully upgraded, indicating that the upgrade package has been downloaded before the power failure is confirmed. Otherwise, it is concluded that the upgrade package data has not been downloaded.

download upgrade package after completion, upgrade package directory through ls-l command to see the file size is right, originally wanted to manually upgrade package permission chmod 400 *.zip, but found that the file operation is not, more weird;
power off, power on and upgrade through the upgrade package directory to see that there is still a few M missing.
can’t change the upgrade package property to read only.
How possible, clearly a file has been downloaded, and checked, boot after you said that the file is damaged, faint ~
After communication with colleagues, hold on, there is another possibility, even though the download is complete, although it’s been md5 checksum, although also match the file size, but through the command to read or software calibration data is not completely synchronized to the flash, because the data loss is related to the speed of power, haha ~
thought of this, the feeling is probably like this.
experiment immediately, before power off, manually execute sync command, found that the packet is normal after startup,
and sync action after completion, chmod 400 *.zip changed to read-only action can also be executed, it seems that the system did not fully synchronize the data to flash, at this time we are not allowed to change the file permissions.
experiments, found that all normal. I’m so excited
Finally, the software added protection for this situation,
after the file verification was completed, added the action of sync, which fixed this weird problem.