System updating method and device, electronic equipment, storage medium and computer program product

Abstract

The invention relates to a system updating method and device, electronic equipment, a storage medium and a computer program product. The method comprises the steps that a first system updating request sent by a terminal is received; obtaining a target storage position of a target version system indicated by the system version mark information on the server; obtaining a release file of the target version system; the release time contained in the release file is modified into the current time of the server; and sending the modified release file and the target storage position to the terminal. Therefore, the system updating is performed based on the system version with the latest release time, the latest creation time and the latest current moment, so that the creation time of the target version system contained in the release file can be modified into the current time from the original time, and the system updating efficiency is improved. According to the method, the time after modification is certainly longer than the system release time cached in the terminal, so that the version system returned each time can be ensured to take effect.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and more particularly, to a system updating method, device, electronic device, storage medium and computer program product. Background Art

[0002] When the Advanced Packaging Tool (APT) manages software, it obtains the index information of the software warehouse from the server and compares the release time of the software warehouse contained in the index information with the release time of the software warehouse cached locally on the terminal. If the release time of the software warehouse contained in the index information is earlier than the local time, the index information will be discarded. This mechanism will cause the system to be completely locked or unable to be locked at a certain stage, where "the system is completely locked" means that the system cannot be upgraded even if it is enabled.

[0003] In order to solve the above problem, in the related art, when each version of the software warehouse is updated, the release time of all subsequent versions will be updated synchronously, that is, the release time of all versions updated than the current version will be updated synchronously, so as to always maintain the release time of the later version later. However, each time a version update is required, the release time of all subsequent versions needs to be updated synchronously, that is, all versions updated than the current version need to be rebuilt, which leads to a large workload for system update and low update efficiency. Summary of the invention

[0004] The present disclosure provides a system update method, device, electronic device, storage medium and computer program product to at least solve the problem of large workload and low update efficiency of system update in the above-mentioned related technologies.

[0005] According to a first aspect of an embodiment of the present disclosure, a system update method is provided, which is applied to a server and includes: receiving a first system update request sent by a terminal, wherein the first system update request includes system version flag information; obtaining a target storage location of a target version system indicated by the system version flag information on the server; obtaining a release file of the target version system, wherein the release file includes a release time of the target version system; modifying the release time included in the release file to the current time of the server to obtain a modified release file; and sending the modified release file and the target storage location to the terminal, wherein the modified release file and the target storage location are used to enable the terminal to obtain the target version system from the server.

[0006] Optionally, obtaining the release file of the target version system includes: determining a target type of the target storage location; and obtaining the release file based on the target type.

[0007] Optionally, after modifying the release time contained in the release file to the current time of the server and obtaining the modified release file, the system update method further includes: signing the modified release file to obtain signature information; and sending the signature information to the terminal.

[0008] Optionally, acquiring the release file based on the target type includes: when the target type ends with InRelease, acquiring the release file from the target storage location.

[0009] Optionally, the step of modifying the release time contained in the release file to the current time of the server to obtain the modified release file includes: parsing the release file to obtain a first content, wherein the first content includes the release time; modifying the release time contained in the first content to the current time of the server to obtain a second content; performing GPG signing on the second content to obtain the signature information; and sending the modified release file and the target storage location to the terminal includes: sending the second content, the signature information and the target storage location to the terminal.

[0010] Optionally, obtaining the release file based on the target type includes: when the target type ends with Release, determining whether a release file of the target version system that has not expired is currently cached in the server; when the release file that has not expired is currently cached in the server, extracting the cached release file that has not expired; when the release file that has not expired is not currently cached in the server, obtaining the release file from the target storage location.

[0011] Optionally, the system update method also includes: receiving a second system update request sent by the terminal, wherein the second system update request is sent by the terminal to the server after the terminal receives a third content, wherein the third content is obtained by the server parsing the release file to obtain a fourth content, and then modifying the release time of the target version system contained in the fourth content to the current time of the server; in response to the second system update request, determining whether the third content is currently cached in the server; if it is determined that the third content is currently cached in the server, performing GPG signing on the third content, obtaining the signature information, and sending the signature information to the terminal; if it is determined that the third content is not currently cached in the server, sending an error prompt message to the terminal.

[0012] According to a second aspect of an embodiment of the present disclosure, a system update method is provided, which is applied to a terminal, and includes: sending a first system update request to a server, wherein the first system update request includes system version flag information; receiving a modified release file and a target storage location sent by the server, wherein the target storage location is a storage location of a target version system indicated by the system version flag information on the server, and the modified release file is a file obtained by modifying the release time of the target version system included in the release file to the current time of the server after the server obtains the release file of the target version system; comparing the current time included in the modified release file with the system release time cached in the terminal, wherein the cached system release time is the release time of the version system obtained by the terminal in a request previous to this request; and when the current time is greater than the cached system release time, pulling and installing the target version system from the target storage location of the server.

[0013] Optionally, before comparing the current time contained in the modified release file with the system release time cached in the terminal, the system update method also includes: receiving signature information sent by the server, wherein the signature information is signature information obtained by the server signing the modified release file; comparing the current time contained in the modified release file with the system release time cached in the terminal includes: performing signature verification using the signature information; if the signature verification passes, comparing the current time contained in the modified release file with the system release time cached in the terminal.

[0014] Optionally, the receiving the modified release file and target storage location sent by the server includes: receiving second content, signature information and the target storage location sent by the server, wherein the second content is obtained by the server, upon determining that the target type of the target storage location ends with InRelease, obtaining the release file from the target storage location, parsing the release file, and after obtaining the first content, modifying the release time contained in the first content to the current time of the server, and the signature information is signature information obtained by the server performing GPG signing on the second content; comparing the current time contained in the modified release file with the system release time cached in the terminal includes: comparing the current time contained in the second content with the system release time cached in the terminal.

[0015] Optionally, the receiving the modified release file and the target storage location sent by the server includes: receiving third content sent by the server and the target storage location, wherein the third content is obtained by the server parsing the acquired release file to obtain fourth content, and then modifying the release time of the target version system contained in the fourth content to the current time of the server; the system update method also includes: sending a second system update request to the server; receiving signature information sent by the server in response to the second system update request, wherein the signature information is the signature information obtained by the server determining whether the third content is currently cached in the server, and performing GPG signature on the third content when the server determines that the third content is currently cached in the server; comparing the current time contained in the modified release file with the system release time cached in the terminal includes: comparing the current time contained in the third content with the system release time cached in the terminal; the system update method also includes: receiving error prompt information sent by the server, wherein the error prompt information is sent to the terminal when the server determines that the third content is not currently cached in the server.

[0016] According to a third aspect of an embodiment of the present disclosure, a system update device is provided, which is applied to a server and includes: a first request receiving module, configured to receive a first system update request sent by a terminal, wherein the first system update request includes system version flag information; a storage location acquisition module, configured to obtain a target storage location of a target version system indicated by the system version flag information on the server; a release file acquisition module, configured to obtain a release file of the target version system, wherein the release file includes a release time of the target version system; a time modification module, configured to modify the release time included in the release file to the current time of the server to obtain a modified release file; a release file and storage location sending module, configured to send the modified release file and the target storage location to the terminal, wherein the modified release file and the target storage location are used to enable the terminal to obtain the target version system from the server.

[0017] Optionally, the release file acquisition module is configured to: determine a target type of the target storage location; and acquire the release file based on the target type.

[0018] Optionally, the system updating device further includes: a signature module configured to sign the modified release file to obtain signature information; and a signature information sending module configured to send the signature information to the terminal.

[0019] Optionally, the release file acquisition module is configured to: when the target type ends with InRelease, acquire the release file from the target storage location.

[0020] Optionally, the time modification module is configured to: parse the release file to obtain first content, wherein the first content includes the release time; modify the release time included in the first content to the current time of the server to obtain second content; perform GPG signing on the second content to obtain the signature information; the release file and storage location sending module is configured to: send the second content, the signature information and the target storage location to the terminal.

[0021] Optionally, the release file acquisition module is configured to: when the target type ends with Release, determine whether the server currently has a release file of the target version system that has not expired; when the server currently has a release file that has not expired, extract the cached release file that has not expired; when the server currently has no release file that has not expired, acquire the release file from the target storage location.

[0022] Optionally, the system update device further includes: a second request receiving module, configured to receive a second system update request sent by the terminal, wherein the second system update request is sent by the terminal to the server after the terminal receives a third content, wherein the third content is obtained by the server parsing the release file to obtain a fourth content and then modifying the release time of the target version system contained in the fourth content to the current time of the server; a judgment module, configured to judge whether the third content is currently cached in the server in response to the second system update request; a GPG signature module, configured to perform GPG signature on the third content to obtain the signature information if it is judged that the third content is currently cached in the server; a GPG signature information sending module, configured to send the signature information to the terminal; and an error prompt information sending module, configured to send an error prompt information to the terminal if it is judged that the third content is not currently cached in the server.

[0023] According to a fourth aspect of an embodiment of the present disclosure, there is provided a system update device, which is applied to a terminal and includes: a first request sending module, configured to send a first system update request to a server, wherein the first system update request includes system version flag information; a storage location receiving module, configured to receive a modified release file and a target storage location sent by the server, wherein the target storage location is a storage location of a target version system indicated by the system version flag information on the server, and the modified release file is a file obtained by modifying the release time of the target version system included in the release file to the current time of the server after the server obtains the release file of the target version system; a comparison module, configured to compare the current time included in the modified release file with the system release time cached in the terminal, wherein the cached system release time is the release time of the version system obtained by the terminal in the previous request of this request; and a pulling module, configured to pull and install the target version system from the target storage location of the server when the current time is greater than the cached system release time.

[0024] Optionally, the system update device also includes: a signature information receiving module, configured to receive signature information sent by the server, wherein the signature information is signature information obtained by the server signing the modified release file; the comparison module is configured to: perform signature verification using the signature information; if the signature verification passes, compare the current time contained in the modified release file with the system release time cached in the terminal.

[0025] Optionally, the storage location receiving module is configured to: receive the second content, signature information and the target storage location sent by the server, wherein the second content is the server obtaining the release file from the target storage location when determining that the target type of the target storage location ends with InRelease, parsing the release file, and after obtaining the first content, modifying the release time contained in the first content to the current time of the server; the comparison module is configured to: compare the current time contained in the second content with the system release time cached in the terminal.

[0026] Optionally, the storage location receiving module is configured to: receive the third content sent by the server and the target storage location, wherein the third content is obtained by the server parsing the acquired release file to obtain the fourth content, and then modifying the release time of the target version system contained in the fourth content to the current time of the server; the system update device also includes: a second request sending module, configured to send a second system update request to the server; a GPG signature information receiving module, configured to receive signature information sent by the server in response to the second system update request, wherein the signature information is the signature information obtained by the server determining whether the third content is currently cached in the server, and performing GPG signature on the third content when the server determines that the third content is currently cached in the server; the comparison module is configured to: compare the current time contained in the third content with the system release time cached in the terminal; the system update device also includes: an error prompt information receiving module, configured to receive error prompt information sent by the server, wherein the error prompt information is sent to the terminal when the server determines that the third content is not currently cached in the server.

[0027] According to a fifth aspect of an embodiment of the present disclosure, there is provided an electronic device, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a system update method according to the present disclosure.

[0028] According to a sixth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the system update method according to the present disclosure.

[0029] According to a seventh aspect of an embodiment of the present disclosure, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the system update method according to the present disclosure is implemented.

[0030] Since the system update in the technical solution provided by the embodiment of the present disclosure is based on the latest release time, that is, the latest creation time, that is, the system version closest to the current moment, the creation time of the target version system contained in the release file can be modified from the original time to the current time. In this way, it can be guaranteed that the modified time must be greater than the system release time cached in the terminal, and thus it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version update is carried out according to the actual needs of the user, that is, it can be achieved at any time to completely prohibit the system update or restore the system update according to the actual needs of the user. In addition, it can also avoid the cumbersome operation process of synchronously updating the release time of all subsequently released versions every time a version update is required, which can reduce the workload of system updates and improve the efficiency of system updates.

[0031] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute improper limitations on the present disclosure.

[0033] Figure 1 is a schematic diagram showing that a complete version lock is performed and a system update cannot be performed in the related art;

[0034] Figure 2 is a flowchart illustrating a system updating method according to an exemplary embodiment of the present disclosure;

[0035] Figure 3 is a flowchart illustrating a system updating method according to an exemplary embodiment of the present disclosure;

[0036] Figure 4 is a specific implementation flow chart showing a system update method according to an exemplary embodiment of the present disclosure;

[0037] Figure 5 is a specific implementation flowchart showing how to obtain the second content and signature information when the type of the resource address is "ending with InRelease" according to an exemplary embodiment of the present disclosure;

[0038] Figure 6 is a specific implementation flow chart showing how to obtain the third content M3 when the type of the resource address is "ending with Release" according to an exemplary embodiment of the present disclosure;

[0039] Figure 7is a specific implementation flow chart showing that a server acquires signature information or error prompt information based on a second system update request according to an exemplary embodiment of the present disclosure;

[0040] Figure 8 is a specific implementation flow chart showing that a terminal pulls and installs a target version system or downloads a file from a target storage location of a server according to an exemplary embodiment of the present disclosure;

[0041] Fig. 9 is a block diagram illustrating a system updating apparatus according to an exemplary embodiment of the present disclosure;

[0042] Fig.10 is a block diagram illustrating another system updating apparatus according to an exemplary embodiment of the present disclosure;

[0043] Fig.11 is a block diagram illustrating an electronic device according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0044] In order to enable ordinary persons in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings.

[0045] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The implementation methods described in the following examples do not represent all implementation methods consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the attached claims.

[0046] It should be noted that the phrase "at least one of the items" in the present disclosure includes three types of parallel situations: "any one of the items", "a combination of any number of the items", and "all of the items". For example, "including at least one of A and B" includes the following three parallel situations: (1) including A; (2) including B; (3) including A and B. Another example is "executing at least one of step 1 and step 2" which means the following three parallel situations: (1) executing step 1; (2) executing step 2; (3) executing step 1 and step 2.

[0047] In the related art, the system version is mainly locked and restarted through the update platform in conjunction with the software management tool (apt). However, every time a version update is required, the release time of all subsequent versions needs to be updated synchronously, that is, all versions newer than the current version need to be rebuilt, which results in a large workload for system updates and low update efficiency.

[0048] Figure 1 It is a schematic diagram showing that a complete version lock is performed and a system update cannot be performed in the related art.

[0049] Reference Figure 1 , a total of 6 system versions are shown, namely version 1032, version 1040, version 1041, version 1042, empty warehouse version and version 1050, wherein these system versions are arranged in the order of release time as follows: version 1032--version 1040--version 1041--version 1042--empty warehouse version--version 1050. In addition, "empty warehouse version" means that the warehouse does not contain any content, that is, the "empty warehouse version" can lock the system version of the terminal to the current version of the terminal system. It should be noted that the "warehouse" in the present disclosure may refer to a "software package warehouse", which may contain a lot of software. Moreover, the release time of the warehouse may also be referred to as the build time of the warehouse.

[0050] Reference Figure 1 , assuming that the system version of terminal A is between version 1032 and version 1040, and the system version of terminal B is between version 1041 and version 1042. If you want to completely lock the versions of terminal A and terminal B, that is, completely prohibit system updates, then Figure 1 The location of the "empty warehouse version" in can meet this requirement. This is because the system update is based on the system version with the latest release time, that is, the latest creation time, that is, the most recent current moment. Since the release time of the "empty warehouse version" is later than the release time of the current system version of terminal A and the release time of the current system version of terminal B, both terminal A and terminal B need to be updated based on the "empty warehouse version" with the latest release time. And, as mentioned above, the "empty warehouse version" means that the warehouse does not contain any content, that is, the "empty warehouse version" can lock the system version of the terminal to the current version of the terminal system. Therefore, at this time, complete version locking can be achieved for terminal A and terminal B, that is, the system versions of terminal A and terminal B can be locked to their respective current system versions.

[0051] However, if you want to unlock the versions for Terminal A and Terminal B, for example, you want to upgrade the system version of Terminal A to Version 1042, and you want to upgrade the system version of Terminal B to Version 1050. At this time, since the release time of the "empty warehouse version" is later than Version 1042 and earlier than Version 1050, Terminal B can be unlocked based on Version 1050, which has the latest release time, to upgrade to Version 1050; while for Terminal A, since the release time of the "empty warehouse version" is later than that of Version 1042, Terminal A can only be locked in its current system version based on the "empty warehouse version" with a later release time, that is, Terminal A cannot be unlocked at this time.

[0052] In order to solve the above-mentioned problems existing in the related art, the system update method, device, electronic device, storage medium and computer program product provided by the present disclosure are that since the system update is based on the latest release time, that is, the latest creation time, that is, the system version closest to the current moment, the creation time of the target version system contained in the release file can be modified from the original time to the current time. In this way, it can be guaranteed that the modified time must be greater than the system release time cached in the terminal, and then it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version update is carried out according to the actual needs of the user, that is, it can be realized at any time to completely prohibit the system update or restore the system update according to the actual needs of the user. In addition, it can also avoid the cumbersome operation process of synchronously updating the release time of all subsequently released versions every time a version update is required, which can reduce the workload of system updates and improve the efficiency of system updates.

[0053] The following are the meanings of some terms involved in this disclosure:

[0054] "Debian": Debian GNU / Linux, an operating system and free software distribution; "aptly": a Debian repository management tool; "repository": a file server that provides software downloads based on certain rules; "apt": a software management tool; "GPG": GnuPG, an information signing and encryption software (algorithm); "Packages": a special file in the repository that describes the basic information of the software in the repository; "Release": a special file in the repository, mainly including the summary information of the Packages file in the repository and the basic information of the repository, among which the "basic information of the repository" may include but is not limited to: the release time and publisher of the repository version, etc.; "InRelease": the file after the Release file is signed by GPG, including the Release file content itself and the signature information.

[0055] Next, we will combine Figure 2 to Figure 8 The implementation process of the system update disclosed in the present invention is specifically described.

[0056] Figure 2 is a flowchart illustrating a system updating method according to an exemplary embodiment of the present disclosure, which is applied to a server.

[0057] Reference Figure 2 In step 201, a first system update request sent by a terminal may be received, wherein the first system update request may include system version flag information.

[0058] In step 202, the target storage location of the target version system indicated by the system version mark information on the server can be obtained, wherein the "target storage location" can also be referred to as a "resource address". It should be noted that a warehouse L with a minimum version number can be created on the server, and all subsequent system version updates can be performed based on the warehouse L with the minimum version number.

[0059] In step 203, a release file of the target version system may be obtained, wherein the release file may include the release time of the target version system.

[0060] According to an exemplary embodiment of the present disclosure, the target type of the target storage location may be determined, and then the release file may be obtained based on the target type, wherein the “target type” may be “ending with InRelease”, “ending with Release”, and so on.

[0061] According to an exemplary embodiment of the present disclosure, when the target type is "ending with InRelease", the release file may be acquired from the target storage location.

[0062] According to an exemplary embodiment of the present disclosure, when the target type ends with Release, it can be determined whether the server currently has cached release files of the target version system that have not expired, that is, it can be determined whether the server currently has cached release files of the target version system that have not expired and that the current terminal has requested in the history of this request.

[0063] If there is a release file that has not expired currently cached in the server, that is, if there is a release file that has not expired of the target version system that the current terminal has requested in the historical process of this request currently cached in the server, the cached release file that has not expired can be extracted; if there is no release file that has not expired currently cached in the server, the release file can be obtained from the target storage location.

[0064] In step 204, the release time of the target version system contained in the release file may be modified to the current time of the server to obtain a modified release file.

[0065] According to an exemplary embodiment of the present disclosure, the modified release file may be signed to obtain signature information, and then the signature information may be sent to the terminal.

[0066] According to an exemplary embodiment of the present disclosure, when the target type of the above-mentioned target storage location ends with Inrelease, the release file can be parsed to obtain the first content M1, wherein the first content M1 can include the release time of the target version system. Next, the release time of the target version system included in the first content M1 can be modified to the current time of the server to obtain the second content M2. Then, the second content M2 can be GPG signed to obtain signature information. Next, the second content M2, the signature information and the above-mentioned target storage location can be sent to the terminal. That is, the GPG signature algorithm can be called for the second content M2 to generate the signature information, and then the second content M2 and the signature information can be directly returned to the terminal as an InRelease file.

[0067] According to an exemplary embodiment of the present disclosure, when the target type of the target storage location ends with Release, a second system update request sent by the terminal can also be received, wherein the "second system update request" can be sent by the terminal to the server after the terminal receives the third content M3, wherein the "third content M3" can be the content obtained by modifying the release time of the target version system contained in the fourth content M4 to the current time of the server after the server parses the release file to obtain the fourth content M4. That is, the above-mentioned "second system update request" can be sent by the terminal to the server after the terminal receives the valid third content M3.

[0068] Next, in response to the second system update request, it can be determined whether the server currently caches the third content M3. If it is determined that the server currently caches the third content M3, a GPG signature can be performed on the third content to obtain signature information, and the signature information can be sent to the terminal; otherwise, that is, if it is determined that the server currently does not cache the third content M3, an error prompt message can be sent to the terminal.

[0069] In step 205, the modified release file and the target storage location may be sent to the terminal, wherein the modified release file and the target storage location are used to enable the terminal to obtain the target version system from the server.

[0070] In the present disclosure, since the system update is based on the latest release time, that is, the latest creation time, that is, the system version closest to the current moment, the creation time of the target version system contained in the release file can be modified from the original time to the current time. In this way, it can be guaranteed that the modified time must be greater than the system release time cached in the terminal, and thus it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version update is carried out according to the actual needs of the user, that is, it can be achieved at any time to completely prohibit the system update or restore the system update according to the actual needs of the user. In addition, it can also avoid the cumbersome operation process of synchronously updating the release time of all subsequently released versions every time a version update is required, which can reduce the workload of system updates and improve the efficiency of system updates.

[0071] Figure 3 is a flowchart illustrating a system updating method according to an exemplary embodiment of the present disclosure, which is applied to a terminal.

[0072] Reference Figure 3 In step 301, a first system update request may be sent to a server, wherein the first system update request may include system version mark information.

[0073] In step 302, the modified release file and target storage location sent by the server may be received, wherein the "target storage location" may be the storage location of the target version system on the server indicated by the system version mark information; the above-mentioned "modified release file" may be a file obtained by modifying the release time of the target version system contained in the release file to the current time of the server after the server obtains the release file of the target version system.

[0074] According to an exemplary embodiment of the present disclosure, signature information sent by the server may also be received, wherein the signature information may be signature information obtained by the server signing the modified release file. Then, the signature information may be used to perform signature verification. If the signature verification passes, the current time contained in the modified release file may be compared with the system release time cached in the terminal.

[0075] In this way, by using the signature information to perform signature verification, it can be determined whether the information sent by the server to the terminal has been tampered with, thereby ensuring the security of information transmission.

[0076] In step 303, the current time contained in the above-mentioned "modified release file" can be compared with the system release time cached in the terminal, wherein the "cached system release time" can be the release time of the version system obtained by the terminal in the previous request of this request.

[0077] According to an exemplary embodiment of the present disclosure, the second content M2, signature information and target storage location sent by the server can be received, wherein the "second content M2" can be obtained by the server obtaining a release file from the target storage location when determining that the target type of the target storage location ends with InRelease, parsing the release file, and obtaining the first content M1, and then modifying the release time of the target version system contained in the first content M1 to the current time of the server. The above-mentioned "signature information" can be the signature information obtained by the server performing a GPG signature on the "second content M2".

[0078] Next, the signature information can be used to perform signature verification, that is, the signature information can be used to determine whether the "second content M2" has been tampered with. If the signature verification passes, that is, if it is determined that the "second content M2" has not been tampered with, the current time contained in the "second content M2" can be compared with the system release time cached in the terminal.

[0079] According to an exemplary embodiment of the present disclosure, a third content M3 and a target storage location sent by a server can be received, wherein the "third content M3" can be obtained by modifying the release time of the target version system contained in the fourth content M4 to the current time of the server after the server parses the acquired release file to obtain the fourth content M4.

[0080] When the terminal receives a valid "third content M3", it can also send a second system update request to the server. Then, the terminal can receive the signature information sent by the server in response to the second system update request, wherein the "signature information" can be used for the server to determine whether the "third content M3" is currently cached in the server, and when it is determined that the "third content M3" is currently cached in the server, the signature information obtained by performing GPG signature on the "third content M3". Next, the terminal can use the signature information to perform signature verification. And, when the signature verification passes, the current time contained in the "third content M3" can be compared with the system release time cached in the terminal.

[0081] Alternatively, the terminal may also receive error prompt information sent by the server, wherein the “error prompt information” may be sent to the terminal when the server determines that the “third content M3” is not currently cached in the server.

[0082] In step 304, when the current time is greater than the cached system release time, the target version system can be pulled from the target storage location of the server and installed.

[0083] In the present disclosure, by creating a warehouse with the lowest version number and recalculating the file content, that is, recalculating the warehouse build time, it can be ensured that the time after recalculation must be greater than the system release time cached in the terminal, and thus it can be ensured that each returned version system will take effect. That is, it can be guaranteed that the version is updated according to the actual needs of the user, that is, the effect of completely prohibiting system updates or restoring system updates according to the actual needs of the user at any time can be achieved.

[0084] Figure 4 is a flowchart showing a specific implementation of a system updating method according to an exemplary embodiment of the present disclosure.

[0085] Reference Figure 4 In step 401, a warehouse L with a minimum version number may be created on the server, wherein all subsequent system version updates may be performed based on the warehouse L with the minimum version number.

[0086] In step 402, the terminal may send a first system update request to the server, wherein the first system update request may include system version mark information.

[0087] In step 403, the first system update request is forwarded to the update platform through the proxy server.

[0088] In step 404, the update platform performs a policy calculation based on the system version mark information included in the first system update request, and obtains the target storage location of the target version system indicated by the system version mark information on the server, that is, the resource address.

[0089] In step 405, when the target version system indicated by the above "system version mark information" is the lowest version system L, the system version of the terminal can be changed to the lowest system version L, and at this time, the system update is completely prohibited for the terminal.

[0090] In step 406, when the target version system indicated by the above-mentioned "system version mark information" is the current version system of the terminal, the system version of the terminal can be locked to the current system version of the terminal.

[0091] In step 407, when the target version system indicated by the above-mentioned "system version mark information" is a specified system version, the system version of the terminal can be upgraded to the specified system version.

[0092] It should be noted that "upgrading the system version" may refer to upgrading the software in the warehouse or adding new software to the warehouse.

[0093] In step 408, when the target type of the target storage location is "ending with InRelease", that is, when the type of the resource address is "ending with InRelease", the second content, signature information and the target storage location may be sent to the terminal.

[0094] Specifically, Figure 5 1 is a specific implementation flowchart showing how to obtain the second content and signature information when the type of the resource address is “ending with InRelease” according to an exemplary embodiment of the present disclosure.

[0095] Reference Figure 5 In step 4081, when the target type of the target storage location is "ending with InRelease", the release file can be obtained from the above target storage location.

[0096] In step 4082, the release file obtained in step 4081 may be parsed to obtain the first content M1, wherein the first content M1 may include the release time of the target version system.

[0097] In step 4083, the release time of the target version system included in the first content M1 may be modified to the current time of the server to obtain the second content M2.

[0098] In step 4084, a GPG signature may be performed on the second content M2 to obtain signature information.

[0099] In step 4085, the second content M2, signature information and the target storage location may be sent to the terminal. That is, the GPG signature algorithm may be called for the second content M2 to generate signature information, and then the second content M2 and signature information may be directly returned to the terminal as an InRelease file.

[0100] In step 409, when the target type of the target storage location is "ending with Release", that is, when the type of the resource address is "ending with Release", the third content M3 may be sent to the terminal.

[0101] Specifically, Figure 61 is a specific implementation flowchart showing how to obtain the third content M3 when the type of the resource address is “ending with Release” according to an exemplary embodiment of the present disclosure.

[0102] Reference Figure 6 In step 4091, when the target type of the target storage location is "ending with Release", that is, when the type of the resource address is "ending with Release", it can be determined whether the server currently has cached third content M3 of the target version system that has been requested by the current terminal in the historical process of this request and has not expired, and a first judgment result is obtained, wherein the third content M3 may include the modified release time of the target version system requested in the previous request process of this system update request.

[0103] In step 4092, if the server currently caches the third content M3 of the target version system that has been requested by the current terminal in the history of this system update request and has not expired, the third content M3 can be directly returned to the terminal.

[0104] In step 4093, if the server does not currently cache the third content M3 of the target version system that has been requested by the current terminal in the history of this system update request and has not expired, the release file can be obtained from the above target storage location.

[0105] In step 4094, the release file obtained in step 4093 is parsed to obtain the fourth content M4.

[0106] In step 4095, the release time of the target version system included in the fourth content M4 is modified to the current time of the server to obtain the third content M3.

[0107] In step 4096, the third content M3 obtained in step 4095 is associated with the identification information of the current terminal and cached to obtain cached content C1, wherein the "current terminal" refers to the terminal that initiates the first system update request this time.

[0108] In step 4097, the third content M3 obtained in step 4095 is sent to the terminal.

[0109] In step 4010, after receiving the valid third content M3, the terminal sends a second system update request to the server. And the server returns signature information or error prompt information to the terminal based on the received second system update request.

[0110] Specifically, Figure 7It is a specific implementation flow chart showing that a server acquires signature information or error prompt information based on a second system update request according to an exemplary embodiment of the present disclosure.

[0111] Reference Figure 7 In step 40101, the server receives a second system update request sent by the terminal.

[0112] In step 40102, the server determines whether the third content M3 is currently cached in the server based on the received second system update request. If it is determined that the third content M3 is currently cached in the server, step 40103 and step 40104 are executed; otherwise, that is, if it is determined that the third content M3 is not currently cached in the server, step 40105 is executed.

[0113] In step 40103, a GPG signature is performed on the third content M3 obtained in step 40102 to obtain signature information.

[0114] In step 40104, the signature information obtained in step 40103 is sent to the terminal.

[0115] In step 40105, an error prompt message is sent to the terminal.

[0116] In step 4011, when the target type of the target storage location is not "ending with Release" or "ending with InRelease", the target storage location, ie, the resource address, is directly returned to the terminal.

[0117] In step 4012, the terminal performs signature verification based on the received signature information, and if the signature verification passes, pulls and installs the target version system or downloads the file from the target storage location of the server based on the received target storage location.

[0118] Specifically, Figure 8 It is a specific implementation flow chart showing that a terminal pulls and installs a target version system or downloads a file from a target storage location of a server according to an exemplary embodiment of the present disclosure.

[0119] Reference Figure 8 In step 40121, the terminal determines whether the target type of the received target storage location is "ending with InRelease" or "ending with Release". If it is determined that the target type of the target storage location is "ending with InRelease" or "ending with Release", step 40122 and step 40123 are executed; otherwise, that is, if it is determined that the target type of the target storage location is not "ending with InRelease" or "ending with Release", step 40124 is executed.

[0120] In step 40122, the terminal compares the time contained in the received second content M2 or third content M3 with the system release time cached in the terminal. If the time contained in the second content M2 or third content M3 is greater than the system release time cached in the terminal, step 40123 is executed.

[0121] In step 40123, the terminal pulls and installs the target version system from the target storage location of the server based on the target storage location.

[0122] In step 40124, the terminal pulls and caches the file from the target storage location of the server based on the target storage location.

[0123] It should be noted that in this embodiment, when performing a system update, the update program will first obtain the InRelease file in the warehouse, that is, the InRelease file has the highest priority. If the InRelease file is not obtained from the warehouse, the Release file will be obtained, and the signature information, that is, the Release.gpg file, will be requested after obtaining a valid Release file.

[0124] In the present disclosure, by constructing the lowest version warehouse L, the effect of completely prohibiting system updates can be achieved; and by recalculating the file content, that is, recalculating the warehouse construction time, it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version is updated according to the actual needs of the user, that is, it can be achieved at any time to completely prohibit system updates or restore system updates according to the actual needs of the user. In addition, the release of the warehouse no longer needs to care about the release time, that is, the impact of the generation time, but only needs to pay attention to the content of the warehouse.

[0125] Fig. 9 is a block diagram showing a system updating apparatus 900 according to an exemplary embodiment of the present disclosure, which is applied to a server.

[0126] Reference Fig. 9 The system updating device 900 may include a first request receiving module 901, a storage location obtaining module 902, a release file obtaining module 903, a time modification module 904 and a release file and storage location sending module 905.

[0127] The first request receiving module 901 may receive a first system update request sent by a terminal, wherein the first system update request may include system version flag information.

[0128] The storage location acquisition module 902 can obtain the target storage location of the target version system indicated by the above system version mark information on the server, where the "target storage location" can also be called a "resource address". It should be noted that a warehouse L with a minimum version number can be created on the server, and all subsequent system version updates can be performed based on the warehouse L with the minimum version number.

[0129] The release file acquisition module 903 may acquire the release file of the target version system, wherein the release file may include the release time of the target version system.

[0130] According to an exemplary embodiment of the present disclosure, the release file acquisition module 903 can determine the target type of the target storage location, and then acquire the release file based on the target type, wherein the "target type" can be "ending with InRelease", "ending with Release", etc.

[0131] According to an exemplary embodiment of the present disclosure, when the target type is "ending with InRelease", the release file acquisition module 903 may acquire the release file from the above target storage location.

[0132] According to an exemplary embodiment of the present disclosure, when the target type ends with Release, the release file acquisition module 903 can determine whether the server currently has cached release files of the target version system that have not expired, that is, it can determine whether the server currently has cached release files of the target version system that have not expired and have been requested by the current terminal in the historical process of this request.

[0133] When there is a release file that has not expired currently cached in the server, that is, when there is a release file that has not expired of the target version system that the current terminal has requested in the historical process of this request currently cached in the server, the release file acquisition module 903 can extract the cached release file that has not expired; when there is no release file that has not expired currently cached in the server, the release file acquisition module 903 can obtain the release file from the target storage location.

[0134] The time modification module 904 can modify the release time of the target version system contained in the release file to the current time of the server to obtain a modified release file.

[0135] According to an exemplary embodiment of the present disclosure, the system updating device 900 may further include a signature module and a signature information sending module.

[0136] The signature module can sign the modified release file to obtain signature information, and then the signature information sending module can send the signature information to the terminal.

[0137] According to an exemplary embodiment of the present disclosure, when the target type of the above-mentioned target storage location ends with Inrelease, the time modification module 904 can parse the release file to obtain the first content M1, wherein the first content M1 can include the release time of the target version system. Next, the time modification module 904 can modify the release time of the target version system included in the first content M1 to the current time of the server to obtain the second content M2. Then, the time modification module 904 can perform GPG signing on the second content M2 to obtain signature information. Next, the release file and storage location sending module 905 can send the second content M2, signature information and the above-mentioned target storage location to the terminal. That is, the GPG signature algorithm can be called for the second content M2 to generate signature information, and then the second content M2 and the signature information can be directly returned to the terminal as an InRelease file.

[0138] The release file and storage location sending module 905 can send the modified release file and target storage location to the terminal, wherein the modified release file and target storage location are used to enable the terminal to obtain the target version system from the server.

[0139] According to an exemplary embodiment of the present disclosure, the system updating apparatus 900 may further include a second request receiving module, a judging module, a GPG signature module, a GPG signature information sending module and an error prompt information sending module.

[0140] In the case where the target type of the target storage location ends with Release, the second request receiving module can also receive a second system update request sent by the terminal, wherein the "second system update request" can be sent by the terminal to the server after the terminal receives the third content M3, wherein the "third content M3" can be obtained by the server parsing the release file to obtain the fourth content M4, and then modifying the release time of the target version system contained in the fourth content M4 to the current time of the server. That is, the "second system update request" can be sent by the terminal to the server after the terminal receives the valid third content M3.

[0141] Next, in response to the second system update request, the judgment module can judge whether the third content M3 is currently cached in the server. If it is determined that the third content M3 is currently cached in the server, the GPG signature module can perform a GPG signature on the third content to obtain signature information, and the GPG signature information sending module can send the signature information to the terminal; otherwise, that is, if it is determined that the third content M3 is not currently cached in the server, the error prompt information sending module can send an error prompt information to the terminal.

[0142] In the present disclosure, since the system update is based on the latest release time, that is, the latest creation time, that is, the system version closest to the current moment, the creation time of the target version system contained in the release file can be modified from the original time to the current time. In this way, it can be guaranteed that the modified time must be greater than the system release time cached in the terminal, and thus it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version update is carried out according to the actual needs of the user, that is, it can be achieved at any time to completely prohibit the system update or restore the system update according to the actual needs of the user. In addition, it can also avoid the cumbersome operation process of synchronously updating the release time of all subsequently released versions every time a version update is required, which can reduce the workload of system updates and improve the efficiency of system updates.

[0143] Fig.10 is a block diagram showing another system updating apparatus 1000 according to an exemplary embodiment of the present disclosure, which is applied to a terminal.

[0144] Reference Fig.10 The system updating device 1000 may include a first request sending module 1001, a storage location receiving module 1002, a comparison module 1003 and a pulling module 1004.

[0145] The first request sending module 1001 may send a first system update request to the server, wherein the first system update request may include system version flag information.

[0146] The storage location receiving module 1002 can receive the modified release file and the target storage location sent by the server, wherein the "target storage location" can be the storage location of the target version system on the server indicated by the system version mark information; the above-mentioned "modified release file" can be the file obtained by the server after obtaining the release file of the target version system and modifying the release time of the target version system contained in the release file to the current time of the server.

[0147] According to an exemplary embodiment of the present disclosure, the system updating device 1000 may further include a signature information receiving module. The signature information receiving module may receive signature information sent by a server, wherein the signature information may be signature information obtained by the server signing a modified release file. Then, the comparison module 1003 may perform signature verification using the signature information. When the signature verification passes, the comparison module 1003 may compare the current time contained in the modified release file with the system release time cached in the terminal.

[0148] In this way, by using the signature information to perform signature verification, it can be determined whether the information sent by the server to the terminal has been tampered with, thereby ensuring the security of information transmission.

[0149] The comparison module 1003 can compare the current time contained in the above-mentioned "modified release file" with the system release time cached in the terminal, wherein the "cached system release time" can be the release time of the version system obtained by the terminal in the previous request of this request.

[0150] According to an exemplary embodiment of the present disclosure, the storage location receiving module 1002 can receive the second content M2, signature information and target storage location sent by the server, wherein the "second content M2" can be obtained by the server obtaining the release file from the target storage location when determining that the target type of the target storage location ends with InRelease, parsing the release file, and obtaining the first content M1, and then modifying the release time of the target version system contained in the first content M1 to the current time of the server. The above-mentioned "signature information" can be the signature information obtained by the server performing GPG signature on the "second content M2".

[0151] Next, the comparison module 1003 can use the above signature information to perform signature verification, that is, it can use the above signature information to determine whether the "second content M2" has been tampered with. If the signature verification passes, that is, if it is determined that the "second content M2" has not been tampered with, the current time contained in the "second content M2" can be compared with the system release time cached in the terminal.

[0152] According to an exemplary embodiment of the present disclosure, the system updating apparatus 1000 may further include a second request sending module, a GPG signature information receiving module, and an error prompt information receiving module.

[0153] The storage location receiving module 1002 can receive the third content M3 and the target storage location sent by the server, wherein the "third content M3" can be the content obtained by modifying the release time of the target version system contained in the fourth content M4 to the current time of the server after the server parses the acquired release file to obtain the fourth content M4.

[0154] In the case where the terminal receives a valid "third content M3", the second request sending module can also send a second system update request to the server. Then, the GPG signature information receiving module can receive the signature information sent by the server in response to the second system update request, wherein the "signature information" can be used for the server to determine whether the "third content M3" is currently cached in the server, and when it is determined that the "third content M3" is currently cached in the server, the signature information obtained by performing GPG signature on the "third content M3". Next, the comparison module 1003 can use the signature information to perform signature verification. And, in the case where the signature verification passes, the comparison module 1003 can compare the current time contained in the "third content M3" with the system release time cached in the terminal.

[0155] Alternatively, the error prompt information receiving module may also receive error prompt information sent by the server, wherein the “error prompt information” may be sent to the terminal when the server determines that the “third content M3” is not currently cached in the server.

[0156] When the current time is greater than the cached system release time, the pulling module 1004 may pull and install the target version system from the target storage location of the server.

[0157] In the present disclosure, by creating a warehouse with the lowest version number and recalculating the file content, that is, recalculating the warehouse build time, it can be ensured that the time after recalculation must be greater than the system release time cached in the terminal, and thus it can be ensured that each returned version system will take effect. That is, it can be guaranteed that the version is updated according to the actual needs of the user, that is, the effect of completely prohibiting system updates or restoring system updates according to the actual needs of the user at any time can be achieved.

[0158] Fig.11 is a block diagram illustrating an electronic device 1100 according to an exemplary embodiment of the present disclosure.

[0159] Reference Fig.11 The electronic device 1100 includes at least one memory 1101 and at least one processor 1102. The at least one memory 1101 stores instructions. When the instructions are executed by the at least one processor 1102, the system updating method according to the exemplary embodiment of the present disclosure is executed.

[0160] As an example, the electronic device 1100 may be a PC, a tablet device, a personal digital assistant, a smart phone, or other device capable of executing the above instructions. Here, the electronic device 1100 is not necessarily a single electronic device, but may also be any device or circuit capable of executing the above instructions (or instruction sets) individually or in combination. The electronic device 1100 may also be part of an integrated control system or a system manager, or may be configured as a portable electronic device interconnected with a local or remote (e.g., via wireless transmission) interface.

[0161] In the electronic device 1100, the processor 1102 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller or a microprocessor. As an example and not limitation, the processor may also include an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, etc.

[0162] The processor 1102 may execute instructions or codes stored in the memory 1101, wherein the memory 1101 may also store data. Instructions and data may also be sent and received over a network via a network interface device, wherein the network interface device may employ any known transmission protocol.

[0163] The memory 1101 may be integrated with the processor 1102, for example, by placing RAM or flash memory within an integrated circuit microprocessor or the like. In addition, the memory 1101 may include a separate device, such as an external disk drive, a storage array, or any other storage device that can be used by a database system. The memory 1101 and the processor 1102 may be operatively coupled, or may communicate with each other, such as through an I / O port, a network connection, etc., so that the processor 1102 can read files stored in the memory.

[0164] In addition, the electronic device 1100 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, a mouse, a touch input device, etc.) All components of the electronic device 1100 may be connected to each other via a bus and / or a network.

[0165] According to an exemplary embodiment of the present disclosure, a computer-readable storage medium may also be provided, and when the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the above-mentioned system update method. Examples of computer-readable storage media here include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disk storage, hard disk drive (HDD), solid state drive (SSD), card storage (such as, multimedia card, secure digital (SD) card or extreme digital (XD) card), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid state disk and any other device, any other device is configured to store computer programs and any associated data, data files and data structures in a non-transitory manner and provide the computer programs and any associated data, data files and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the above-mentioned computer-readable storage medium can be run in an environment deployed in a computer device such as a client, a host, an agent device, a server, etc. In addition, in one example, the computer program and any associated data, data files and data structures are distributed on a networked computer system, so that the computer program and any associated data, data files and data structures are stored, accessed and executed in a distributed manner by one or more processors or computers.

[0166] According to an exemplary embodiment of the present disclosure, a computer program product may also be provided, including a computer program, and when the computer program is executed by a processor, the system updating method according to the present disclosure is implemented.

[0167] According to the system update method, device, electronic device, storage medium and computer program product disclosed in the present invention, since the system update is based on the latest release time, that is, the latest creation time, that is, the system version closest to the current time, the creation time of the target version system contained in the release file can be modified from the original time to the current time. In this way, it can be guaranteed that the modified time must be greater than the system release time cached in the terminal, and then it can be guaranteed that each returned version system will take effect. That is, it can be guaranteed that the version update is carried out according to the actual needs of the user, that is, it can be achieved at any time to completely prohibit the system update or restore the system update according to the actual needs of the user. In addition, it can also avoid the cumbersome operation process of synchronously updating the release time of all subsequently released versions every time a version update is required, which can reduce the workload of system updates and improve system update efficiency.

[0168] According to an exemplary embodiment of the present disclosure, by using signature information to perform signature verification, it can be determined whether the information sent by the server to the terminal has been tampered with, thereby ensuring the security of information transmission.

[0169] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present disclosure is intended to cover any variations, uses or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are to be considered exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0170] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A system update method, applied to a server, characterized in that: include: Receiving a first system update request sent by a terminal, wherein the first system update request includes system version flag information; Obtain a target storage location of the target version system indicated by the system version mark information on the server; Obtaining a release file of the target version system, wherein the release file includes the release time of the target version system; Modify the release time contained in the release file to the current time of the server to obtain a modified release file; The modified release file and the target storage location are sent to the terminal, wherein the modified release file and the target storage location are used to enable the terminal to obtain the target version system from the server.

2. The system updating method according to claim 1, characterized in that: The step of obtaining the release file of the target version system includes: determining a target type of the target storage location; The release file is obtained based on the target type.

3. The system updating method according to claim 1, characterized in that: After the release time contained in the release file is modified to the current time of the server and the modified release file is obtained, the system update method further includes: Sign the modified release file to obtain signature information; The signature information is sent to the terminal.

4. The system updating method according to claim 2, characterized in that: The obtaining the release file based on the target type includes: When the target type ends with InRelease, the release file is obtained from the target storage location.

5. A system update method, applied to a terminal, characterized in that: include: Sending a first system update request to a server, wherein the first system update request includes system version mark information; Receive the modified release file and target storage location sent by the server, wherein the target storage location is the storage location of the target version system indicated by the system version mark information on the server, and the modified release file is a file obtained by modifying the release time of the target version system contained in the release file to the current time of the server after the server obtains the release file of the target version system; Compare the current time contained in the modified release file with the system release time cached in the terminal, wherein the cached system release time is the release time of the version system obtained by the terminal in the previous request of the current request; In a case where the current time is greater than the cached system release time, the target version system is pulled from the target storage location of the server and installed.

6. A system update device, applied to a server, characterized in that: include: A first request receiving module is configured to receive a first system update request sent by a terminal, wherein the first system update request includes system version flag information; A storage location acquisition module, configured to acquire a target storage location of the target version system indicated by the system version mark information on the server; A release file acquisition module, configured to acquire a release file of the target version system, wherein the release file includes a release time of the target version system; A time modification module is configured to modify the release time contained in the release file to the current time of the server, and obtain a modified release file; The release file and storage location sending module is configured to send the modified release file and the target storage location to the terminal, wherein the modified release file and the target storage location are used to enable the terminal to obtain the target version system from the server.

7. A system update device, applied to a terminal, characterized in that: include: A first request sending module is configured to send a first system update request to the server, wherein the first system update request includes system version mark information; a storage location receiving module configured to receive a modified release file and a target storage location sent by the server, wherein the target storage location is a storage location of the target version system indicated by the system version mark information on the server, and the modified release file is a file obtained by modifying the release time of the target version system contained in the release file to the current time of the server after the server obtains the release file of the target version system; A comparison module is configured to compare the current time contained in the modified release file with the system release time cached in the terminal, wherein the cached system release time is the release time of the version system obtained by the terminal in the previous request of the current request; The pulling module is configured to pull and install the target version system from the target storage location of the server when the current time is greater than the cached system release time.

8. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the system updating method according to any one of claims 1 to 4, or to implement the system updating method according to claim 5.

9. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the system updating method as claimed in any one of claims 1 to 4, or execute the system updating method as claimed in claim 5.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the system updating method according to any one of claims 1 to 4, or implements the system updating method according to claim 5.

Images