OTA upgrading method

Abstract

The invention discloses an OTA upgrading method, which comprises the following steps: S1, obtaining the existing program package information of a terminal, and analyzing the description information of each to-be-matched OTA package in an OTA set one by one, the OTA set comprising a plurality of different types of to-be-matched OTA packages; s2, sequentially comparing the description information of each to-be-matched OTA packet in the OTA set with the existing program packet information to select a target OTA packet; wherein the target OTA packet comprises at least one type of OTA packet to be matched; and S3, sending the target OTA packet to the terminal, so that the terminal executes an upgrading operation according to the target OTA packet. The OTA upgrading method provided by the invention not only can support independent upgrading of certain types of to-be-matched OTA packets, but also can support simultaneous upgrading of different types of to-be-matched OTA packets, and can be flexibly suitable for various scene requirements.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and particularly to an OTA upgrade method. Background Art

[0002] With the popularization of smart terminals and the continuous expansion of application scenarios, OTA (Over-The-Air) upgrade, as a key means for smart terminals to perform function updates, performance optimization, etc., has become increasingly important.

[0003] Currently, OTA upgrade is mainly performed based on corresponding OTA upgrade systems, such as Google's GOTA (Google Over-The-Air), MediaTek's MOTA (MediaTek Over-The-Air), and GuangSheng's FOTA (Firmware Over-The-Air). In the interaction process between the server and the terminal of these OTA upgrade systems, the main factors considered are fingerprint information, product name, version number, customer-defined version, etc. Among them, the main factor considered by GOTA is fingerprint information; the main factors considered by MOTA are fingerprint information, customer-defined version, and product name; the main factors considered by GuangSheng FOTA are product name and version number. However, researchers have found that the OTA upgrade methods based on the above OTA upgrade systems are only applicable to the upgrade scenarios of basic system OTA packages (i.e., whole packages), and are not applicable to multi-type OTA package upgrade scenarios, having certain limitations. Summary of the Invention

[0004] The technical problem to be solved by the present invention is: to provide an OTA upgrade method to solve the problem that the existing OTA upgrade methods do not support the simultaneous upgrade of multi-type OTA packages.

[0005] To solve the above technical problem, the technical solution adopted by the present invention is: an OTA upgrade method, which includes the following steps: S1: Obtain the existing program package information of the terminal, and parse the description information of each to-be-matched OTA package in the OTA set one by one, where the OTA set includes multiple different types of to-be-matched OTA packages; S2: Compare the description information of each to-be-matched OTA package in the OTA set with the existing program package information in turn to select a target OTA package; wherein, the target OTA package includes at least one type of to-be-matched OTA package; S3: Send the target OTA package to the terminal so that the terminal performs an upgrade operation according to the target OTA package.

[0006] Further, in the OTA upgrade method of the present invention, the existing package information includes: the first platform name, the first product name, the first module name, the first baseline name, and the first version number.

[0007] Further, in the OTA upgrade method of the present invention, the description information includes: the second platform name, the second product name, the second module name, the second baseline name, and the second version number, where the content of the second product name is empty or not empty.

[0008] Further, in the OTA upgrade method of the present invention, the types of the OTA packages to be matched include: basic system OTA, customer resource OTA, communication OTA, device OTA, and product configuration OTA.

[0009] Further, in the OTA upgrade method of the present invention, in step S2, specifically: Compare the description information of each OTA package to be matched with the existing package information one by one to determine whether each OTA package to be matched meets the preset upgrade conditions; If it meets the preset upgrade conditions, add the OTA package to be matched to the upgrade list as the target OTA package; if it does not meet the preset upgrade conditions, perform a filtering operation on the OTA package to be matched.

[0010] Further, in the OTA upgrade method of the present invention, in step S2, comparing the description information of each OTA package to be matched with the existing package information one by one to determine whether each OTA package to be matched meets the preset upgrade conditions includes the steps of: S21: Compare the first platform name with the second platform name. If the first platform name is the same as the second platform name, go to step S22; if they are different, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S22: Compare the first product name with the second product name. If the second product name matches the first product name or the content of the second product name is empty, go to step S23; if the content of the second product name is not empty and the second product name does not match the first product name, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S23: Compare the first baseline name and the second baseline name to determine whether the baseline upgrade conditions are met; if the baseline upgrade conditions are met, go to step S24; if the baseline upgrade conditions are not met, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S24: Compare the first version number with the second version number. If the second version number is greater than the first version number, it is determined that the OTA package to be matched meets the preset upgrade condition. If the second version number is not greater than the first version number, it is determined that the OTA package to be matched does not meet the preset upgrade condition.

[0011] Further, in the OTA upgrade method of the present invention, comparing the first baseline name and the second baseline name to determine whether the baseline upgrade condition is met includes: Determine the upgrade type between the first baseline and the second baseline according to the first baseline name and the second baseline name. The upgrade type includes same-baseline upgrade and cross-baseline upgrade; If the upgrade type is a same-baseline upgrade, it is determined that the baseline upgrade condition is met; If the upgrade type is a cross-baseline upgrade, further determine whether the cross-baseline upgrade is from the default baseline to a non-default baseline; if so, it is determined that the baseline upgrade condition is met; if not, it is determined that the baseline upgrade condition is not met.

[0012] Further, in the OTA upgrade method of the present invention, a central directory end flag is provided at the end of the OTA package to be matched. The central directory end flag includes annotation content, and the description information is set in the annotation content.

[0013] Further, in the OTA upgrade method of the present invention, before step S1, the following steps are further included: receiving an upgrade request triggered by the terminal, where the upgrade request carries the existing program package information.

[0014] Further, in the OTA upgrade method of the present invention, before step S1, the following steps are further included: configuring a push update task and sending the push update task to the terminal so that when the terminal polls the push update task, it reports the existing program package information.

[0015] The beneficial effects of the present invention are as follows: The present invention provides an OTA upgrade method that supports the upgrade of one or more types of OTA packages, and corresponding description information is added to the tail of the OTA to be matched in advance. When the terminal needs to perform an upgrade and update, the server / tool end can first obtain the existing package information of the terminal and the description information of each OTA package to be matched. Then, based on the obtained existing package information and the corresponding description information, a target OTA package is selected from the OTA package set. The target OTA package includes at least one type of OTA package to be matched. For example, it can include two types of OTA packages to be matched. On this basis, the target OTA package is sent to the terminal, enabling the terminal to perform an upgrade based on the target OTA package, thereby achieving the support for the joint upgrade of different types of OTA packages. That is to say, the present invention sets different types of OTA packages to be matched. During the process of selecting packages for upgrade, one or more different types of OTA packages to be matched can be selected, thereby achieving the support for the independent upgrade of a certain type of OTA package to be matched and also supporting the joint upgrade of different types of OTA packages to be matched, flexibly adapting to various scenario requirements and greatly improving the usage effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a flowchart of the steps of the OTA upgrade method described in the present invention in one embodiment.

[0017] Figure 2 It is a schematic diagram of the data structure of the central directory end flag in the OTA upgrade method described in the present invention.

[0018] Figure 3 It is another flowchart of the steps of the OTA upgrade method described in the present invention in one embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] To describe the technical content, the achieved objectives, and the effects of the present invention in detail, the following is described in conjunction with the embodiments and with reference to the drawings.

[0020] The inventor of the present invention has learned that if OTA upgrade is to be performed, generally, the method of using an OTA upgrade system and an OTA upgrade tool can be adopted. For an OTA upgrade system, it generally consists of a server and a terminal. And if the OTA upgrade tool is used for upgrade, during its use, it generally consists of a tool end and a terminal. The tool end can be an upgrade tool such as a PC. Therefore, please refer to Figures 1 to 3 , the present invention provides an OTA upgrade method, which can be used in an OTA upgrade system or applied to a scenario where upgrade is performed through an upgrade tool such as a PC. Specifically, it includes the following steps: S1: Obtain the existing package information of the terminal, and parse the description information of each OTA package to be matched in the OTA set one by one. The OTA set includes multiple different types of OTA packages to be matched; S2: Compare the description information of each OTA package to be matched in the OTA set with the existing package information of the terminal in sequence to select a target OTA package. Among them, the target OTA package includes at least one type of OTA package to be matched; S3: Send the target OTA package to the terminal so that the terminal can perform an upgrade operation according to the target OTA package.

[0021] As can be seen from the above description, the beneficial effects of the present invention are as follows: The present invention provides an OTA upgrade method that supports the upgrade of one / multiple types of OTA packages, and corresponding description information is added to the tail of the OTA to be matched in advance. When the terminal needs to perform an upgrade and update, the server / tool end can first obtain the existing package information of the terminal and the description information of each OTA package to be matched. Then, based on the obtained existing package information and the corresponding description information, a target OTA package is selected from the OTA package set. The target OTA package includes at least one type of OTA package to be matched, such as it can include two types of OTA packages to be matched. On this basis, the target OTA package is sent to the terminal, enabling the terminal to perform an upgrade based on the target OTA package, thereby achieving the support for the upgrade of different types of OTA packages together. That is to say, the present invention sets different types of OTA packages to be matched. During the process of selecting packages for upgrade, one / multiple different types of OTA packages to be matched can be selected, thereby achieving the support for the independent upgrade of a certain type of OTA package to be matched and also supporting the joint upgrade of different types of OTA packages to be matched, flexibly meeting various scenario requirements and greatly improving the usage effect.

[0022] The following combines Figures 1 to 3 to elaborate in detail on each step in steps S1 - S3 and other optional steps.

[0023] S1: Obtain the existing package information of the terminal, and parse the description information of each OTA package to be matched in the OTA set one by one. The OTA set includes multiple different types of OTA packages to be matched.

[0024] OTA (Over-the-Air) is a technical means for remotely managing and software-updating terminal devices via a mobile communication network or a wireless network. The OTA upgrade method of the present invention can be used in the field of terminal system upgrades for operating systems such as Android and HarmonyOS. The above OTA set includes all the to-be-matched OTA packages for installation upgrades in the server / tool end, which includes various different types of to-be-matched OTA packages. Each type of to-be-matched OTA package can include one or more to-be-matched OTA packages, and the specific quantity is not limited. In some embodiments, each type in an OTA set may only contain one to-be-matched OTA package. For example, if there are five types of to-be-matched OTA packages in the OTA set, then the OTA set will contain five to-be-matched OTA packages (one for each type). Of course, in some embodiments, each type of to-be-matched OTA package can also include multiple to-be-matched OTA packages. For example, the same type of to-be-matched OTA package can contain two, and at least part of the description information at the tails of these two to-be-matched OTA packages is different (such as different second product names).

[0025] The existing package information refers to the relevant data information about the existing package stored in the current terminal (such as a POS machine), which includes the general device information of the terminal (such as the first platform name and the first product name) and the OTA module information of various OTA packages currently existing in the terminal (such as the OTA module information of the basic system OTA package / device OTA package). That is to say, in the present invention, the existing package information may include: the first platform name (i.e., PlatformName), the first product name (i.e., ProductModule), and the OTA module information of various OTA packages, etc. Among them, the OTA module information includes the first module name (i.e., ModuleName), the first baseline name (i.e., Baseline), and the first version number / version name (i.e., VersionCode / VersionName). It should be noted that the first module name is the category of the OTA package to which the OTA module information belongs.

[0026] In actual application, there can be various ways to obtain the existing package information of the terminal. The following provides several optional embodiments: (1) In the scenario of OTA upgrade based on the server side, there are two ways to obtain information: First, the user actively triggers the upgrade on the terminal: The user clicks the corresponding upgrade operation on the terminal, and the terminal device sends an upgrade request to the server. The upgrade request will carry the corresponding existing package information. After the server receives the upgrade request, it can obtain the existing package information of the terminal from the upgrade request. ② Second, the server actively pushes updates: The server configures a push update task and pushes the push update task to the terminal, so that when the terminal polls the push update task, it will report the existing package information to the server.

[0027] (2) In the scenario of OTA upgrade based on the tool side (such as a PC tool): First, import the corresponding OTA package to be matched through the PC tool, and then click the install or update button of the PC tool. The PC tool will obtain the existing package information from the terminal.

[0028] An OTA package is a data package that can be transmitted from the server side / tool side to the terminal through a wireless communication network to implement operations such as device software upgrade, function update, and error repair. The OTA package to be matched is pre-listed / stored in the server side / tool side for selection and use when the terminal performs OTA upgrade.

[0029] The description information refers to some information used to record the relevant data and attributes of the OTA package to be matched. In the present invention, the description information includes the second module name (i.e., ModuleName), the second platform name (i.e., PlatformName), the second product name (i.e., ProductModule), the second baseline name (i.e., Baseline), the second version number (i.e., VersionCode / VersionName), the source version (i.e., PreVersion), and the end flag, etc. The above description information will be specifically introduced as follows: (1) The second module name is the type name of the OTA package to be matched, such as the basic system (i.e., System), customer resources (i.e., Customer), Modem (i.e., communication), devices (i.e., Odm), and product configuration (i.e., Syscfg).

[0030] (2) The second platform name is related to the chip platform: Since different models of chips have differences in design, performance, and functions, the AOSP versions they are adapted to are also different. Moreover, due to hardware and other differences between different models of chips, their driver programs are also different. Eventually, the OTA package of one chip cannot be compatible and shared among different chips, that is, the OTA package of one chip cannot be directly used for upgrading other chips. Therefore, the present invention distinguishes different chips by setting a second platform name related to the chip platform, so as to accurately identify and adapt in operations such as OTA upgrades.

[0031] In practical applications, the second platform names set by the present invention based on the chip platform can be: AND-Q1-ALPHA, AND-Q2-ALPHA, OHM-R1-ALPHA, OHM-S1-ALPHA, etc. Among them, the first field AND represents the Android system, and OHM represents the OpenHarmony system; in the second field, Q represents Qualcomm chips, R represents Rockchip chips, S represents Unisoc chips, and the number indicates the model number of the chip of that manufacturer.

[0032] (3) The second product name (i.e., the second product model) is the name used to identify the product, which can be the device name of the terminal. Assuming the terminal is a POS machine and a cash register, the second product name can be A8, A8S, P20, P20Lite, P30, P30Lite, etc., which is not limited here. It should be noted that in the present invention, the second product name can have two cases: The first case is that the content of the second product name is empty. When it is empty, it indicates that the OTA package to be matched is a general package, that is, it is applicable to all products of a certain platform; the second case is that the content of the second product name is not empty. When the content of the second product name is not empty, it indicates that the OTA package to be matched is applicable to one or more specific products specified by a certain platform. It should be particularly noted that when the second product name is not empty, the second product name can include the product name of one product or the names of multiple products. If it includes the names of multiple products, it means that it can be applicable to the specified multiple products. At this time, multiple different products on the same platform can share this OTA package to be matched. For example, if the second product name (ProductName) is ["P20","P30"], it means that this OTA package to be matched is applicable to two products, "P20" and "P30". At this time, the two products, "P20" and "P30", can share this OTA package to be matched.

[0033] In addition, during actual use, when the content of the second product name of a to-be-matched OTA package is set to be empty, it can also enable multiple different products on the same platform (i.e., products with multiple different product names on the same platform) to share this to-be-matched OTA package, so as to be compatible with different products, thereby greatly improving the usage effect, reducing resource consumption, and reducing the workload of version production personnel.

[0034] (4) The second baseline name refers to the identification name of a specific version or state that serves as the basis for subsequent development and upgrade during software development or system upgrade. The second baseline name represents a relatively stable software version or system state. In the present invention, the default second baseline name is Default. When a certain baseline is customized, the second baseline name is not Default, for example, it can be CustomerA.

[0035] In actual application, for the system first burned into the terminal, it is generally a common version. The default value of the first baseline name of various types of OTA packages in the existing program package of the terminal is "Default". If the second baseline name in the description information at the end of the to-be-matched OTA package is also "Default", it is considered an in-baseline upgrade. When the device is to be sold to customers, customization is required. At this time, the second baseline name at the end of the to-be-matched OTA package can be not "Default". For example, the baseline name of the customer resource OTA package of Customer A is "CustomerA", and the baseline name of the customer resource OTA package of Customer B is "CustomerB". Installing the customer resource OTA package of Customer A on the terminal with the common version, in this case, the baseline name changes from "Default" to "CustomerA", and this situation is considered a "cross-baseline upgrade".

[0036] (5) The second version number is a set of numbers or alphanumeric combinations used to identify the version of software or system. It is arranged according to certain rules and sequences to distinguish versions at different stages and with different contents, such as it can be 1.5.0. It should be noted that the formulation of the second version number is usually based on a specific second baseline name. The second baseline name determines the basic version or state of the software or system, and the version number evolves and is identified on this basis, that is, the version number can clearly identify the development stage of the software or system based on a certain baseline name.

[0037] (6) The source version is the original version or starting version on which the to-be-matched OTA package is based. It is used to identify the starting point of the upgrade operation. If the value of this field is empty, it means it is a full package. If the value of this field is not empty, it means it is an incremental package. It should be noted in particular that when performing OTA upgrades using OTA upgrade tools, etc., the existing method is to first decompress the OTA package to be matched and then parse the OTA package metadata file to obtain description information (such as the second product name), etc. This method is time-consuming. For this reason, the present invention adds description information to the tail of the OTA package to be matched, so that when the present invention selects the target OTA package, it only needs to parse the description information at the tail of the OTA package to be matched, without decompressing the entire OTA package to be matched, and can quickly obtain description information such as the second product name of the OTA package to be matched, with less time consumption. It should be noted that in practical applications, the speed of parsing the description information at the tail of the OTA package to be matched is very fast, and the time consumed is much less than the time consumed in parsing the entire OTA package to be matched. For example, for an 800M OTA package to be matched, it takes about 5 seconds to parse the entire OTA package to be matched, while it only takes about 3 - 5 milliseconds to parse the description information at the tail of the OTA package to be matched. Therefore, by setting the OTA package to be matched and adding description information to the tail of the OTA package to be matched, when in use, the description information at the tail of the OTA package to be matched can be directly decompressed, so that the description information can be quickly obtained, the time consumption can be reduced, and the OTA upgrade efficiency of the present invention can be improved.

[0038] In practical applications, the description information can be added to the End of Central Directory Record of the OTA package to be matched. As Figure 2 shown, the specific structure of the End of Central Directory Record can be as follows: FLAG (4 bytes) + FIXPART1 (16 bytes) + CommentLength (2 bytes) + Comment ('CommentLength' bytes). Among them, the FLAG is the End of Central Directory marker, which has 4 bytes and is fixed at 0x06054b50; the FIX PART1 is 16 bytes, including the current disk number (2 bytes), the disk number of the start position of the central directory (2 bytes), the number of central directories recorded on this disk (2 bytes), the total number of central directory structures (2 bytes), the size of the central directory (4 bytes), and the relative shift of the start position of the central directory (4 bytes); the Comment Length is the comment length, which is 2 bytes; Comment is the comment content.

[0039] In the present invention, the OTA package to be matched can be divided into multiple different types according to needs. For example, it can be divided into five categories according to functions, namely basic system OTA, customer resource OTA, communication OTA (i.e., Modem OTA), device OTA, and product configuration OTA. The following specifically introduces the above five types of OTA packages to be matched.

[0040] (1) Customer Resource OTA: The resource components related to customers cannot be shared among other customers, and customers have the need to change resource components. For example, updating the customer configuration table, boot logo, etc. Therefore, customer resource OTA is designed to support independent upgrade.

[0041] (2) Communication OTA: The same product may select multiple Modem modules, such as Quectel and Fibocom. Since the Modem module is relatively independent and generally does not depend on other modules, communication OTA can be designed to support independent upgrade for flexible upgrade.

[0042] (3) Device OTA: Some devices of the same product may also have multiple options. Among them, the devices that are often changed mainly include LCD, touch screen, camera (i.e., camera), power manager, etc. In actual applications, some customers (such as overseas customers) are worried about some other problems caused by the upgrade of the entire system, so there is a need to lock the basic system version of the terminal. If the device-related components are included in the basic system, when some terminals adapt to the drivers related to new devices, the basic system needs to be updated to use the new devices, which cannot meet the requirement of locking the basic system version of the terminal. Therefore, device OTA is designed to support independent upgrade.

[0043] (4) Product Configuration OTA: The product configuration OTA package mainly contains the product configuration table image. This product configuration table image mainly contains configuration items related to the product such as product name, product model, device name, etc. Taking the POS machine as an example, the product configuration table image may include the product name (such as P20, P30), etc. Generally, a matching product configuration table has been selected when burning the chip package, and the product configuration table cannot be easily changed. Considering that the product configuration table image is relatively independent and does not depend on other modules, sometimes it is necessary to update the product configuration table image separately. For example, existing terminals need to modify or add a certain product configuration item. Therefore, product configuration OTA is designed to support independent upgrade.

[0044] In actual applications, the product configuration OTA packages of different products cannot be shared. Otherwise, after OTA upgrade, the product name, product model, etc. of the terminal will be replaced, which does not meet the expectations. Therefore, in order to prevent the OTA packages of different products from being downloaded from each other, the present invention makes corresponding settings for the description information. Generally, the content of the second product name in the description information at the end of the OTA package to be matched is empty, indicating that it is applicable to all products. In special cases, when the content of the second product name is not empty, a specific product name is specified, indicating that it is only used for the specified product.

[0045] In addition, it should be noted that, as described above, the product configuration table images of different products are different. Therefore, for the product configuration OTA packages, different products cannot share them, but the OTA packages such as the basic system, communication, devices, and customer resources can be shared. In practical applications, since the product configuration table image is relatively stable and does not need to be updated frequently, the OTA update frequency of the product configuration of the terminal is relatively low, while that of other types of OTA packages is relatively high. This means that for a long time, the product configuration table images of different products can be independently maintained without affecting the sharing of other types of OTA packages by different products. For this reason, the present invention sets up a corresponding product configuration table mechanism to set up an independent product configuration OTA for the product configuration table, so that the present invention can support multiple products on the same platform to share OTA packages. That is to say, based on the product configuration table mechanism, the present invention sets up an independent product configuration OTA package to separate the product configuration table image from other types of OTA packages, so that the product configuration table images of different products can be independently maintained without affecting the sharing of other types of OTA packages. At the same time, by setting the content of the second product name in other types of OTA packages (such as being empty), the demand for multiple products on the same platform to share OTA packages is further supported.

[0046] (5) Basic system OTA: Except for relevant components such as customer resources, Modem, devices, and product configuration, other relatively general components are included in the basic system category. For example, the Android framework, general components of chip manufacturers, general components of manufacturers, etc. Therefore, the basic system OTA is designed to support independent upgrade.

[0047] As described above, the OTA packages to be matched can be classified into five categories according to their functions. Since in the present invention, corresponding description information including the second baseline name and the second version number, etc. will be pre-embedded at the end of each OTA package to be matched. For this reason, different types of OTA packages to be matched can set custom second version numbers and second baseline names, which can be achieved by means of attribute presetting. For example, the version number and baseline name attribute definitions of five different types of OTA packages to be matched can be as follows: (1) For the basic system OTA, the attribute of its second version number is ro.system.manu.version, and the corresponding attribute value can be set according to the actual situation, such as it can be 1.1.0; the attribute of its second baseline name is ro.system.branch.name, and the corresponding attribute value can be, for example, Default (default value).

[0048] (2)For the customer resource OTA, the attribute of its second version number is ro.customer.manu.version, and the corresponding attribute value can be, for example, 1.2.0; the attribute of its second baseline name is ro.customer.branch.name, and the corresponding attribute value can be, for example, ChinaUms.

[0049] (3)For the communication OTA, the attribute of its second version number is ro.modem_ext.manu.version, and the corresponding attribute value can be, for example, 1.3.101.1; the attribute of its second baseline name is ro.modem_ext.branch.name, and the corresponding attribute value can be, for example, FIBOCOM-AM-RF0.

[0050] (4)For the device OTA, the attribute of its second version number is ro.odm.manu.version, and the corresponding attribute value can be, for example, 1.3.0; the attribute of its second baseline name is ro.odm.branch.name, and the corresponding attribute value can be, for example, Default (default value).

[0051] (5)For the product configuration OTA, the attribute of its second version number is ro.syscfg_ext.manu.version, and the corresponding attribute value can be, for example, 1.5.0; the attribute of its second baseline name is ro.syscfg_ext.branch.name, and the corresponding attribute value can be, for example, P20-A1.

[0052] S2: Compare the description information of each OTA package to be matched in the OTA set with the existing package information in turn to select the target OTA package; where the target OTA package includes at least one type of OTA package to be matched.

[0053] In practical applications, different types of OTA packages are distinguished by module names. For example, the module name of the basic system OTA package is System, the module name of the customer resource OTA package is Customer, the module name of the device OTA package is Odm, etc. The module names, platform names, product names, baseline names, and version numbers recorded in each type of OTA package are not necessarily the same. Therefore, in the process of selecting packages, it is necessary to find the OTA module information that matches the type of the OTA package to be matched from the existing package information of the obtained terminal, so as to judge whether the preset upgrade conditions are met based on the OTA module information.

[0054] For example, in the process of individually determining whether the OTA package to be matched meets the preset upgrade conditions, assuming that the current OTA package to be matched is the basic system OTA package, when judging this basic system OTA package, it is necessary to determine the second module name of the OTA package to be matched (i.e., the basic system OTA package), which is System. Then, based on this second module name, find the OTA module information that matches the second module name in the existing package information obtained above, that is, find the OTA module information that matches System. For example, the OTA module information found may be: {"ModuleName":"System","Baseline":"Default","VersionName":"1.0.0MDD","VersionCode":0}. Then, compare the found OTA module information with the description information of the OTA package to be matched to determine whether the OTA package to be matched meets the preset upgrade conditions.

[0055] In addition, when the tool or the background determines what type of OTA package the current OTA package to be matched is, it is also judged by the module name at the end of the OTA package to be matched.

[0056] In the present invention, the OTA package to be matched has multiple different types. As described above, the OTA package to be matched can have five different types. The target OTA package can include one type of OTA package to be matched, or can include multiple types of OTA packages to be matched.

[0057] In actual application, in the process of sequentially comparing each OTA package to be matched in a plurality of OTA packages to be matched with the existing package information, if the description information of a certain OTA package to be matched matches the existing package information, then this OTA package to be matched can be used as the target OTA package. The following specifically introduces how to sequentially compare the description information of multiple OTA packages to be matched with the existing package information to determine the target OTA package.

[0058] As Figure 3 shown, in step S2, comparing the description information of each OTA package to be matched in the OTA set with the existing package information in sequence to select the target OTA package from the OTA set includes the following steps: Sequentially compare the description information of the OTA package to be matched with the existing package information to determine whether each OTA package to be matched meets the preset upgrade conditions; If it meets the preset upgrade conditions, add the OTA package to be matched to the upgrade list to be used as the target OTA package; if it does not meet the preset upgrade conditions, perform a filtering operation on the OTA package to be matched.

[0059] The filtering operation is as follows: Ignore and do not process the OTA package to be matched, do not add the OTA package to the upgrade list to be matched, that is, do not perform an update installation of the terminal based on the OTA package to be matched.

[0060] In practical applications, each OTA package to be matched will be compared with the existing package information to determine whether the OTA package to be matched meets the preset upgrade conditions. If it meets the preset upgrade conditions, the OTA package to be matched will be added to the upgrade list. If it does not meet the preset upgrade conditions, a filtering operation will be performed on the OTA package to be matched. It should be noted that during the package selection process, each OTA package to be matched will be compared until all the OTA packages to be matched are traversed. After traversing all the OTA packages to be matched, an upgrade list containing the target OTA packages will be finally formed. The upgrade list records all the OTA packages to be matched that meet the preset upgrade conditions. On this basis, the server can send the target OTA packages in the upgrade list to the terminal, and the terminal installs the OTA packages one by one according to the upgrade list for upgrade and update. After the installation is completed, the terminal restarts the system.

[0061] In practical applications, after each OTA package to be matched is parsed, the description information obtained through the parsing operation will be compared with the existing package information to determine whether the OTA package to be matched meets the preset upgrade conditions. As Figure 3 shown, the specific steps can be as follows: S21: Compare the first platform name with the second platform name. If the first platform name is the same as the second platform name, go to step S22; if not, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S22: Compare the first product name with the second product name. If the second product name is not empty and matches the first product name or the content of the second product name is empty, go to step S23; if the content of the second product name is not empty and the second product name does not match the first product name, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S23: Compare the first baseline name and the second baseline name to determine whether the baseline upgrade conditions are met; if the baseline upgrade conditions are met, go to step S24; if the baseline upgrade conditions are not met, it is determined that the OTA package to be matched does not meet the preset upgrade conditions; S24: Compare the first version number with the second version number. If the second version number is greater than the first version number, it is determined that the OTA package to be matched meets the preset upgrade conditions. If the second version number is not greater than the first version number, it is determined that the OTA package to be matched does not meet the preset upgrade conditions.

[0062] In practical applications, after obtaining the existing package information of the terminal and the description information of a certain OTA package to be matched, the comparison can be carried out according to the following steps to determine whether it meets the preset upgrade conditions: (1) Check the platform name: Compare the first platform name with the second platform name of this OTA package to be matched. If the first platform name is the same as the second platform name, proceed to the next step (i.e., check the product name). If the first platform name is different from the second platform name, perform a filtering operation on this OTA package to be matched. It should be noted that when checking the platform name, the first platform name and the second platform name must correspond one by one, that is, the second platform name in the tail description information of the OTA package to be matched and the first platform name of the terminal must be the same to proceed to the next step.

[0063] (2) Check the product name: Compare the first product name with the second product name of this OTA package to be matched. If the second product name matches the first product name or the content of the second product name is empty, proceed to the next step (i.e., check the baseline name); if the content of the second product name is not empty and the second product name does not match the first product name, it is determined that this OTA package to be matched does not meet the preset upgrade conditions. It should be noted that if the content of the second product name is not empty and there is a product name in the first product name that is the same as the second product name, it indicates that the first product name matches the second product name; if there is no product name in the first product name that is the same as the second product name, they do not match. For example, assume that the first product name is ["P20", "P30"] and the second product name is ["P20"] (the content is not empty). At this time, there is a product name in the first product name that is the same as the second product name (i.e., P20), which can indicate that the first product name matches the second product name, and at this time this OTA package to be matched meets the preset upgrade conditions.

[0064] (3) Check the baseline name: Compare the first baseline name and the second baseline name to determine whether the baseline upgrade conditions are met; if the baseline upgrade conditions are met, proceed to the next step (i.e., check the version number); if the baseline upgrade conditions are not met, it is determined that this OTA package to be matched does not meet the preset upgrade conditions.

[0065] Among them, comparing the first baseline name and the second baseline name to determine whether the baseline upgrade conditions are met includes the following steps: Determine the upgrade type between the first baseline and the second baseline according to the first baseline name and the second baseline name, and the upgrade type includes in-baseline upgrade and cross-baseline upgrade; If the upgrade type is in - baseline upgrade, it is determined that the baseline upgrade condition is met; If the upgrade type is cross - baseline upgrade, it is further determined whether it is an upgrade from the default baseline to a non - default baseline between the first baseline and the second baseline; if so, it is determined that the baseline upgrade condition is met; if not, it is determined that the baseline upgrade condition is not met.

[0066] It should be noted that the above - mentioned first baseline is the baseline represented by the first baseline name in the existing program package information of the terminal, and the second baseline is the baseline represented by the second baseline name in the OTA package description information to be matched. The in - baseline upgrade refers to the upgrade and update within the same baseline, and the cross - baseline upgrade refers to the upgrade and update from one baseline to another baseline (such as from Default to CustomerA).

[0067] In practical applications, during the process of comparing the first baseline name and the second baseline name, it is necessary to determine whether the OTA package to be matched meets the baseline upgrade condition. Only when the baseline upgrade condition is met can it enter the version number check step. In the present invention, determining whether the OTA package to be matched meets the baseline upgrade condition can be achieved through the following steps: First, according to the first baseline name and the second baseline name, determine the upgrade type between the first baseline in the corresponding terminal and the second baseline in the OTA package to be matched. Then, according to the different upgrade types, determine whether the OTA package to be matched meets the baseline upgrade condition. Specifically: If the upgrade type is in - baseline upgrade, the OTA package to be matched meets the baseline upgrade condition. For example, since the default value of the first baseline name of various types of OTA packages in the existing program package information of the terminal is Default, if the second baseline name in the description information at the end of the OTA package to be matched is also Default, it is considered an in - baseline upgrade, and at this time, the OTA package to be matched meets the upgrade condition.

[0068] If the upgrade type is cross - baseline upgrade, it is further necessary to determine whether it is an upgrade from the default baseline to a non - default baseline between the first baseline and the second baseline, that is, to determine whether the first baseline is the default baseline (Default baseline) and the second baseline is a non - default baseline (such as CustomerA, CustomerB). If so, it is determined that the OTA package to be matched meets the baseline upgrade condition; if not, it is determined that the OTA package to be matched does not meet the baseline upgrade condition.

[0069] That is to say, the cross-baseline upgrade of the present invention only supports upgrading from the Default baseline to a non-Default baseline, and does not support upgrading from a non-Default baseline to other baselines. For example, it supports upgrading from Default to CustomerA, does not support upgrading from CustomerA to CustomerB, nor does it support upgrading from CustomerA to Default. In addition, it should be noted that cross-baseline upgrade only allows the use of full packages, while same-baseline upgrade allows the use of full packages and incremental packages.

[0070] (4) Check the version numbers: Compare the first version number with the second version number. If the second version number is greater than the first version number, it is determined that the OTA package to be matched meets the preset upgrade conditions; if the second version number is not greater than the first version number, it is determined that the OTA package to be matched does not meet the preset upgrade conditions. It should be noted that if the OTA package to be matched is the target OTA package, the second version number of this OTA package to be matched must be greater than the first version number of the terminal to prevent downgrading.

[0071] As described above, by setting the second product name in the description information of the OTA package to be matched, the present invention has the following two situations: the content of the second product name is empty, and the content of the second product name is not empty (i.e., there is a specific product name). When the content of the second product name is empty, it is set to be applicable to all products. When the content of the second product name is not empty, the second product name may include one or more product names of the same platform, and it is set to be applicable to one or more products of the same platform. In the process of comparing the OTA information of each OTA package to be matched with the existing package information, the above-mentioned product name check is to find the OTA package to be matched in which the second product name matches the first product name or the content of the second product name is empty. If the content of the second product name is empty, it can support multiple different products of the same platform (i.e., products with multiple different product names of the same platform) to share a certain OTA package to be matched, that is, to branch according to the second product name to be compatible with different products, thereby reducing the maintenance cost, the storage space occupied by the server, and the corresponding resource consumption.

[0072] In actual application, in the upgrade list, for the same type, there may be a to-be-matched OTA package with a non-empty second product name that matches the first product name, or there may be a to-be-matched OTA package with an empty second product name. In this case, the to-be-matched OTA package with a non-empty content of the product name that matches the first product name can be searched for first. If no to-be-matched OTA package that matches the first product name is found, then the to-be-matched OTA package with an empty content of the second product name is searched for. Specifically, during the package selection process, all to-be-matched OTA packages in the OTA set that meet the preset upgrade conditions are selected. As can be seen from step S22 above, during the process of checking the product name, the to-be-matched OTA packages with the second product name matching the first product name or the second product name having an empty content are selected. In some cases, when there are multiple to-be-matched OTA packages of the same type, after performing the above steps S21 to S24, for the to-be-matched OTA packages of the same type, there may be a to-be-matched OTA package with a non-empty second product name that matches the first product name in the upgrade list, or there may be a to-be-matched OTA package with an empty second product name. If both exist, a second round of selection can be performed at this time to achieve priority adjustment, that is, the to-be-matched OTA package with a non-empty and matching second product name in the same type is preferentially selected as the target OTA package, and the to-be-matched OTA package with an empty second product name in the same type is removed from the upgrade list to update the upgrade list. If only one exists, the above second round of selection is not required.

[0073] Of course, in actual application, if there is only one to-be-matched OTA package of the same type in an OTA set, at this time, only the above steps S21 to S24 need to be performed to finally select the target OTA package, and the operation of the above second round of selection is not required.

[0074] S3: Send the target OTA package to the terminal so that the terminal performs an upgrade operation according to the target OTA package.

[0075] After selecting the target OTA package from multiple types of to-be-matched OTA packages, the target OTA package can be sent to the terminal. After the terminal receives it, it can perform an update and upgrade according to the target OTA package. In actual application, as described above, after traversing all the to-be-matched OTA packages, an upgrade list containing the target OTA package will finally be formed. The upgrade list records all to-be-matched OTA packages that meet the preset upgrade conditions. On this basis, the server can send the target OTA package in the upgrade list to the terminal, and the terminal installs them one by one according to the upgrade list for upgrade and update. After the installation is completed, the terminal restarts the system.

[0076] In summary, the OTA upgrade method provided by the present invention: (1) supports both the simultaneous upgrade of multiple types of OTA packages to be matched and the independent upgrade of the OTA packages to be matched; supports multiple products on the same platform to share a single OTA package to be matched; and supports the rapid parsing of the OTA packages to be matched to obtain description information. (2) By adding description information to the tail of the OTA packages to be matched, classifying the OTA packages to be matched into five categories, adding new OTA-related system attributes, product configuration table images, and other mechanisms, different types of OTA packages to be matched can be put on the server. These different types of OTA packages to be matched support both joint upgrades and independent upgrades. Moreover, due to the existence of the product configuration table mechanism, multiple products on the same platform can share OTA packages. (3) The OTA upgrade tool of this solution only needs to parse the description information at the tail of the OTA packages to be matched and does not need to decompress the entire OTA package to be matched, and can quickly parse out description information such as the second platform, improving efficiency. (4) The present invention is applicable not only to the Recovery upgrade and AB upgrade of the Android system but also to the OTA upgrade of the HarmonyOS (L0-L2). In various terminals, such as mobile phones and POS machines, due to differences in product models, devices, customers, and other factors, each needs to maintain an OTA upgrade chain, which will bring a huge workload to version production personnel. Therefore, the five OTA modules designed in this patent, namely the basic system OTA, device OTA, customer resource OTA, Modem OTA, and product configuration OTA, can be upgraded together or independently, and can flexibly meet various scenario requirements. Moreover, combined with the product configuration table mechanism, OTA packages of different products on the same platform can be shared to reduce maintenance costs and server storage space occupancy.

[0077] The above are only the embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent transformation made using the content of the specification and drawings of the present invention, or directly or indirectly applied in related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. An OTA upgrade method, characterized in that: The following steps are involved: S1: obtaining existing program package information of the terminal, and parsing description information of each OTA package to be matched in the OTA set one by one, wherein the OTA set includes multiple different types of OTA packages to be matched; S2: Compare the description information of each OTA package to be matched in the OTA set with the existing program package information in turn to select a target OTA package; wherein the target OTA package includes at least one type of OTA package to be matched; S3: Send the target OTA package to the terminal, so that the terminal performs an upgrade operation according to the target OTA package.

2. The OTA upgrade method according to claim 1, characterized in that: The existing program package information includes: a first platform name, a first product name, a first module name, a first baseline name, and a first version number.

3. The OTA upgrade method according to claim 2, characterized in that: The description information includes: a second platform name, a second product name, a second module name, a second baseline name and a second version number, wherein the content of the second product name is empty or not empty.

4. The OTA upgrade method according to claim 1, characterized in that: The types of OTA packages to be matched include: basic system OTA, customer resource OTA, communication OTA, device OTA and product configuration OTA.

5. The OTA upgrade method according to claim 3, characterized in that: In step S2, specifically: Comparing the description information of the OTA packages to be matched with the existing program package information one by one to determine whether each OTA package to be matched meets the preset upgrade condition; If the preset upgrade condition is met, the OTA package to be matched is added to the upgrade list as the target OTA package; If the preset upgrade condition is not met, a filtering operation is performed on the OTA package to be matched.

6. The OTA upgrade method according to claim 5, characterized in that: In step S2, the description information of the OTA package to be matched is compared with the existing program package information one by one to determine whether each OTA package to be matched meets the preset upgrade condition, including the steps of: S21: comparing the first platform name with the second platform name, if the first platform name is consistent with the second platform name, proceeding to step S22; if they are inconsistent, determining that the OTA package to be matched does not meet the preset upgrade condition; S22: Compare the first product name with the second product name. If the second product name matches the first product name or the content of the second product name is empty, proceed to step S23; if the content of the second product name is not empty and the second product name does not match the first product name, determine that the OTA package to be matched does not meet the preset upgrade condition; S23: Compare the first baseline name and the second baseline name to determine whether a baseline upgrade condition is met; If the baseline upgrade condition is met, proceed to step S24; if the baseline upgrade condition is not met, determine that the OTA package to be matched does not meet the preset upgrade condition; S24: Compare the first version number with the second version number. If the second version number is greater than the first version number, determine that the OTA package to be matched meets the preset upgrade condition. If the second version number is not greater than the first version number, determine that the OTA package to be matched does not meet the preset upgrade condition.

7. The OTA upgrade method according to claim 6, characterized in that: Comparing the first baseline name with the second baseline name to determine whether a baseline upgrade condition is met includes: Determining, according to the first baseline name and the second baseline name, an upgrade type between the first baseline and the second baseline, wherein the upgrade type includes same-baseline upgrade and cross-baseline upgrade; If the upgrade type is the same as the baseline upgrade, it is determined that the baseline upgrade condition is met; If the upgrade type is a cross-baseline upgrade, it is further determined whether the first baseline and the second baseline are upgraded from a default baseline to a non-default baseline; if so, it is determined that the baseline upgrade condition is met; if not, it is determined that the baseline upgrade condition is not met.

8. The OTA upgrade method according to claim 1, characterized in that: A central directory end marker is provided at the tail of the OTA package to be matched, the central directory end marker includes annotation content, and the description information is provided in the annotation content.

9. The OTA upgrade method according to claim 1, characterized in that: Before step S1, the method further includes the following steps: receiving an upgrade request triggered by the terminal, wherein the upgrade request carries the existing program package information.

10. The OTA upgrade method according to claim 1, characterized in that: Before step S1, the method further includes the following steps: configuring a push update task, and sending the push update task to the terminal, so that the terminal reports the existing program package information when polling the push update task.

Images