OTA upgrade FAQ

Problem phenomenon : During the OTA upgrade test, the upgrade package was downloaded successfully. After clicking Update Now, the mobile phone kept prompting "Updating" and failed to restart to upgrade.

Problem analysis : After analysis, it is found that because the OTA application does not have system permissions. As a result, it cannot create a command file in the directory /cache/recovery and write commands in the file, so that the OTA application cannot restart the machine and enter the recovery mode in this predetermined way, and cannot achieve normal OTA upgrade.

Solution : By adding the mkdircache/recovery command to the init.rc file, make the directory have write permission by default to ensure that the OTA application can perform the system upgrade normally.

Problem phenomenon : After downloading the upgrade package, when entering the recovery mode to upgrade, the system prompts that the upgrade failed, and the mobile phone cannot be upgraded successfully.

Problem analysis : By analyzing the log, the upgrade failure is caused by the failure to pass the verification when verifying the system files . Tracking the compilation process, it is found that the generated version file is inconsistent with the directory file used to generate the OTA upgrade package. The root cause is that many modules are recompiled in the process of compiling the object file after the version file is generated. As a result, there are different files in the version file and the target file. As a result, the upgrade cannot be upgraded normally due to the verification failure.

Solution : In this case, after compiling the target file, repackage the generated version file to solve the problem of inconsistency between the two.

Problem phenomenon : The differential package signature verification fails, and an error message is displayed: signature verification failed, Installation aborted.

Solution : (there are three cases):

1. The differential package signature is inconsistent with the signature in the version. The development stream version uses Google's native signature, so the differential package must also be used

Google native signature. The integration flow and release flow versions use company signatures, so differential packages must also use company signatures.

2.   When the differential package is imported to the  SD card, sometimes the import fails. The reason is that it is seen from the command prompt that the import has been successful. In fact, part of the data of the differential package is still in the cache and has not been fully imported into the  SD card, so it will appear The data of the  SD card is incomplete and the verification fails. Solution: After importing the upgrade package (update.zip package ) into the  SD card, you need to execute  adb shell sync .

3. During the process of making the differential package, the compressed file of the differential package is damaged and the CRC check fails. Verification method: Decompress the differential packet, and it will prompt that the decompression fails. The normal differential packet should be able to be decompressed normally.

Problem phenomenon : The upgrade process fails, and an error message is reported: assert failed: getprop("ro.product.device")

Problem analysis : Since ro.product.device needs to be verified during the upgrade process, if the value of this attribute is modified in the new version, when using the forward version to upgrade, because the ro.product.device is inconsistent, the upgrade will cause the upgrade to consider the machine phone The upgrade failed due to different types.

Solution : Block the script statement of assert(getprop("ro.product.device").

Problem phenomenon : The version number does not correspond, and the error message is: assertfailed: file_getprop("/system/build.prop", "ro.build.fingerprint")

Problem analysis : Since the differential package is upgraded based on the difference between the two versions before and after, if the source version used does not correspond, the differential package will not match and the upgrade will fail.

Solution : Enter the system settings, check whether the mobile phone version corresponds to the ro.build.fingerprint of the differential package, and then use the correct version to upgrade.

Problem phenomenon : The version file is manually modified, and an error message is reported: script aborted: assert failed: apply_patch_check

Analysis of the problem : Maybe the developers or pilots have obtained root permissions on the source version and modified the files in the mobile phone, and these files will be upgraded during the upgrade, and the upgrade of the modified files will fail.

Solution : Compare all files in the system directory of the mobile phone version with the files in the source version package used to make the differential package, and find out why the file is modified. If it is a version integration problem, you need to recompile the version.

Problem phenomenon : The cache partition space is insufficient, and an error message is displayed: scriptaborted: assert failed: apply_patch_space

Analysis of the problem : During the upgrade of the differential package, the files that need to be differentially packaged need to be placed under the  cache partition . If the maximum file size to be differentiated is greater than the maximum size of the cache partition, the upgrade will fail because it cannot be placed.

Solution : Check the following statement in the updater-script script in the differential package: assert(apply_patch_space(number)), by calculating the cache partition capacity <number>, it is because a modified file in the version is very large, the large file Generally, it is the iso image in the version, so if the product is mass-produced in the project, it is not allowed to modify the iso image.

Problem phenomenon : The kernel upgrade fails, and an error message is reported: scriptaborted: assert failed: apply_patch("EMMC:…

Problem analysis : Kernel upgrades may fail in many cases:

1. If the starting address of the kernel is modified in the version, the sha verification of the produced differential packet will fail when verifying the kernel.

2. When making a differential package, if you need to upgrade the modem file, the correct sequence is to make the differential package and the whole package on the AP side first, then put the MP side file to be upgraded in, and then sign. If the order is reversed: if you place the files on the MP side first, and then make the differential package and the whole package on the AP side, this will also cause the kernel upgrade to fail.

Solution : For the first case, the differential form cannot be used for the kernel, but the overall form should be used to upgrade, that is, the apply_patch statement of the kernel should be removed, and the following method should be used. emmc file system: package_extract_file("boot.img","/dev/block/mmcblk0p8") or MTD file system: assert(package_extract_file("boot.img","/tmp/boot.img"),write_raw_image("/ tmp/boot.img","boot"),delete("/tmp/boot.img"));

Symptom : When upgrading boot.img, after removing the battery and restarting, it will always enter the recovery mode and cannot be upgraded normally.

Problem analysis : Since the differential package needs to be verified during the upgrade process, the power outage will cause the differential package and the source file to be mismatched and the upgrade will fail.

Solution : Prompt the user not to remove the battery during the upgrade, or use the whole package upgrade instead of the differential upgrade package.


Problem phenomenon: The MTP method does not insert the T card to upgrade the problem (the android4.4 system only has this problem)

solution:  

当MTK_2SDCARD_SWAP == yes

The external sd card is the main card, insert the external sd card to download the ota package to the external card, unplug the sd card and download it to the built-in sd card.
The built-in T card in MTP mode is actually the DATA area, so after restarting, it will prompt that the SD card cannot be detected.
Need to modify the update package path, change /sdcard to /data/media, recovery.cpp file main function
char *inPath = NULL;
if (update_package) {
inPath = (char*)malloc(strlen(update_package)+sizeof(char) * 5);
memset(inPath, 0, strlen(update_package)+sizeof(char) * 5);
if (strncmp(update_package, "/sdcard", 7) == 0) {
if (ensure_path_mounted(update_package) != 0 ) {
strcat(inPath, "/data/media");
strcat(inPath, update_package + sizeof(char) * 7);
if (ensure_path_mounted(inPath) == 0) {
update_package = inPath;
                }
LOGI("Change mount path to:%s\n", update_package);
            }
        }
}
2.2 When MTK_2SDCARD_SWAP == no
, the built-in sd card is the main card, and the ota package is downloaded to the built-in sd card whether the external sd card is inserted or not.
The path of the built-in sd card is no longer /data/media, which is determined after viewing it through adb shell, for example: /data/media/0.
strcat(inPath, "/data/media"); changed to --> strcat(inPath, "/data/media/0");

Problem phenomenon: Some apks are lost after OTA upgrade
Problem description:
Restore factory settings in the current version, After upgrading to the next version via OTA, the desktop shortcuts of some applications cannot be opened and the application cannot be found in the main menu.
Do not restore the factory settings in the current version, upgrade to the next version through OTA, and check that the application is running normally.
Analysis of the problem:
Analyze the lost applications as third-party apks updated between the two versions, because the names of these apks have changed, and most of the names have information such as the version number and date. The way to update is to delete the old apks and add new ones. apk. The question is whether the current version is factory reset, so let's see what effect the factory reset has on these apks?

 
It can be seen that the apk under data/app after restoring the factory settings is just a link, pointing to the apk backed up under system/appjar, that is to say, when restoring the factory settings, after wiping the data area, the system/apppjar is not as we expected. The apk is copied to data/app, but only a link is created. In order to confirm that the apk is deleted, you can check the change of the used space in the data area before and after restoring the factory settings. You will find that the used space in the data area is less than a few hundred megabytes after the download version directly restores the factory settings. Let's think about it, restore the factory settings in the current version, delete the apk under data/app, create a link to point to the system, upgrade to the new version, update the apk under the system, the upgrade will not erase the data area, so the link remains unchanged , because it's name changed, then obviously the new apk can't be found. As for restoring the factory settings, why not copy the apk, but create a link, this is a data area optimization scheme of MTK. If there is no such optimization scheme on the platform, there is no such problem.
Solution:
How do we solve the apk loss?
1. Apply to MTK to close the data area optimization plan;
2. In the case of restoring the factory settings and only saving the link, the name of the apk is always kept unchanged when integrating the apk. 4. Upgrade failure due

to incomplete package I:Opening update package... I:read key e=3 I:1 key(s) loaded from /res/keys







I:Verifying update package...
I:comment is 1682 bytes; signature 1664 bytes from end
E:failed to verify whole-file signature
I:verify_file returned 1
E:signature verification failed
Installation aborted.

The reason for the incomplete package may be that there is no safe exit after copying. If this happens, first delete the package, wait for a while and exit safely after re-copying. If it still does not work, then format the SD card and then copy it. This problem can generally be solved.




Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325647841&siteId=291194637