WO2022183810A1

WO2022183810A1 - Plug-in updating method and apparatus, electronic device, system, and storage medium

Info

Publication number: WO2022183810A1
Application number: PCT/CN2021/139156
Authority: WO
Inventors: 周智
Original assignee: 京东科技控股股份有限公司
Priority date: 2021-03-01
Filing date: 2021-12-17
Publication date: 2022-09-09
Also published as: CN115080077A

Abstract

A plug-in updating method and apparatus, an electronic device, a system, and a storage medium. The plug-in updating method comprises: using a shell module of a target plug-in referenced by an application program to determine whether a current core module of the target plug-in needs to be updated (101); upon determination that the current core module needs to be updated, downloading a target core module of the target plug-in (102); and updating the current core module to the target core module (103).

Description

Plug-in update method, apparatus, electronic device, system and storage medium

This application claims the priority of a Chinese patent application with application number 202110226815.1 filed with the China Patent Office on March 1, 2021, the entire contents of which are incorporated herein by reference.

technical field

The present application relates to the field of computer technology, for example, to a plug-in updating method, apparatus, electronic device, system and storage medium.

Background technique

The application needs to refer to the plugin to implement some functions. For example, the Android application needs to refer to the Gradle plugin to add dependencies, analyze dependencies, and resolve dependency conflicts. When the Android application refers to the Gradle plugin, it needs to manually add the plugin version in the application directory. information.

SUMMARY OF THE INVENTION

The present application provides a plug-in update method, apparatus, electronic device, system and storage medium, which can improve plug-in update efficiency.

This application provides a plug-in update method, including:

Use the shell module of the target plug-in referenced by the application to determine whether the current core module of the target plug-in needs to be updated;

When it is determined that the current core module needs to be updated, downloading the target core module of the target plug-in;

The current core module is updated to the target core module, wherein the target plug-in may be a plug-in deployed externally by privatization, or may be a plug-in deployed by non-privatization (ie, internal deployment).

In one embodiment, the use of the shell module of the target plug-in referenced by the application to determine whether the current core module of the target plug-in needs to be updated includes:

Use the shell module of the target plug-in to determine the version information of the current core module;

Obtain the version information of the target core module from the version management server;

When the version indicated by the version information of the target core module is higher than the version indicated by the version information of the current core module, it is determined that the current core module needs to be updated.

The version management server may be an external Paas server when the target plug-in is an externally deployed plug-in, and when the target plug-in is an internally deployed plug-in, the version management server is an internal Paas server.

In an embodiment, the obtaining the version information of the target core module from the version management server includes:

Obtain the version management address from the configuration file of the shell module of the target plug-in;

Acquire the version information of the target core module from the version management server according to the version management address.

In an embodiment, when acquiring the version information of the target core module from the version management server, the method further includes:

Obtain the plug-in storage address from the version management server;

The downloading of the target core module of the target plug-in includes:

The target kernel module is downloaded from the plug-in storage server according to the plug-in storage address.

Wherein, when the target plug-in is an externally privatized deployment plug-in, the plug-in storage server may be an external Maven server, and when the target plug-in is an internally deployed plug-in, the version management server is an internal Maven server.

In one embodiment, when the target plug-in is a plug-in deployed by external privatization, the target plug-in is obtained in the following manner:

Obtain the configured version management address and the plug-in storage address from the preset deployment interface;

The version management address and the plug-in storage address are written into the configuration file of the shell module of the original plug-in to obtain the target plug-in, that is, the target plug-in is a plug-in obtained by modifying the original plug-in developed by the developer.

In addition, when the target plug-in is an internally deployed plug-in, the target plug-in is an original plug-in developed by a developer.

In one embodiment, the method further includes:

uploading the target plug-in to the plug-in storage server. That is, when the target plug-in is a plug-in deployed privately to the outside world, after modifying the original plug-in to obtain the target plug-in, the target plug-in can be published to an external Maven server for other external users to download and use.

In one embodiment, the application program references the target plug-in in the following manner:

Add the version information of the shell module of the target plug-in under the root directory of the application according to the user operation;

The shell module of the target plug-in is added under the root directory according to the version information of the shell module of the target plug-in, and the current kernel module is added under the subdirectory of the application program.

Among them, when the target plug-in is an externally deployed plug-in, the shell module and sum module of the target plug-in can be obtained directly from the local storage; when the target plug-in is an internally deployed plug-in, the shell module and core module of the target plug-in can be obtained from Internal Maven server download.

The present application provides a plug-in update device, including:

determining module, set to utilize the shell module of the target plug-in referenced by the application program to determine whether the current core module of the target plug-in needs to be updated;

A download module, configured to download the target core module of the target plug-in when it is determined that the current core module needs to be updated;

an update module, configured to update the current core module to the target core module.

The present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, where the processor implements the above plug-in update method when executing the program.

The present application also provides a plug-in update system, including a version management server, a plug-in storage server, and an electronic device configured to execute the above-mentioned plug-in update method.

The present application also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the above plug-in update method is implemented.

Description of drawings

1 is a schematic flowchart of a plug-in update method provided by an embodiment of the present application;

2 is a schematic flowchart of another plug-in update method provided by an embodiment of the present application;

3 is a schematic interface diagram of a parameter configuration provided by an embodiment of the present application;

4 is an interactive schematic diagram of a plug-in update system provided by an embodiment of the present application;

5 is a schematic flowchart of another plug-in update method provided by an embodiment of the present application;

6 is a schematic structural diagram of a plug-in update device provided by an embodiment of the present application;

7 is a schematic structural diagram of a plug-in update system provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.

Detailed ways

The present application will be described below with reference to the accompanying drawings and embodiments. The specific embodiments described herein are merely used to explain the present application. For the convenience of description, only the parts related to the present application are shown in the drawings.

The application reference plugin has at least the following problems: 1. When the referenced plugin needs to be updated, the user needs to be notified to manually modify the version information of the plugin added in the application directory, which is not intelligent enough and the update efficiency is low; 2. When When the plug-in is deployed in large-scale external output privatization, different teams have inconsistent requirements for the plug-in. When the plug-in is updated, frequent communication with different teams is required, and the maintenance cost is high; 3. When the plug-in is deployed externally for privatization, it needs to be modified according to user needs. Plug-in code and package and regenerate the plug-in, which is cumbersome to deploy.

FIG. 1 is a schematic flowchart of a plug-in updating method provided by an embodiment of the present application. The method may be performed by a plug-in updating apparatus provided by an embodiment of the present application, and the apparatus may be implemented in software and/or hardware. In one embodiment, the apparatus may be integrated into an electronic device, such as a mobile phone, a personal computer (Personal Computer, PC), a tablet computer, a notebook computer, a desktop computer, and other electronic devices. The following embodiments will be described by taking the device integrated into an electronic device as an example. Referring to Figure 1, the method may include the following steps:

Step 101, using the shell module of the target plug-in referenced by the application program to determine whether the current core module of the target plug-in needs to be updated.

For example, the application can be an Android (mobile operating system developed by Google) application, an IOS (mobile operating system developed by Apple) application, and the target plug-in can be a plug-in referenced by the application to implement related functions, such as Gradle plugin, Android applications can manage application builds and resolve dependency-related issues by referencing Gradle plugins.

In the embodiment of this application, the plug-in is designed as a shell module + core module structure, wherein the shell module is mainly used to implement functions such as version update of the core module and privatized deployment of the plug-in; the core module is mainly used to implement real business logic, For example: dynamically add dependencies, dynamically analyze dependencies, dynamically resolve dependency conflicts, etc. The shell module can find the entry of the core module of the plug-in through reflection technology, so as to execute the latest core module and achieve the ability of automatic upgrade.

When the application needs to reference the target plug-in, the version information of the shell module of the target plug-in can be added under the root directory of the application through user operation. Download the shell module and current core module of the target plug-in from the plug-in storage server, automatically add the downloaded shell module of the target plug-in to the root directory of the application, and automatically add the current core module of the downloaded target plug-in to the sub-folder of the application In the directory, when the application is running, it can execute the current kernel module in the subdirectory to realize related functions.

In this embodiment of the present application, after the application program references the target plug-in, the shell module of the target plug-in can determine whether the current core module of the target plug-in needs to be updated in real time or periodically, and the method for determining whether the current core module of the target plug-in needs to be updated can be as follows :

(1) Use the shell module of the target plug-in to determine the version information of the current kernel module.

For example, the shell module of the target plug-in can be used to read the jar package file of the current core module in the subdirectory of the application, and parse the file name to obtain the version information of the current core module.

(2) Obtain the version information of the target core module from the version management server.

For example, the version management address may be obtained from the configuration file of the shell module of the target plug-in, and the version information of the target core module may be obtained from the version management server according to the version management address. The configuration file may be, for example, a Manifest.MF file.

(3) When the version indicated by the version information of the target core module is higher than the version indicated by the version information of the current core module, it is determined that the current core module needs to be updated.

For example, if the version information of the target kernel module indicates that the version of the kernel module is 2.0, and the version information of the current kernel module indicates that the kernel module version is 1.0, it can be determined that the version of the target kernel module is higher than the version of the current kernel module, and the current kernel module needs renew.

Step 102, when it is determined that the current core module needs to be updated, download the target core module of the target plug-in.

When obtaining the version information of the target core module from the version management server, the plug-in storage address can also be obtained, and when it is determined that the current core module needs to be updated, the target core module can be downloaded from the plug-in storage server according to the plug-in storage address.

Step 103: Update the current core module to the target core module.

After downloading the target kernel module, you can delete the current kernel module added in the subdirectory of the application program, and add the target kernel module to the subdirectory of the application program. When the application program is running, first execute the subdirectory of the application program. The shell module of the added target plug-in, and then finds the entry of the target core module through the reflection mechanism, and executes the target core module, thereby realizing the automatic update of the plug-in.

In the embodiment of the present application, the shell module of the target plug-in referenced by the application program can be used to determine whether the current core module of the target plug-in needs to be updated. When it is determined that the current core module needs to be updated, the target core module of the target plug-in is downloaded, and the current core module is updated. is the target kernel module. That is, in the embodiment of the present application, the plug-in includes a shell module and a core module, and the shell module of the plug-in is used to check whether the core module needs to be updated. The automatic update avoids the need for manual operation of the user during the update process, and improves the update efficiency.

In addition, because the plug-in is a shell module + core module structure, the plug-in update only needs to update the core module of the plug-in. When the plug-in is deployed on a large scale, it only needs to communicate with different teams about the update of the core module, and there is no need to reconnect with the plug-in. Multiple teams communicate and modify plug-in code and notify different teams to modify version information, reducing maintenance costs.

In the related technology, when the plug-in output is deployed in privatization, for security reasons, the plug-in source code is not open to the outside world, and only the obfuscated plug-in jar package is provided, but the user needs to customize some parameters according to the privatization deployment environment, for example, customizing the private Information about the version management server of the deployment, information about the privatized plug-in storage server that stores binary dependencies, and so on. The relevant solution is usually: re-modify the plug-in source code for different customers, and then repackage to generate a new plug-in for external output. This method is not only cumbersome but also has high operation and maintenance costs, and requires frequent communication with external teams. In response to this problem, The embodiments of the present application also provide corresponding solutions, which are described below with reference to FIG. 2 .

As shown in FIG. 2 , in a privatized deployment scenario, taking the plugin as a Gradle plugin as an example, another plugin update method provided by this embodiment of the present application includes the following steps:

Step 201: Obtain the configured version management address and plug-in storage address from a preset deployment interface.

Developers can develop the original Gradle plugin. The original Gradle plugin consists of a shell module and a core module. The shell module has a corresponding shell module jar package, and the core module has a corresponding core module jar package. The jar package of the core module can be used to obfuscate the code. provided in the form of. When exporting privatized deployment, in addition to providing users with the original Gradle plug-in (for example, through email, hard disk, etc.), it can also provide users with plug-in deployment tools, and the plug-in's corresponding dependency file pom file.

The user can install the plug-in deployment tool on the electronic device, and a preset deployment interface can be presented on the electronic device. In one embodiment, the preset deployment interface can be as shown in FIG. 3, including a version management server (such as a Paas server) , Configurable items of the plug-in storage server (such as a Maven server), configurable items of the plug-in storage server, such as the address of the plug-in storage server (that is, the plug-in storage address), user name, password, Configurable items of the version management server such as version The address of the management server (ie, the version management address). Of course, the preset deployment interface may also include other information, such as the version number of the plug-in shell module, the version number of the core module, and pom file information.

Users can configure related parameters on the preset deployment interface. After the configuration is complete, the electronic device obtains the configured version management address and plug-in storage address from the preset deployment interface, and writes the version management address and plug-in storage address into the original through the jar command line. The configuration file of the Gradle plugin's shell module to get the target Gradle plugin. Among them, the configuration file of the shell module of the original Gradle plug-in can have information such as the version management address of the default configuration and the storage address of the plug-in. When writing, the default configuration can be modified to the user configuration.

In one embodiment, the relevant implementation logic code configured by the user may be as follows:

Step 202: Write the version management address and the plug-in storage address into the configuration file of the shell module of the original plug-in to obtain the target plug-in.

The shell module of the target Gradle plugin is different from the shell module of the original Gradle plugin, but the core module is the same for both.

Step 203, uploading the target plug-in to the plug-in storage server.

For example, when the user clicks the publish button of the preset deployment interface and needs to publish the plug-in, the electronic device can obtain the version number of the plug-in shell module, the version number of the core module, the pom file information, etc. from the preset deployment interface, and use Gradle's maven-publish Publish the target Gradle plugin to the plugin storage server for use by other users.

Step 204: Add version information of the shell module of the target plug-in in the root directory of the application according to the user operation.

For example, when the target Gradle plugin needs to be referenced in the application, the version information of the shell module of the target Gradle plugin can be added under the root directory of the application (for example, under the build.gradle file in the root directory) through user operations, such as: myplugin_shell: 1.0.

Step 205 , according to the version information of the shell module of the target plug-in, add the shell module of the target plug-in in the root directory of the application, and add the current core module in the subdirectory of the application.

When the application is initialized, as shown in Figure 4, the shell module of the target Gradle plugin (for example: myplugin_shell: 1.0 jar package) and the current core module (for example: myplugin_core_1.0) can be automatically downloaded from the plugin storage server according to the added version information jar package), automatically add the shell module of the downloaded target Gradle plugin to the root directory of the application (for example, under the build.gradle file in the root directory), and automatically add the current core module of the downloaded target Gradle plugin to the root directory of the application Under the subdirectory of the application (such as the .gradle directory), when the application is running, the current kernel module in the subdirectory can be executed to achieve related functions.

Step 206, using the shell module of the target plug-in to determine the version information of the current kernel module.

For example, the shell module of the target Gradle plug-in can be used to read the jar package file of the current core module in the subdirectory of the application, and parse the file name to obtain the version information of the current core module.

Step 207: Obtain the version management address from the configuration file of the shell module of the target plug-in.

Step 208: Acquire the version information and plug-in storage address of the target core module from the version management server according to the version management address.

In one embodiment, the data format of the data obtained from the version management server is as follows:

Step 209, determine whether the current nuclear module needs to be updated according to the version information of the current nuclear module and the version information of the target nuclear module, if the current nuclear module needs to be updated, then execute step 210, if the current nuclear module does not need to be updated, then execute step 212 to end deal with.

For example, if the version information of the target core module is myplugin_core_2.0 and the version information of the current core module is myplugin_core_1.0, it can be determined that the version of the target core module is higher than that of the current core module, and the current core module needs to be updated.

Step 210: Download the target core module from the plug-in storage server according to the plug-in storage address.

Step 211, update the current core module to the target core module.

Step 212, end.

When the plug-in is privatized and deployed, the target plug-in is the plug-in obtained by dynamically configuring the original plug-in developed by the developer. Correspondingly, the user mentioned in this embodiment is equivalent to the client, the version management server and the developer for the developer. Plug-in storage servers are all client-side servers.

In the embodiment of the present application, when the plug-in is deployed privately, the shell module of the target plug-in referenced by the application can be used to determine whether the current core module of the target plug-in needs to be updated, and when it is determined that the current core module needs to be updated, the target core module of the target plug-in is downloaded. module to update the current kernel module to the target kernel module. That is, in the embodiment of the present application, the plug-in includes a shell module and a core module, and the shell module of the plug-in is used to check whether the core module needs to be updated. The automatic update avoids the need for manual operation of the user during the update process, and improves the update efficiency.

You can obtain the configured version management address and plug-in storage address from the preset deployment interface, write the version management address and plug-in storage address into the configuration file of the shell module of the original plug-in, and obtain the target plug-in, that is, when the plug-in is deployed privately, the Customized parameters are exposed to users for self-management through the privatized deployment interface (that is, the preset deployment interface), and customized parameters are obtained through the privatized deployment interface, so as to realize the customization of the plug-in, thereby reducing the operation and maintenance cost of the deployment and upgrade of the plug-in. The plug-in update only needs to update the core module, and developers can focus on the design of the core module, which reduces the development and operation and maintenance costs of the plug-in.

In one embodiment, in a non-privatized deployment scenario, taking the plugin as a Gradle plugin as an example, as shown in FIG. 5 , another method for updating a plugin provided by an embodiment of the present application includes the following steps:

Step 301: Add version information of the shell module of the target plug-in in the root directory of the application according to the user operation.

For example, the Gradle plug-in in this embodiment is still composed of a shell module and a core module, and the developer can upload the developed original Gradle plug-in (that is, the target Gradle plug-in) to the plug-in storage server. For example, when the target Gradle plugin needs to be referenced in the application, the version information of the shell module of the target Gradle plugin can be added under the root directory of the application (for example, under the build.gradle file in the root directory) through user operations, such as :myplugin_shell:1.0.

Step 302, download the shell module and the current core module of the target plug-in from the plug-in storage server according to the version information of the shell module of the target plug-in.

Step 303, add the shell module of the target plug-in in the root directory of the application, and add the current kernel module in the subdirectory of the application.

For example, the shell module of the downloaded target Gradle plugin can be added to the root directory of the application (for example, the build.gradle file in the root directory), and the current core module of the downloaded target Gradle plugin can be added to the subdirectory of the application (such as the .gradle directory), when the application is running, it can execute the current kernel module in the subdirectory to achieve related functions.

Step 304, using the shell module of the target plug-in to determine the version information of the current core module.

Step 305: Obtain the version management address from the configuration file of the shell module of the target plug-in.

Illustratively, the configuration file may be a Manifest.MF file, for example.

Step 306: Acquire the version information of the target core module and the plug-in storage address from the version management server according to the version management address.

Step 307: Determine whether the current core module needs to be updated according to the version information of the current core module and the version information of the target core module, if the current core module needs to be updated, then execute step 308, if the current core module does not need to be updated, then execute step 310 to end deal with.

Step 308, download the target core module from the plug-in storage server according to the plug-in storage address.

Step 309, update the current core module to the target core module.

Step 310, end.

When the plug-in is deployed in a non-privatized manner, the target plug-in is the original plug-in developed by the developer. Correspondingly, the user mentioned in this embodiment is equivalent to an internal user to the developer. The version management server and the plug-in storage server are both internal server.

In the embodiment of the present application, when the plug-in is deployed without privatization, the shell module of the target plug-in referenced by the application can be used to determine whether the current core module of the target plug-in needs to be updated, and when it is determined that the current core module needs to be updated, the target plug-in's target plug-in is downloaded. kernel module, update the current kernel module to the target kernel module. That is, in the embodiment of the present application, the plug-in includes a shell module and a core module, and the shell module of the plug-in is used to check whether the core module needs to be updated. The automatic update avoids the need for manual operation of the user during the update process, and improves the update efficiency.

The plug-in update only needs to update the core module, and developers can focus on the design of the core module, which reduces the development and operation and maintenance costs of the plug-in.

Although a plurality of steps in the flowcharts of FIGS. 2 and 5 are displayed in sequence according to the arrows, these steps are not necessarily executed in the sequence indicated by the arrows. Unless stated herein, the steps are not strictly limited to the order in which they are performed, and the steps may be performed in other orders. Moreover, at least a part of the steps in FIGS. 2 and 5 may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but may be executed at different times. These sub-steps or stages are not necessarily completed at the same time. The order of execution of the steps is not necessarily sequential, but may be performed alternately or alternately with other steps or at least a part of sub-steps or stages of other steps.

The schematic interface diagrams shown in the embodiments of the present disclosure are intended to illustrate a method for deploying a detection plug-in for sensitive functions, and the content (including but not limited to text, pictures, etc.) presented on the interface does not constitute a limitation on the solution.

FIG. 6 is a structural diagram of a plug-in updating apparatus provided by an embodiment of the present application, and the apparatus is suitable for executing the plug-in updating method provided by the embodiment of the present application. As shown in Figure 6, the apparatus may include:

The determining module 401 is configured to use the shell module of the target plug-in referenced by the application to determine whether the current core module of the target plug-in needs to be updated; the downloading module 402 is configured to download the target when it is determined that the current core module needs to be updated The target core module of the plug-in; the update module 403 is configured to update the current core module to the target core module.

In one embodiment, the determining module 401 is configured to:

Use the shell module of the target plug-in to determine the version information of the current core module; obtain the version information of the target core module from a version management server; the version indicated by the version information of the target core module is higher than the current core module When the version indicated by the version information of the module is determined, it is determined that the current core module needs to be updated.

In one embodiment, the determining module 401 is configured to obtain the version information of the target core module from the version management server in the following manner:

The version management address is obtained from the configuration file of the shell module of the target plug-in; the version information of the target core module is obtained from the version management server according to the version management address.

In one embodiment, the determining module 401 is further configured to: when acquiring the version information of the target core module from the version management server, acquire the plug-in storage address from the version management server.

The download module 402 is configured to download the target core module of the target plug-in in the following manner:

In one embodiment, the target plug-in is obtained in the following manner:

Obtain the configured version management address and the plug-in storage address from the preset deployment interface; write the version management address and the plug-in storage address into the configuration file of the shell module of the original plug-in to obtain the target plug-in.

In one embodiment, the device further includes:

The uploading module is configured to upload the target plug-in to the plug-in storage server.

The version information of the shell module of the target plug-in is added under the root directory of the application program according to the user operation; the shell module of the target plug-in is added under the root directory according to the version information of the shell module of the target plug-in, And add the current kernel module in the subdirectory of the application.

Those skilled in the art can clearly understand that, for the convenience and conciseness of the description, only the division of the above-mentioned multiple functional modules is used for illustration. That is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. For the working processes of the functional modules described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described herein again.

The device of the embodiment of the present application can use the shell module of the target plug-in referenced by the application program to determine whether the current core module of the target plug-in needs to be updated, when it is determined that the current core module needs to be updated, the target core module of the target plug-in is downloaded, and the current core module Update to target kernel module. That is, in the embodiment of the present application, the plug-in includes a shell module and a core module, and the shell module of the plug-in is used to check whether the core module needs to be updated. The automatic update avoids the need for manual operation of the user during the update process, and improves the update efficiency. The plug-in is designed in the form of a shell module and a core module. The plug-in update only needs to update the core module. Developers can focus on the design of the core module, which reduces the development and operation and maintenance costs of the plug-in.

When the plug-in is privatized and deployed externally, the customized parameters are exposed to the user through the privatized deployment interface (ie, the preset deployment interface) for self-management, and the customized parameters are obtained through the privatized deployment interface, so as to realize the customization of the plug-in and reduce the number of plug-ins. deployment and upgrade operation and maintenance costs.

Embodiments of the present application further provide an electronic device, including a memory, a processor, and a computer program stored on the memory and running on the processor, where the processor implements any of the above when executing the program The plug-in update method provided by the embodiment.

Embodiments of the present application further provide a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, implements the plug-in update method provided by any of the foregoing embodiments.

An embodiment of the present application further provides a plug-in update system, as shown in FIG. 7 , including a version management server 501, a plug-in storage server 502, and an electronic device 503 configured to execute the plug-in update method described in any of the embodiments of the present application , the interaction between multiple devices can be referred to the description of the previous embodiment, which is not repeated here.

Referring next to FIG. 8 , it shows a schematic structural diagram of a computer system 600 suitable for implementing the electronic device of the embodiment of the present application. The electronic device shown in FIG. 8 is only an example, and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

As shown in FIG. 8 , the computer system 600 includes a central processing unit (Central Processing Unit, CPU) 601, which can be loaded into a random device according to a program stored in a read-only memory (Read-Only Memory, ROM) 602 or from a storage part 608 A program in Random Access Memory (RAM) 603 is accessed to perform various appropriate actions and processes. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An Input/Output (I/O) interface 605 is also connected to the bus 604 .

The following components are connected to the I/O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc. ; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a local area network (Local Area Network, LAN) card, a modem, and the like. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I/O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 610 as needed so that a computer program read therefrom is installed into the storage section 608 as needed.

According to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments disclosed herein include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the method illustrated in the flowchart. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 609 and/or installed from the removable medium 611 . When the computer program is executed by the CPU 601, the above-described functions defined in the system of the present application are executed.

The computer-readable medium shown in this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. Examples of computer-readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, RAM, ROM, Erasable Programmable Read-Only Memory (EPROM) or flash memory), optical fiber, portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device . The program code embodied on the computer readable medium may be transmitted by any suitable medium, including but not limited to: wireless, wire, optical fiber cable, radio frequency (RF), etc., or any suitable combination of the above.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logical functions for implementing the specified functions executable instructions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented in special purpose hardware-based systems that perform the specified functions or operations, or can be implemented using A combination of dedicated hardware and computer instructions is implemented.

The modules and/or units involved in the embodiments of the present application may be implemented in a software manner, and may also be implemented in a hardware manner. The described modules and/or units can also be provided in the processor, for example, it can be described as: a processor includes a determination module, a download module and an update module. The names of these modules do not, in one case, constitute a limitation on the module itself.

As another aspect, the present application also provides a computer-readable medium. The computer-readable medium may be included in the device described in the above embodiments, or may exist alone without being assembled into the device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by a device, the device includes: determining the current core of the target plug-in using the shell module of the target plug-in referenced by the application program. Whether the module needs to be updated; when it is determined that the current core module needs to be updated, download the target core module of the target plug-in; update the current core module to the target core module.

According to the technical solutions of the embodiments of the present application, the shell module of the target plug-in referenced by the application can be used to determine whether the current core module of the target plug-in needs to be updated. When it is determined that the current core module needs to be updated, the target core module of the target plug-in is downloaded, and the current The kernel module is updated to the target kernel module. That is, in the embodiment of the present application, the plug-in includes a shell module and a core module, and the shell module of the plug-in is used to check whether the core module needs to be updated. The automatic update avoids the need for manual operation of the user during the update process, and improves the update efficiency.

Claims

A plugin update method, including:

Use the shell module of the target plug-in referenced by the application to determine whether the current core module of the target plug-in needs to be updated;

Under the condition that it is determined that the current core module needs to be updated, download the target core module of the target plug-in;

The current kernel module is updated to the target kernel module.
The method for updating a plug-in according to claim 1, wherein determining whether the current core module of the target plug-in needs to be updated by using the shell module of the target plug-in referenced by the application program comprises:

Use the shell module of the target plug-in to determine the version information of the current core module;

Obtain the version information of the target core module from the version management server;

When the version indicated by the version information of the target core module is higher than the version indicated by the version information of the current core module, it is determined that the current core module needs to be updated.
The plug-in update method according to claim 2, wherein the acquiring the version information of the target core module from a version management server comprises:

Obtain the version management address from the configuration file of the shell module of the target plug-in;

Acquire the version information of the target core module from the version management server according to the version management address.
The plug-in update method according to claim 3, in the case of acquiring the version information of the target core module from the version management server, further comprising:

Obtain the plug-in storage address from the version management server;

The downloading of the target core module of the target plug-in includes:

The target kernel module is downloaded from the plug-in storage server according to the plug-in storage address.
The plug-in update method according to claim 4, wherein, the target plug-in is obtained in the following manner:

Obtain the configured version management address and the plug-in storage address from the preset deployment interface;

Write the version management address and the plug-in storage address into the configuration file of the shell module of the original plug-in to obtain the target plug-in.
The plug-in update method according to claim 5, further comprising:

uploading the target plug-in to the plug-in storage server.
The plug-in update method according to any one of claims 1 to 6, wherein the application program references the target plug-in in the following manner:

Add the version information of the shell module of the target plug-in under the root directory of the application according to the user operation;

The shell module of the target plug-in is added under the root directory according to the version information of the shell module of the target plug-in, and the current kernel module is added under the subdirectory of the application program.
A plug-in update device, comprising:

determining module, set to utilize the shell module of the target plug-in referenced by the application program to determine whether the current core module of the target plug-in needs to be updated;

a download module, configured to download the target core module of the target plug-in when it is determined that the current core module needs to be updated;

an update module, configured to update the current core module to the target core module.
An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements any one of claims 1 to 7 when the processor executes the program One of the described plugin update methods.
A plug-in update system includes a version management server, a plug-in storage server, and an electronic device configured to execute the plug-in update method according to any one of claims 1 to 7.
A computer-readable storage medium storing a computer program, wherein when the program is executed by a processor, the plug-in updating method according to any one of claims 1 to 7 is implemented.