Tag Archives: ota

Android r compiles OTA times error: ExternalError: Invalid ro.product.property_source_order

In make dist dist_ When compiling OTA package, dir = mydist encountered an error, which was not encountered in previous Android versions. Here is a record
error report content:

2021-07-02 09:53:29 - common.py - WARNING : Failed to read ODM/build.prop
2021-07-02 09:53:29 - add_img_to_target_files.py - ERROR   : 
   ERROR:
Traceback (most recent call last):
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 999, in <module>
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 993, in main
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 733, in AddImagesToTargetFiles
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 701, in LoadInfoDict
    build_info = BuildInfo(d)
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 393, in __init__
    self._device = self.GetOemProperty("ro.product.device")
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 509, in GetOemProperty
    return self.GetBuildProp(key)
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 451, in GetBuildProp
    return self._ResolveRoProductBuildProp(prop)
  File "/home/xxxx/yourdevice_r_1.0_dev_0616/android/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 476, in _ResolveRoProductBuildProp
    "Invalid ro.product.property_source_order '{}'".format(source_order))
**ExternalError: Invalid ro.product.property_source_order '['odm', 'vendor', 'product', 'product_services', 'system']'**

Analyze the corresponding common. Py code

common.py script
 def _ResolveRoProductBuildProp(self, prop):
   default_source_order = self._GetRoProductPropsDefaultSourceOrder()
   source_order_val = self._GetRawBuildProp(
        "ro.product.property_source_order", None)
   source_order = source_order_val.split(",")
       if any([x not in default_source_order for x in source_order]):
      raise ExternalError(
          "Invalid ro.product.property_source_order '{}'".format(source_order))#挂在这行

  def _GetRoProductPropsDefaultSourceOrder(self):
  ...
  return BuildInfo._RO_PRODUCT_PROPS_DEFAULT_SOURCE_ORDER_CURRENT

  _RO_PRODUCT_PROPS_DEFAULT_SOURCE_ORDER_CURRENT = [
      "product", "odm", "vendor", "system_ext", "system"]

Open systme.prop in the board

ro.product.property_source_order=odm,vendor,product,product_services,system

It can be seen that the two do not match, resulting in an error
modify the ro.product.property in system.prop_ source_ The content of the order property, so that the two are equal, the compiler will no longer report an error.

#ro.product.property_source_order=odm,vendor,product,product_services,system
ro.product.property_source_order=odm,vendor,product,system_ext,system

A strange upgrade data package error problem

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.