CN107783776B

Movatterモバイル変換

Info

Publication number: CN107783776B
Application number: CN201610742935.6A
Authority: CN
Inventors: 裘绍翔; 张智宇
Original assignee: Banma Zhixing Network Hongkong Co Ltd
Current assignee: Banma Zhixing Network Hongkong Co Ltd
Priority date: 2016-08-26
Filing date: 2016-08-26
Publication date: 2021-10-15
Anticipated expiration: 2036-08-26
Also published as: CN107783776A

Abstract

本申请公开了固件升级包的处理方法及装置、电子设备，该方法包括步骤：读取升级指令，所述升级指令包括用于指示操作源文件的指令，所述源文件为已存在于系统中的文件；根据所述升级指令，对所述源文件的索引节点中的信息进行修改；所述索引节点中的信息包括读取所述源文件的路径。本申请可以减少固件升级时对系统运行的影响。

The present application discloses a method and device for processing a firmware upgrade package, and an electronic device. The method includes the steps of: reading an upgrade instruction, where the upgrade instruction includes an instruction for instructing to operate a source file, and the source file already exists in the system modify the information in the index node of the source file according to the upgrade instruction; the information in the index node includes the path for reading the source file. The present application can reduce the impact on system operation during firmware upgrade.

Description

Processing method and device of firmware upgrade package and electronic equipment

Technical Field

The present application relates to a firmware upgrade technology, and in particular, to a firmware upgrade processing method and apparatus, and an electronic device.

Background

FOTA (firmware over-The-Air firmware upgrade) is The current mainstream upgrade mode of a mobile device operating system (such as Android), and an upgrade packet is transmitted between a terminal device and a server through network interaction to complete firmware upgrade of The terminal device. The firmware upgrade package used in the firmware upgrade can be divided into a full firmware upgrade package and an incremental firmware upgrade package according to the content.

The firmware upgrade performed by the full firmware upgrade package is the upgrade of all files of the system, which is equivalent to deleting all files of the current system and then reinstalling all files of the current system. The firmware upgrade is carried out through the increment firmware upgrade package, only the difference part is upgraded, and the non-difference part is not modified.

In the prior art, after a firmware upgrade package is downloaded and installed, a file (which may be called a source file) in an original system is usually replaced and stored in a system partition, but the firmware upgrade needs to be completed by restarting the system in the manner of installing the firmware upgrade package, which affects the operation of the system.

Disclosure of Invention

The application provides a processing method and device for a firmware upgrade package and an electronic device, which can reduce the influence on system operation during firmware upgrade.

According to a first aspect of the embodiments of the present application, there is provided a method for processing a firmware upgrade package, the method including:

reading an upgrade instruction, wherein the upgrade instruction comprises an instruction for instructing to operate a source file, and the source file is a file existing in a system;

modifying information in the index node of the source file according to the upgrading instruction; the information in the inode includes a path to read the source file.

In another aspect of the present application, an electronic device includes:

a processor;

a memory storing processor-executable instructions;

wherein the processor is coupled to the memory for reading program instructions stored by the memory and, in response, performing the following:

In a third aspect of the present application, there is provided a processing apparatus for a firmware upgrade package, including:

the communication module is used for reading an upgrading instruction, wherein the upgrading instruction comprises an instruction for indicating to operate a source file, and the source file is a file which already exists in a system;

the processing module is used for modifying the information in the index node of the source file according to the upgrading instruction; the information in the inode includes a path to read the source file.

According to the method and the device, the information in the index nodes is modified, so that the system can be redirected to the patch file or the operations of deleting and recovering the source file and the like are performed according to the modified index nodes when the system source file is opened, the possibility of not restarting equipment during upgrading is created, and the influence of upgrading on system operation is greatly reduced.

Drawings

FIG. 1 is a network diagram of an application environment in an embodiment of the present application;

FIG. 2 is a partial flowchart of a method for processing a firmware upgrade package according to an embodiment of the present disclosure;

FIG. 3 is a partial flow diagram of a method for processing a firmware upgrade package in an application example;

FIG. 4a is a diagram of a hardware architecture of an electronic device to which the embodiments of the present application are applicable;

FIG. 4b is a diagram illustrating a hardware architecture of a processing device for a firmware upgrade package according to an embodiment of the present invention;

fig. 5 is a software logic block diagram of a processing device of a firmware upgrade package in an embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The application provides a processing method for a firmware upgrade package of a terminal device, wherein the firmware upgrade package can be a change set for one-time upgrading of an operating system of the terminal device, and a file attached to the firmware upgrade package and used for replacing a source file is called a patch file. The terminal device to which the method is applied can be various devices with networking functions, and the devices can be upgraded by utilizing FOTA technology, such as a mobile terminal, a tablet computer, a portable media player, a vehicle-mounted terminal, a wearable device and the like. The type of device is not limited in this application.

Fig. 1 is a schematic diagram of a network. Theterminal device 100 is connected to theserver 120 through thenetwork 110, and theterminal device 100 may have an operating system, which may be an embedded operating system, such as an Android system, an iOS system, a Linux system, and the like. The operating system has a system partition and a data partition (data partition), and theterminal device 100 may also be loaded with a plurality of application programs. The system partition may store system files of the operating system of theterminal device 100. The data partition may be a storage area provided by theterminal device 100 for use by a user or other application. Files of the non-operating system may not be allowed to be stored in the system partition, and in some examples, system files stored in the system partition may be restricted from changing.

The processing method of the firmware upgrade package of the present application may, in some examples, involve processing of a download process, an installation process, and a file validation process of the firmware upgrade package, and may, in some examples, involve processing of the installed firmware upgrade package, for example, uninstalling the firmware upgrade package, detecting a system exception during using the firmware upgrade package, and the like.

FIG. 2 illustrates a partial flow of processing of a firmware upgrade package in some examples.

Step S201, reading an upgrade instruction, wherein the upgrade instruction comprises an instruction for instructing to operate a source file, and the source file can be a file already existing in the system;

s202, modifying the information in the index node of the source file according to the upgrading instruction; the information in the inode includes a path to read the source file.

In some examples, the firmware upgrade package may be stored in the temporary directory after being downloaded, and the firmware upgrade package in the temporary directory is stored in the data partition after being validated. When the legality is verified, if the firmware upgrading packet is a compressed upgrading packet, the legality is verified after the firmware upgrading packet is decompressed. The purpose of the validity verification is to ensure the security of the firmware upgrade package, and the validity verification may be performed with reference to a signature and verification process of an installation package of an application program, for example.

In some examples, the firmware upgrade package may include an upgrade package description file in which the applicability of the firmware upgrade package may be described to prevent the firmware upgrade package from being installed to the wrong operating system or being used maliciously. The firmware upgrade package can be explained through the upgrade package description file, and the upgrade process is guided. For example, in some examples, the upgrade package description file may contain description information of the patch file, information for describing the applicable range of the firmware upgrade package, and the like; in one example, the upgrade instructions may be stored in an upgrade package description file for instructing how to perform the upgrade process, and the upgrade package description file may further include information such as a path of the source file.

The upgrade process may be a replacement of a file already existing in the system (hereinafter the source file), or may be a restoration of a source file already marked as unavailable or a marking of a source file as unavailable. Thus, the upgrade instructions may include one or more of the following instructions: the method comprises a source file replacing instruction, a source file recovering instruction and a source file deleting instruction, wherein the source file is a file which already exists in the system. It will be readily appreciated that for different upgrade instructions, in some examples, the firmware upgrade package may also include patch files to replace the source files, which may be stored in the data partition. The patch file is stored in the data partition without modifying the system partition content, i.e. the source file in the system is not changed. Because the source file in the system still exists, the possibility that the firmware is returned to the state before the system is upgraded exists after the firmware is upgraded, and because the read file is not the file of the system partition but the file of the data partition, the possibility that the equipment does not need to be restarted during the upgrading is created, and the influence of the upgrading on the system operation is greatly reduced.

As an example, information such as Hash (Hash) values of all patch files in the firmware upgrade package (for example, the Hash values can be obtained through MD5(Message Digest Algorithm, fifth edition of chinese name) and applicability ranges of each patch file may be obtained, and whether a patch file is reasonable or not may be calculated based on the obtained information, and if not reasonable, the patch file may be ignored at the time of installation. For a reasonable patch file, information (Hash value, etc.) related to the patch file may be put down to the kernel to be validated.

The firmware upgrade package stored in the data partition may be organized and stored in units of firmware upgrade packages. The file directory organization in the firmware upgrade package may not be limited, and it should be noted that the related information in the upgrade package description file in the firmware upgrade package and the information such as the Hash value corresponding to the patch file may be stored in the database in an encrypted manner, so as to avoid being tampered. In some examples, it may be responsible for processing the stored firmware upgrade package by a process.

In some examples, after triggering the action of installing the firmware upgrade package, an instruction for installing the firmware upgrade package is received, during the installation process, information in an index node (Inode) of the source file is modified according to the upgrade instruction, and the upgrade process is completed according to the modified index node. Inode refers to a data structure. Each Inode maintains meta-information data for a file system object (including files, directories, device files, sockets, pipes, etc.) in the file system. The modification of the information in the index node of the source file may be adding new annotation information to the Inode, or deleting or modifying existing annotation information.

The condition for triggering the installation of the firmware upgrade package may be in various manners, for example, the condition may be actively triggered by the user, the user may be prompted by theterminal device 100, and the user may select the time for installing the firmware upgrade package according to his own will; for another example, the installation process may be triggered automatically by the system, and the system may trigger installation at a certain time period (e.g., 12: 00 a.m.), at a certain time (e.g., when the device is powered on), and so on. The application is not limited as to the triggering occasions.

As an example, it may be that the attribute values of the Inode are extended, and the extended Inode attribute values are modified when the system is responding to an instruction to install the firmware upgrade package. The way of modifying the information in the index node may be different for different upgrade instructions, for example, if an upgrade instruction is a replace source file instruction, a path of a patch file replacing the source file may be marked in an Inode node of the source file that needs to be replaced; the following is an example of modifying the extended Inode attribute values: the modified Inode mainly comprises the following contents:

Struct Patch{

const char filePath; v. target file path, i.e. patch file path

Const char srcPath; v. Source File Path

Const u8 hash [32 ]; v. target File hash value, for validity checking: |, target File hash value

}；

For another example, if the upgrade instruction is a restore source file instruction, deleting a path of a patch file already existing in an original label in an inode of the source file, where the deleted label may include a first identifier, where the first identifier may be generated by a system in response to an instruction of another firmware upgrade package to indicate that the source file is unavailable; for another example, if the upgrade instruction is a delete source file instruction, the source file is marked as unavailable in the Inode of the source file through the first identifier, and as an example, a corresponding judgment logic may be added to the relevant API, so that the API may refuse to open the source file according to the first identifier in the Inode.

In some examples, after the installation process of the firmware upgrade package is completed, a process of file opening may be performed to validate the installed firmware upgrade package. In some examples, the user may also be provided with a setup option that allows the user to determine which firmware upgrade packages to not use or use. When it is determined to use this firmware upgrade package, validation of the firmware upgrade package may be achieved by opening the source file through the OPEN command. The source file may be in a used state or an idle state, and different file opening procedures may be executed for different current used states of the source file, and therefore, in some examples, the following procedure may be performed:

whether a process using the source file is in an idle state or not can be judged before the source file is opened, and if the process is in the idle state, an OPEN instruction can be triggered to read the source file; as an example, for a patch file in a use state, it may be determined whether a process using the patch file is rebooteable (the rebooteable process may be a process that does not affect system operation of the device when the process is rebooted), and for a rebooteable process, the process may be ended, and an OPEN instruction may be triggered to read a source file when the process is rebooted, and for a non-rebooted process, the OPEN instruction may be triggered when an operating system is rebooted.

When the OPEN instruction of the source file is responded, the read file path can be determined according to the attribute value expanded in the Inode, for example, if the attribute value expanded in the Inode is null, the path of the source file is continuously read to OPEN the source file, and if the attribute value expanded in the Inode is not null, the following further operations are performed according to the specific value of the attribute value: in some examples, the Inode attribute value represents a path of the patch file, and the patch file under the path is opened according to the attribute value; in some examples, an Inode attribute value may represent that a source file needs to be deleted, and opening the source file may be ignored according to the attribute value.

It can be seen that the scheme provided by the application can be rapidly upgraded, and as most of files are actually used in only a few scenes, the files can be dynamically replaced without restarting under the idle condition. Even if the file is already used, the user belongs to the rebootable processes, and rebooting the system can be avoided by rebooting those processes.

After the patch file takes effect, some examples can also detect whether the process using the patch file is abnormal, and if the process using the patch file is abnormal, the firmware upgrade package at this time can be deleted, so that the system can be retreated to the system version before the upgrade, and the system rollback is realized, so that the condition that the system is abnormal due to the upgrade is prevented, particularly the condition that the system is abnormal in starting. When the firmware upgrade package is abnormal, for example, a patch package which is not completely verified is pushed, the system can find the abnormality caused by the firmware upgrade package with the problem through an abnormality detection process, and avoid using the firmware upgrade package with the problem in the subsequent restart process, so that the system is helped to recover.

Some examples may also include the process of deleting a firmware upgrade package. The instruction to trigger the uninstallation of the firmware upgrade package may be triggered by the user, but other triggering cases are not excluded.

Deleting the firmware upgrade package can be deleting operation such as deleting patch files and/or deleting upgrade package description files. In response to an instruction to delete a firmware upgrade package, the patch file to be deleted may be marked (e.g., marked as being deleted) prior to formal deletion of the patch file to prevent deletion of the patch file in use from causing a system operating error. To ensure that the system can roll back after patch file deletion, the extended attribute values in the Inode can be recalculated, as an example, so that the file of the correct path can be read the next time the file is read. Several methods of recalculating the extended attribute value of Inode are enumerated herein: 1. the path of the patch file marked in the Inode node may be deleted, for example, the extended attribute value in the Inode may be deleted, so that the system reads the source file of the system partition again when the file is opened next time; 2. if more than one version of firmware upgrade package exists in the data partition, the path of the patch file marked in the Inode node may be replaced, for example, the extended attribute value in the Inode may be replaced with another version of firmware upgrade package, so that the system reads the patch file in another version of firmware upgrade package according to the path represented by the attribute value when opening the file next time.

In some examples, when the patch file is deleted, it may be determined whether the patch file is in a used state, and whether to perform a deletion operation is determined according to a determination result, for example, the patch file may be directly deleted when the patch file is not used; if the patch file is being used and the process using the patch file can be restarted, the process can be closed, and the process is restarted after the deleting operation is executed; if the patch file is being used and the process using the patch file cannot be restarted, the equipment can be prompted to be restarted, when the equipment is restarted, the patch file is deleted when the patch file is read and marked as a deleting state in the upgrade package description file, and other files are opened according to the mark in the Inode, so that the deleting operation is completed. By way of example, the corresponding information of the patch file in the upgrade package description file may be deleted after the patch file is deleted, and if all patch files are deleted, the upgrade package description file may be deleted.

With reference to the scenario described in fig. 1, fig. 3 is a partial flowchart of a processing method for a firmware upgrade package in an application example, where aterminal device 100 starts a process (hereinafter referred to as an upgrade package management process) to download a firmware upgrade package from aserver 120, where the content of the firmware upgrade package including an upgrade package description file and patch files 1 and 2 may include the following partial contents:

forwarding name

Switch bin/patch File 1

Limiting Patch File 2

├signature

Xml/. issuer signature, where there is MD5 for each file and the signature for all files

Xml/xxx other signatures was transcribed

The upgrade instructions in the upgrade package description file include: a file replacement instruction: instructing patch file 1 to replace source file a; and (4) file recovery instructions: indicating a resume source file b; a file delete instruction indicating to ignore source file c.

And in the S301 stage, the firmware upgrade package is downloaded to a temporary directory. And then, the upgrade patch management process verifies the validity of the firmware upgrade patch according to the signature information in the upgrade patch description file (stage S302), and in stage S303, the firmware upgrade patch is stored in the data partition after verification is passed, and meanwhile, the related information of the upgrade patch description file and the related information of the patch file are encrypted and stored in a database.

In the stage of S304, modifying the attribute value of the Inode according to the upgrading instruction: after a process of installing a firmware upgrade package is triggered by a user, traversing each upgrade instruction in an upgrade package description file, and marking a path of a patch file 1 in an extension attribute value of an Inode of a source file a through an OPEN instruction aiming at a file replacement instruction; for a source file recovery instruction, deleting original labeling information in an Inode extended attribute value of a source file b through an OPEN instruction; and for the source file deleting instruction, marking a first identifier on the expansion attribute value of the Inode of the source file c through an OPEN instruction, and adding corresponding judgment logic in a corresponding API (application program interface), so that the API stops opening the source file c when recognizing the first identifier.

Stage S305, validating the firmware upgrade package through OPEN instruction: after the firmware upgrade package is installed, sequentially trying to OPEN each source file of the system partition, when trying to OPEN the source file a, if the source file a is being used, judging whether the process using the source file a can be restarted, if the process can be restarted, closing the current process, then opening the source file a through an OPEN instruction, judging whether the extended attribute value of the Inode of the source file a is empty, if not, reading the patch file 1 according to the path in the patch file 1, and enabling the patch file 1 to take effect. When trying to OPEN the source file b, if the source file is in an idle state, opening the source file b through an OPEN instruction, judging whether the extended attribute value of the Inode of the source file b is empty or not, and opening the source file b according to the path of the source file b in a system partition if the judgment result is empty; when the source file c is tried to be opened, if the source file c is in an idle state, the source file c is opened through an OPEN instruction, the extended attribute value of the Inode of the source file c is judged not to be empty, and the API refuses to OPEN the source file c according to the marked first identifier.

And S306, performing exception checking on the patch file in use: after the firmware upgrade package is installed and takes effect, the upgrade package management process performs exception detection on each patch file in use, and if an exception patch file is found, the corresponding label of the patch file is deleted in the Inode, so that the system can return to the version before upgrade when reading the file next time.

And S307, unloading the firmware upgrade package: when the installed firmware upgrade package needs to be deleted, judging whether each patch file is used currently or not, and deleting the patch file 1 if the judgment result shows that the patch file 1 is not used; if the patch file 2 is being used and the process using the patch file 2 can be restarted, the process is closed, and the process is restarted after the patch file 2 is deleted. And after all patch files are deleted, deleting the upgrade patch description file.

Corresponding to the foregoing embodiment of the processing method of the firmware upgrade package, the present application also provides an embodiment of a processing apparatus of the firmware upgrade package.

The embodiment of the processing device of the firmware upgrade package can be applied to electronic equipment. A hardware block diagram of an electronic device may refer to fig. 4a, and the electronic device may include hardware such as a processor, a memory, a network interface, and a non-volatile memory. The embodiment of the processing device of the firmware upgrade package can be realized by software, or can be realized by hardware or a combination of the software and the hardware. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. In terms of hardware, as shown in fig. 4b, the hardware structure diagram of the electronic device in which the processing apparatus of the firmware upgrade package is located is shown in fig. 4b, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 4b, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to the actual function of the electronic device, which is not described again. In some examples, a processor is coupled to the memory for reading program instructions stored by the memory and, in response, performing the following:

As an example, the instructions for instructing to operate the source file may include at least one of: the method comprises a source file replacing instruction, a source file recovering instruction and a source file deleting instruction.

When the processor modifies the information in the index node of the source file according to the upgrade instruction, the executed operation may be to mark a path for replacing a patch file of the source file in the index node of the source file according to the replace source file instruction; and the patch file is downloaded through a firmware upgrade package and stored in the data partition.

In some examples, the operations performed by the processor may further include: and receiving an instruction for opening the source file, and reading a corresponding patch file according to the label in the index node of the source file.

When the processor modifies the information in the index node of the source file according to the upgrade instruction, the existing label can be deleted in the index node of the source file according to the file recovery instruction; the annotation includes a first identifier, generated in response to instructions of the other firmware upgrade package, indicating that the source file is unavailable. In addition, the processor can also execute the operation of receiving an instruction for opening the source file and opening the source file according to the index node of the source file.

In some examples, the processor executing the operation of modifying the information in the inode of the source file according to the upgrade instruction may further be: according to the source file deleting instruction, setting a first identifier in an index node of the source file, wherein the first identifier is used for indicating that the source file is unavailable.

Additionally, the processor may perform operations further comprising: and receiving an instruction for opening the source file, and refusing to open the source file according to the first identifier in the index node of the source file.

The operations that the processor may perform further include: and after reading the patch file, detecting whether the process using the patch file is abnormal, and if so, deleting the firmware upgrade package.

The operations that the processor may perform further include: before receiving an instruction for opening the source file, if the process using the source file is determined to be in a non-idle state and the process can be restarted, the process is ended and restarted.

As an example, instructions for instructing to operate a source file may be stored in an upgrade package description file of a firmware upgrade package; the processor may perform operations further comprising:

receiving an instruction for deleting the firmware upgrade package, and marking a patch file to be deleted in the upgrade package description file;

replacing or deleting the path of the patch file marked in the index node;

and deleting operation is carried out according to the using state of the patch file, wherein the deleting operation comprises deleting the patch file and/or deleting the upgrade patch description file.

As an example, when the processor performs the deleting operation according to the use state of the patch file, the performed operation may include at least one of:

if the patch file is not used, deleting operation is carried out;

if the patch file is being used and the process using the patch file can be restarted, closing the process, and restarting the process after executing deletion operation;

and if the patch file is being used and the process using the patch file cannot be restarted, prompting to restart the equipment, and carrying out deletion operation after restarting the equipment.

Referring to fig. 5, aprocessing apparatus 500 for a firmware upgrade package includes:

acommunication module 501, configured to read an upgrade instruction, where the upgrade instruction includes an instruction for instructing to operate a source file, where the source file is a file already existing in a system;

aprocessing module 502, configured to modify information in an index node of the source file according to the upgrade instruction; the information in the inode includes a path to read the source file.

Theprocessing module 502 in some examples, modifying information in the inode of the source file according to the upgrade instruction, may include:

according to the source file replacing instruction, marking a path for replacing a patch file of the source file in an index node of the source file; and the patch file is downloaded through a firmware upgrade package and stored in the data partition.

Theprocessing module 502 may further receive an instruction to open the source file, and read a corresponding patch file according to a label in an inode of the source file.

In some examples, the modifying, by theprocessing module 502, information in the index node of the source file according to the upgrade instruction may include:

deleting existing labels in the index nodes of the source file according to the file recovery instruction; the annotation includes a first identifier, generated in response to instructions of the other firmware upgrade package, indicating that the source file is unavailable.

Theprocessing module 502 may also receive an instruction to open the source file and open the source file according to the inode of the source file.

according to the source file deleting instruction, setting a first identifier in an index node of the source file, wherein the first identifier is used for indicating that the source file is unavailable.

Theprocessing module 502 may also receive an instruction to open the source file, denying opening the source file according to the first identification in the inode of the source file.

After reading the patch file, theprocessing module 502 may further detect whether there is an abnormality in the process using the patch file, and if there is an abnormality, delete the firmware upgrade package.

In addition, theprocessing module 502 may also end and restart the process after determining that the process using the source file is in a non-idle state and determining that the process is rebooteable, before receiving the instruction to open the source file.

As an example, the upgrade instruction is stored in an upgrade package description file of a firmware upgrade package;

theprocessing module 502 may further receive an instruction to delete the firmware upgrade package, and mark the patch file to be deleted in the upgrade package description file;

replacing or deleting the path of the patch file marked in the index node;

As an example, theprocessing module 502 performs a deletion operation according to the use status of the patch file, including at least one of the following:

if the patch file is not used, deleting operation is carried out;

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.