An application software updating method, a client device, and an electronic device

Abstract

This application discloses an application software update method, client device, and electronic device to improve the flexibility of application software updates. The method includes: when the target software meets update check conditions, sending an update check request to a server, so that the server determines whether a target dynamic module exists based on the update check request; wherein the target software includes a base package and several dynamic modules, the dynamic modules are separate from the base package and communicate with the base package through a predefined standardized interface; the update check request carries version information of the base package and version information of the dynamic modules; receiving an update check response from the server; when the update check response indicates the existence of the target dynamic module, downloading an update file corresponding to the target dynamic module from the server based on the update information carried in the update check response; generating an updated version of the target dynamic module based on the update file; and registering the updated version to the base package.

Description

Technical Field

[0001] This application relates to the field of application update technology, and in particular to an application software update method, a client device, and an electronic device. Background Technology

[0002] As mobile internet applications continue to expand, they inevitably require feature iterations, bug fixes, and performance optimizations during operation. Current application update methods typically rely on a full version release mechanism, where the modified application is repackaged and submitted to an application distribution platform, which then reviews and approves it before pushing the updated version to users. Alternatively, there are solutions for partial updates using hotfixes, hot resource updates, or plugin frameworks, aiming to reduce the frequency of full version updates to some extent.

[0003] However, existing technologies still suffer from insufficient flexibility in application software updates. On the one hand, update methods relying on overall version releases are constrained by fixed review processes and release schedules, making it difficult to respond promptly to frequently changing update needs. On the other hand, some existing hot update or plug-in solutions often require significant modifications to the original application structure in practical applications, or have limitations in update strategies and security controls, making it difficult to flexibly adjust the update process according to different update content, thus affecting the update efficiency and adaptability of application software during operation. Summary of the Invention

[0004] This application provides an application software update method, a client device, and an electronic device, which can improve the flexibility of application software updates.

[0005] The first aspect of this application provides an application software update method, applied to a client device, the method comprising:

[0006] When the target software meets the update check conditions, it sends an update check request to the server, so that the server can determine whether a target dynamic module exists based on the update check request. The target software includes a base package and several dynamic modules. The dynamic modules are separate from the base package and communicate with the base package through a predefined standardized interface. The update check request carries version information of the base package and version information of the dynamic modules. The target dynamic module is the dynamic module with updated content. Receive the update check response sent by the server; When the update check response indicates the existence of the target dynamic module, the update file corresponding to the target dynamic module is downloaded from the server according to the update information carried in the update check response; An updated version of the target dynamic module is generated based on the update file; Register the updated version to the base package.

[0007] Optionally, the updated version is a differential patch file, and generating an updated version of the target dynamic module based on the updated file includes: The update file is applied to the local version corresponding to the target dynamic module to generate an updated version of the target dynamic module.

[0008] Optionally, applying the update file to the local version corresponding to the target dynamic module to generate an updated version of the target dynamic module includes: Determine the differential algorithm for the updated file; wherein the differential algorithm includes a text-based differential algorithm, a block-based differential algorithm, and a hash-based differential algorithm; The update file is applied to the local version corresponding to the target dynamic module according to the differential algorithm to generate an updated version of the target dynamic module.

[0009] Optionally, the updated version is a complete file, and generating the updated version of the target dynamic module based on the updated file includes: The updated file is identified as the updated version of the target dynamic module.

[0010] Optionally, after downloading the update file corresponding to the target dynamic module from the server, the method further includes: A first integrity verification is performed on the updated file, the first integrity verification being used to determine the integrity of the updated file that has just been downloaded; If the result of the first integrity verification is successful, the step of generating an updated version of the target dynamic module based on the updated file includes: A second integrity verification is performed on the updated file, the second integrity verification being used to determine the integrity of the updated file when the update is applied; If the result of the second integrity verification indicates that the verification is successful, an updated version of the target dynamic module is generated based on the update file.

[0011] Optionally, before performing the second integrity verification on the updated file, the method further includes: The digital signature of the updated file is verified against tampering using a locally stored public key; The second integrity verification performed on the updated file includes: When the verification result of the anti-tampering verification indicates that the verification is successful, a second integrity verification is performed on the updated file.

[0012] Optionally, before sending the update check request for the target software to the server, the method further includes: Obtain the device information of the client device; An update check request is generated based on the device information, the version information of the base package, and the version information of the dynamic module.

[0013] A second aspect of this application provides a client device for implementing the method of the first aspect and any possible implementation thereof, the client device comprising: A sending unit is configured to send an update check request for the target software to a server when the target software meets the update check conditions, so that the server can determine whether a target dynamic module exists based on the update check request; wherein, the target software includes a base package and several dynamic modules, the dynamic modules are separate from the base package and communicate with the base package through a predefined standardized interface; the update check request carries version information of the base package and version information of the dynamic modules, and the target dynamic module is the dynamic module with updated content; A receiving unit is used to receive an update check response sent by the server; The download unit is used to download the update file corresponding to the target dynamic module from the server according to the update information carried in the update check response when the update check response indicates that the target dynamic module exists; A generation unit is used to generate an updated version of the target dynamic module based on the update file; A registration unit is used to register the updated version to the base package.

[0014] A third aspect of this application provides an electronic device, comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method of the first aspect and any possible implementation of the first aspect.

[0015] The fourth aspect of this application provides a computer-readable storage medium storing a program that, when executed on a computer, causes the computer to perform the methods of the first aspect and any possible implementation thereof.

[0016] As can be seen from the above technical solutions, this application has the following advantages: In this application, the client device, with its architecture separating the base package and dynamic modules, simultaneously reports both base package version information and dynamic module version information during the update check phase. This enables the server to accurately determine the updability of dynamic modules based on strong version binding relationships and trigger subsequent download and update processes only when the target dynamic module exists. Simultaneously, during the update process, only the update file for the target dynamic module is downloaded and the corresponding update version is generated. Registration is then completed through the module management framework provided by the base package, ensuring that the update behavior is always confined to the scope of dynamic modules, avoiding impact on the base package and native methods. This allows for flexible updates of dynamic modules while ensuring the stability and compliance of the base package, and reduces the risks and resource consumption associated with updates. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating one embodiment of the application software update method in this application; Figure 2 This is a flowchart illustrating a sub-implementation of the application software update method in this application; Figure 3 This is a flowchart illustrating another sub-implementation of the application software update method in this application; Figure 4 This is a flowchart illustrating another sub-implementation of the application software update method in this application; Figure 5 This is a schematic diagram of the structure of one embodiment of the client device in this application; Figure 6 This is a schematic diagram of the structure of one embodiment of the electronic device in this application. Detailed Implementation

[0018] This application provides an application software update method, a client device, and an electronic device to improve the flexibility of application software updates.

[0019] The embodiments of this application will now be described with reference to the accompanying drawings.

[0020] Please see Figure 1 , Figure 1 One embodiment of the application software update method provided in this application includes: 101. When the target software meets the update check conditions, an update check request for the target software is sent to the server so that the server can determine whether the target dynamic module exists based on the update check request. During the execution of the target software, the client device triggers update checks based on preset update check conditions. These conditions can include scenarios such as startup, periodic checks, or triggers by specific operations. The target software is architecturally composed of a base package and several dynamic modules. The base package is a stable version approved by the app store, while the dynamic modules, as updatable components, are separate from the base package. The two communicate through predefined standardized interfaces, thus avoiding direct modification of native methods. When constructing an update check request, the client device includes both the version information of the base package and the version information of each dynamic module. This allows the server to perform compatibility checks based on the strong binding relationship between the base package version and the dynamic module versions, and thereby determine whether a target dynamic module with update content exists. Specifically, when processing a client's update check request, the server first parses and obtains core parameters such as the client device's current base package version and installed dynamic module information. Then, based on a pre-built module database, it performs a two-step filtering process for incompatible dynamic modules: First, it performs a runtime eligibility check, retaining only dynamic modules with preset minimum compatibility version requirements that are no higher than the client device's current base package version, ensuring that the dynamic modules have the underlying environment to run normally. Second, it performs an interaction matching check, retaining only dynamic modules whose interface specification major version number matches the base package version requirements, ensuring that the dynamic modules and the base package can communicate and exchange commands normally. Dynamic module versions that fail both checks are filtered out. Subsequently, the server uses a semantic version number comparison algorithm to select the highest version number from the candidate versions that meet the compatibility requirements as the target dynamic module, while simultaneously checking the dependency chain compatibility of this version. Finally, it returns the information of the target dynamic module that has passed the full verification to the client, ensuring that the target dynamic module is available.

[0021] 102. Receive the update check response sent by the server; After sending an update check request to the server, the client device receives an update check response from the server via network communication. This response is generated by the server based on the base package version information and dynamic module version information submitted by the client. The update check response indicates whether an updatable target dynamic module exists in the current client environment and can carry update description information related to the target dynamic module, thus providing a basis for judgment in the client's subsequent update processing flow.

[0022] 103. When the update check response indicates the existence of a target dynamic module, download the update file corresponding to the target dynamic module from the server based on the update information carried in the update check response; Once the client device parses the update check response and confirms the existence of the target dynamic module, it invokes the file downloader module in the client engine based on the update information carried in the update check response to download the update file corresponding to the target dynamic module from the server. The downloaded update file can be an incremental update, containing only the content that has changed relative to the current dynamic module version, in order to reduce the amount of data transmitted over the network and download time, while avoiding any modifications to the base package content, thus maintaining consistency with the version reviewed by the app store.

[0023] 104. Generate an updated version of the target dynamic module based on the update file; After the client device completes the download of the update file, the dynamic module loader processes the update file and generates an updated version of the target dynamic module based on its content. During this process, a security verifier can be used to verify the integrity and hash value of the update file, ensuring that it has not been tampered with. Simultaneously, through modular isolation, the generated update version is limited to an independent dynamic module entity, allowing it to interact with the base package only through standardized interfaces, preventing runtime intrusion into the base package or modification of native code.

[0024] 105. Register the updated version to the base package.

[0025] After successfully generating an updated version of the target dynamic module, the client device registers the updated version with the base package through the module management framework provided by the base package. This allows the base package to recognize and load the updated version during subsequent runtime. The registration process follows the dynamic module interface specification predefined by the base package. The client engine uniformly manages the module's activation status and version relationships, thereby enabling the updated version of the target dynamic module to take effect on the client device without violating app store review criteria.

[0026] In this embodiment, under the architecture where the base package and dynamic modules are separated, the client device simultaneously reports the base package version information and the dynamic module version information during the update check phase. This enables the server to accurately determine the updability of the dynamic module based on the strong version binding relationship and trigger the subsequent download and update process only when the target dynamic module exists. At the same time, during the update process, only the update file is downloaded for the target dynamic module and the corresponding update version is generated. Then, the registration is completed through the module management framework provided by the base package. This ensures that the update behavior is always limited to the scope of the dynamic module, avoiding any impact on the base package and native methods. Thus, while ensuring the stability and compliance of the base package, flexible updates of the dynamic module are achieved, and the risks and resource consumption brought about by the update are reduced.

[0027] In this application, there may be multiple ways to update files, which will be described below: First, the update file is the differential patch file of the target dynamic module, that is, the difference file between the old version on the client device and the new version provided by the server. It needs to be further processed into a complete file before it can communicate with the base package through the interface.

[0028] Second, if the updated file is a complete file of the target dynamic module, it can directly communicate with the base package through an interface. If the updated file is a complete file of the target dynamic module, in step 104 of the aforementioned embodiment, the client device can identify it as an updated version of the target dynamic module.

[0029] Please see Figure 2 When the update file is a differential patch file for the target dynamic module, in some embodiments of this application, step 104 in the above embodiments, which generates an updated version of the target dynamic module based on the update file, may include the following steps: 201. Determine the differential algorithm for updating the file; wherein, the differential algorithm includes text-based differential algorithm, block-based differential algorithm, and hash-based differential algorithm; When a client device prepares to generate an updated version of a target dynamic module based on an update file, it first parses the update file downloaded from the server to determine the type of differential algorithm corresponding to the update file. To do this, the client device can obtain algorithm identification information from the update file's metadata, file header information, or update description field to distinguish whether the update file is generated using a text-based differential algorithm, a block-based differential algorithm, or a hash-based differential algorithm. Meanwhile, during the update file generation phase, the server has already selected an appropriate differential method and completed the difference calculation for the old and new versions of the target dynamic module. For example, it uses a binary differential algorithm to generate an incremental patch file for the compiled binary dynamic module, and compresses and calculates integrity information for the patch file during the generation process. Based on this, the client device can determine the structural characteristics of the update file and subsequent application rules.

[0030] 202. Apply the update file to the local version corresponding to the target dynamic module according to the differential algorithm to generate an updated version of the target dynamic module.

[0031] After identifying the differential algorithm type, the client device retrieves the current version file of the target dynamic module from local storage based on the determined differential algorithm. Following the merging rules corresponding to the differential algorithm, it gradually applies the differential content from the updated file to the local version file to restore the updated version of the target dynamic module. During this process, the client device can verify the integrity of the updated file before or during merging to ensure that the updated file is consistent with the one generated by the server, thereby guaranteeing the correctness of the merging result. This allows the client device to generate the updated version of the target dynamic module without having to re-download the complete dynamic module file.

[0032] In this embodiment, during the update file generation stage, the client device first determines the type of differential algorithm used by the server, and then applies the update file to the local version of the target dynamic module according to the differential algorithm, so that the update process can be consistent with the differential generation method on the server side. At the same time, since the server has pre-completed the difference calculation between the old and new dynamic modules and generated the corresponding update file, the client device only needs to perform differential merging locally to generate the update version, thereby avoiding repeated downloading of the complete module file, reducing network transmission overhead, and reducing the resource consumption of local update processing.

[0033] Please see Figure 3 In some embodiments of this application, after step 103 of the above embodiments downloads the update file corresponding to the target dynamic module from the server, and before step 104 generates the updated version of the target dynamic module based on the update file, the method may further include steps of dual integrity verification and anti-tampering verification, as follows: 301. Perform the first integrity verification on the updated file; After downloading the update file corresponding to the target dynamic module from the server, the client device first performs a first integrity verification on the update file before generating the updated version of the target dynamic module. This first integrity verification is performed by the client device based on preset integrity verification rules, including checking the existence of the update file to confirm that the update file has been completely downloaded to local storage; then obtaining the file size of the update file and comparing it with a preset size limit to prevent abnormal files or maliciously constructed large files from entering subsequent processes; after confirming that the file exists and its size meets the requirements, the client device performs a hash calculation on the content of the update file, for example, calculating the hash value of the update file based on the SHA256 algorithm, and comparing the calculated hash value with the check value provided by the server in the update check response or update file metadata, thereby determining whether the update file has been corrupted or abnormally altered during the download and storage process.

[0034] 302. If the result of the first integrity verification indicates that the verification is successful, the digital signature of the updated file is verified against tampering using the public key stored locally. When the initial integrity verification passes, the client device continues to perform anti-tampering verification on the update file to further confirm the authenticity of its source and the immutability of its content. The client device reads pre-saved public key information from local secure storage and obtains the digital signature data carried in the update file. After hashing the update file content, it uses the public key to verify the digital signature to determine whether the update file was generated and signed by the server holding the corresponding private key. If the digital signature verification fails, it indicates that the update file may have been tampered with during transmission or distribution. The client device then terminates subsequent processing to prevent abnormal update files from being applied to the target dynamic module.

[0035] 303. When the verification result of the anti-tampering verification indicates that the verification is passed, a second integrity verification is performed on the updated file.

[0036] When the anti-tampering verification result indicates that the verification is successful, the client device performs a second integrity verification on the update file before entering the update file application stage. This second integrity verification is performed by the client device at a different processing stage than the first integrity verification. Its verification logic is consistent with or partially consistent with the first integrity verification; for example, it recalculates and compares the hash value of the update file to confirm that the update file has not been locally modified or replaced during the process from completing the anti-tampering verification to generating the target dynamic module update version. By introducing this second integrity verification before the update file application, the client device confirms the integrity status of the update file at different stages of its lifecycle, providing a reliable file foundation for the subsequent generation of the target dynamic module update version.

[0037] In this embodiment, before downloading the update file and generating the target dynamic module update version, the client device performs a first integrity verification, an anti-tampering verification, and a second integrity verification on the update file. This ensures that the update file is verifiable at different stages, including after download completion, source confirmation, and before application. Specifically, hash verification is used to verify the consistency of the update file's content, and public key-based digital signature verification confirms that the update file was generated by the server and has not been tampered with. This forms a multi-layered verification mechanism before the update file enters the dynamic module update process, reducing the risk of abnormal or maliciously tampered files being loaded and improving the security and reliability of the target dynamic module update process.

[0038] Please see Figure 4 In some embodiments of this application, before step 101 in the above embodiments sends an update check request for the target software to the server, the method may further include the following steps: 401. Obtain device information for the client device; Before sending an update check request for the target software to the server, the client device first obtains the current device information through the update checker. This device information describes the basic characteristics of the client's operating environment. The device information may include the operating system platform and corresponding platform version running on the client device, hardware type information, and processor type, among other basic environmental information. It may also obtain a unique device identifier to identify the client device, forming a stable device fingerprint. Furthermore, the client device can obtain the version information of the base package currently running the target software, as well as the version information of each locally registered dynamic module, providing a complete environmental context for generating the subsequent update check request. This allows the server to make targeted update decisions based on the device environment and software version status.

[0039] 402. Generate an update check request based on the device information, the version information of the base package, and the version information of the dynamic module.

[0040] After obtaining device information, the client device integrates this information with the version information of the base package and the version information of the installed dynamic modules to generate an update check request to be sent to the server. This update check request includes not only version status information to identify the target software but also device information reflecting the client device's operating environment. This allows the server, upon receiving the update check request, to determine the update requirements of the dynamic modules based on the client device's environmental characteristics, the base package version, and the current versions of each dynamic module, and then return the corresponding update check response.

[0041] In this embodiment, before sending an update check request, the client device first obtains and integrates device information, basic package version information, and dynamic module version information to generate an update check request. This enables the server to fully grasp the client device's operating environment and software version status when processing the update check, thereby making a more accurate update judgment based on device characteristics and version matching relationships. At the same time, by introducing device information into the update check request, a foundation is provided for subsequent device fingerprint binding and update security control, reducing the risk of abnormal distribution or misjudgment of update files and improving the targeting and reliability of the dynamic module update process.

[0042] In the foregoing embodiments, the specific implementation process of the method provided in this application has been described in detail. It should be understood that, to implement the above method, this application also provides corresponding devices and computer-readable storage media, the technical concepts of which are consistent with the foregoing method embodiments, and both are used to implement all or part of the steps in the foregoing method. The technical solutions of the devices and computer-readable storage media involved in this application will be further described below in conjunction with specific embodiments.

[0043] Please see Figure 5 , Figure 5 One embodiment of the client device provided in this application is a client device used to implement Figures 1 to 4 The method in the illustrated embodiment includes: The sending unit 501 is used to send an update check request for the target software to the server when the target software meets the update check conditions, so that the server can determine whether there is a target dynamic module based on the update check request; wherein, the target software includes a base package and several dynamic modules, the dynamic modules are separated from the base package and communicate with the base package through a predefined standardized interface; the update check request carries the version information of the base package and the version information of the dynamic modules, and the target dynamic module is a dynamic module with updated content; The receiving unit 502 is used to receive the update check response sent by the server; Download unit 503 is used to download the update file corresponding to the target dynamic module from the server according to the update information carried in the update check response when the update check response indicates the existence of the target dynamic module; Generation unit 504 is used to generate an updated version of the target dynamic module based on the update file; Registration unit 505 is used to register the updated version to the base package.

[0044] In this implementation, the functions of each unit are as described above. Figures 1 to 4 The steps in the illustrated embodiments are the same and will not be repeated here.

[0045] Please see Figure 6 , Figure 6 One embodiment of the electronic device provided in this application includes: Processor 601, memory 602, input / output unit 603, and bus 604; The processor 601 is connected to the memory 602, the input / output unit 603, and the bus 604; The memory 602 stores a program, which the processor 601 calls to execute. Figures 1 to 4 The steps in the illustrated embodiment.

[0046] In this embodiment, the function of processor 601 is the same as described above. Figures 1 to 4 The steps in the illustrated embodiments are the same and will not be repeated here.

[0047] This application also provides a computer-readable storage medium on which a program is stored. When the program is executed on a computer, it causes the computer to perform the aforementioned actions. Figures 1 to 4 The method in any possible implementation.

[0048] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0049] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0050] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0051] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0052] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. An application software update method, characterized in that, Applied to a client device, the method includes: When the target software meets the update check conditions, it sends an update check request to the server, so that the server can determine whether a target dynamic module exists based on the update check request. The target software includes a base package and several dynamic modules. The dynamic modules are separate from the base package and communicate with the base package through a predefined standardized interface. The update check request carries version information of the base package and version information of the dynamic modules. The target dynamic module is the dynamic module with updated content. Receive the update check response sent by the server; When the update check response indicates the existence of the target dynamic module, the update file corresponding to the target dynamic module is downloaded from the server according to the update information carried in the update check response; An updated version of the target dynamic module is generated based on the update file; Register the updated version to the base package.

2. The method according to claim 1, characterized in that, The update file is a differential patch file, and the step of generating an updated version of the target dynamic module based on the update file includes: The update file is applied to the local version corresponding to the target dynamic module to generate an updated version of the target dynamic module.

3. The method according to claim 2, characterized in that, The step of applying the update file to the local version corresponding to the target dynamic module to generate an updated version of the target dynamic module includes: Determine the differential algorithm for the updated file; wherein the differential algorithm includes a text-based differential algorithm, a block-based differential algorithm, and a hash-based differential algorithm; The update file is applied to the local version corresponding to the target dynamic module according to the differential algorithm to generate an updated version of the target dynamic module.

4. The method according to claim 1, characterized in that, The updated file is a complete file, and the step of generating an updated version of the target dynamic module based on the updated file includes: The updated file is identified as the updated version of the target dynamic module.

5. The method according to claim 1, characterized in that, After downloading the update file corresponding to the target dynamic module from the server, the method further includes: A first integrity verification is performed on the updated file, the first integrity verification being used to determine the integrity of the updated file that has just been downloaded; If the result of the first integrity verification is successful, the step of generating an updated version of the target dynamic module based on the updated file includes: A second integrity verification is performed on the updated file to determine the integrity of the updated file when the update is applied. If the result of the second integrity verification indicates that the verification is successful, an updated version of the target dynamic module is generated based on the update file.

6. The method according to claim 5, characterized in that, Before performing the second integrity verification on the updated file, the method further includes: The digital signature of the updated file is verified against tampering using a locally stored public key; The second integrity verification performed on the updated file includes: When the verification result of the anti-tampering verification indicates that the verification is successful, a second integrity verification is performed on the updated file.

7. The method according to any one of claims 1 to 6, characterized in that, Before sending the update check request for the target software to the server, the method further includes: Obtain the device information of the client device; An update check request is generated based on the device information, the version information of the base package, and the version information of the dynamic module.

8. A client device, characterized in that, The client device is used to implement the method as described in any one of claims 1 to 7, the client device comprising: A sending unit is configured to send an update check request for the target software to a server when the target software meets the update check conditions, so that the server can determine whether a target dynamic module exists based on the update check request; wherein, the target software includes a base package and several dynamic modules, the dynamic modules are separate from the base package and communicate with the base package through a predefined standardized interface; the update check request carries version information of the base package and version information of the dynamic modules, and the target dynamic module is the dynamic module with updated content; A receiving unit is used to receive an update check response sent by the server; The download unit is used to download the update file corresponding to the target dynamic module from the server according to the update information carried in the update check response when the update check response indicates that the target dynamic module exists; A generation unit is used to generate an updated version of the target dynamic module based on the update file; A registration unit is used to register the updated version to the base package.

9. An electronic device, characterized in that, include: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.

Images