Patching method, related device and system

Abstract

The present application provides a method for patching, related devices and systems. The method may include: a first electronic device mounted with a patch pool can obtain a first patch sent by a cloud server. The first electronic device can compile the first patch into a first machine code based on the first version information of this device. The first electronic device can obtain the second version information of a first program in a second electronic device in the same local area network. The first electronic device can quickly synthesize a second machine code and generate a second patch file according to a second offset corresponding to the second version information. The second electronic device can obtain the second patch file or instructions corresponding to the second patch file and run them, the patch takes effect, and a first vulnerability in the first program of the second electronic device is repaired. Implementing the technical solution of the present application can avoid the cloud server from sending patches multiple times repeatedly, reduce the consumption of network bandwidth, greatly improve the efficiency of patch repair, and bring a better user experience to users.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a method for patching, related devices, and systems. Background Art

[0002] During the process of a user using an electronic device, system programs or application programs may have bugs. The solution in the prior art for this problem is usually that a cloud server sends corresponding patches to the electronic device. After the electronic device obtains the patch, it installs the patch to make the patch take effect, thereby fixing the corresponding bug in the program.

[0003] When the cloud server sends a patch to an electronic device, in the first method, the cloud server can send the original interpretive code of the patch to the electronic device. After the electronic device receives the patch, it performs machine code conversion on the electronic device side and loads and runs the machine code of the patch, and the patch takes effect, and the program bug is fixed. Using the first method, the cloud server may repeatedly send patches to different electronic devices, consuming network bandwidth, and performing patch machine code conversion on the electronic device side, resulting in low patch repair efficiency.

[0004] In the second method, the cloud server can perform machine code conversion on the patch on the cloud server side according to information such as the version of the program that needs to fix the bug obtained, and then send the machine code of the patch to the electronic device. The electronic device can directly load and run the machine code of the patch, and the patch takes effect, and the program bug is fixed. In the second method, the electronic device directly runs the machine code-converted patch file. Compared with the first method, the patch repair efficiency is improved, but the machine code-converted patch file is bound to a specific version. However, the versions of the programs on different electronic devices may not be the same, so the cloud server will send different patches corresponding to different versions of the program. Using the second method will cause the cloud server to repeatedly perform machine code conversion on the patches for the same bug, consuming a large amount of network bandwidth when sending patches, affecting the patch repair efficiency and user experience. Summary of the Invention

[0005] The purpose of this application is to provide a method for patching, related devices, and systems, which can solve the problem that the cloud server repeatedly sends patches multiple times in the case where different electronic devices need to fix the same program bug, reduce the consumption of network bandwidth, and can quickly synthesize patch machine codes adapted to different electronic devices on the terminal side, greatly improving the patch repair efficiency and bringing a better user experience to users.

[0006] The above objectives and other objectives will be achieved by the features in the independent claims. Further implementation manners are reflected in the dependent claims, the description, and the drawings.

[0007] In a first aspect, the present application provides a method for patching, which may include: A first electronic device may establish a first connection with a second electronic device. Then, the first electronic device may obtain a first patch file, which may be used for a first vulnerability in a first program, and the first vulnerability exists in the first program of the second electronic device. The electronic device may compile the first patch into first machine code according to the first version information of the first program. Next, the first electronic device may synthesize the first machine code and a first offset into a second machine code, and may burn the second machine code to generate a second patch file. Wherein, the first offset is determined according to second version information, and the second version information is the version information of the first program in the second electronic device, and the second version information is obtained by the first electronic device from the second electronic device through the first connection, and the second patch file may be used to repair the first vulnerability in the first program whose version information is the second version information.

[0008] In the present application, the first electronic device may be a smart phone, a tablet computer, a laptop computer, a desktop computer or other types of electronic devices. The first electronic device may have relatively strong computing and processing capabilities and relatively sufficient internal storage space. The first electronic device may be a device for mounting a patch pool, and the first electronic device may also be a device for compiling a patch into machine code. And it also has a Bluetooth (BT) module and / or a wireless local area network (WLAN) module. Among them, the Bluetooth (BT) module may provide a solution for Bluetooth communication including one or more of classic Bluetooth (Bluetooth 2.1 standard) or Bluetooth low energy (BLE). The WLAN module may provide a solution for WLAN communication including one or more of wireless fidelity direct (Wi-Fi direct), wireless fidelity local area networks (Wi-Fi LAN) or wireless fidelity software access point (Wi-Fi softAP).

[0009] In the present application, the second electronic device may be an electronic device such as a smart phone, a tablet computer, a laptop computer, etc., which has relatively strong computing and processing capabilities and relatively sufficient internal storage space. The second electronic device may also be an electronic device such as a smart watch, a smart bracelet, a smart speaker, a smart earphone, etc., which has relatively weak computing and processing capabilities or relatively small internal storage space. The second electronic device may have a Bluetooth (BT) module and / or a wireless local area network (WLAN) module. Among them, the Bluetooth (BT) module may provide a solution for Bluetooth communication including one or more of classic Bluetooth (Bluetooth 2.1 standard) or Bluetooth low energy (BLE). The WLAN module may provide a solution for WLAN communication including one or more of wireless fidelity direct (Wi-Fi direct), wireless fidelity local area networks (Wi-Fi LAN), or wireless fidelity software access point (Wi-Fi softAP).

[0010] Implementing the method of the first aspect can avoid the problem of the cloud server repeatedly sending patches multiple times when different electronic devices need to repair the same program vulnerability, reduce the consumption of network bandwidth, and can quickly synthesize patch machine codes adapted to different electronic devices on the terminal side, greatly improving the efficiency of patch repair and bringing a better user experience to users.

[0011] In combination with the first aspect, in some embodiments, the first offset may be determined according to the corresponding relationship between the second version information recorded in the first mapping table and the first offset.

[0012] In combination with the first aspect, in some embodiments, the first electronic device may send a second patch file to the second electronic device. The second patch file can be used together with the first program file in the second electronic device to form a second program file. The first program file is the executable file of the first program with the first vulnerability not repaired in the second electronic device, and the second program file is the executable file of the first program with the first vulnerability repaired in the second electronic device.

[0013] In combination with the first aspect, in some embodiments, when the second electronic device receives an interaction request for the first program file, the first electronic device can receive an interaction request for the second program file through the first connection. Wherein, the first program file can be an executable file of the first program with the first vulnerability not repaired in the second electronic device, the second program file can be obtained by the first electronic device by synthesizing the first program file and the second patch file, the second program file is an executable file of the first program with the first vulnerability repaired, and the first program file on the second electronic device can be associated with the second program file on the first electronic device. The first electronic device can read the second program file, generate an interaction result or executable instructions, and can send the interaction result or executable instructions to the second electronic device through the first connection.

[0014] In combination with the first aspect, in some embodiments, after the first electronic device generates the second patch file, the first electronic device can send broadcast information, which can include: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file. After receiving the response information of the second electronic device in response to the broadcast information, the first electronic device can determine that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program. The response information can include: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device.

[0015] In a second aspect, the present application provides another method for patching, which may include: the first electronic device can establish a first connection with the second electronic device. The first electronic device can obtain a first patch file, which can be used to repair the first vulnerability of the first program, and the first vulnerability exists in the first program of the second electronic device. Then, the first electronic device compiles the first patch into a first machine code according to the first version information of the first program. The first electronic device synthesizes the first machine code and a first offset into a second machine code, and burns the second machine code to generate a second patch file. Wherein, the first offset can be determined according to the second version information, the second version information can be the version information of the first program in the second electronic device, the second version information can be obtained by the first electronic device from the second electronic device through the first connection, and the second patch file is used to repair the first vulnerability of the first program with the version information being the second version information.

[0016] Implementing the method of the second aspect can avoid the problem of the cloud server repeatedly downloading patches multiple times when different electronic devices need to repair the same program vulnerability, reduce the consumption of network bandwidth, and can quickly synthesize patch machine code adapted to different electronic devices on the terminal side, greatly improving the efficiency of patch repair and bringing a better user experience to users.

[0017] In combination with the second aspect, in some embodiments, the first offset can be determined according to the corresponding relationship between the second version information recorded in the first mapping table and the first offset.

[0018] In combination with the second aspect, in some embodiments, the second electronic device can receive the second patch file generated by the first electronic device. The second electronic device combines the first program file and the second patch file into a second program file, where the first program file is the executable file of the first program in the second electronic device that has not repaired the first vulnerability, and the second program file is the executable file of the first program in the second electronic device that has repaired the first vulnerability.

[0019] In combination with the second aspect, in some embodiments, after the second electronic device receives an interaction request for the first program file, the second electronic device can forward the interaction request to the second program file of the first electronic device through the first connection, where the first program file is the executable file of the first program in the second electronic device that has not repaired the first vulnerability, the second program file can be obtained by the first electronic device combining the first program file and the second patch file, the second program file is the executable file of the first program that has repaired the first vulnerability, and the first program file on the second electronic device can be associated with the second program file on the first electronic device. Then, the first electronic device can read the second program file, generate an interaction result or executable instructions, and can send the interaction result or executable instructions to the second electronic device through the first connection. In response to the interaction result or executable instructions, the second electronic device can run the first program with the first vulnerability repaired.

[0020] In combination with the second aspect, in some embodiments, after the first electronic device generates the second patch file, the first electronic device may send broadcast information, which may include: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file. In response to the broadcast information, the second electronic device may send a response message to the first electronic device, and the response message may include: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device. The first electronic device may determine that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program.

[0021] In a third aspect, the present application provides an electronic device, which may include: a communication device, a memory, and a processor coupled to the memory, a plurality of application programs, and one or more programs. When the processor executes one or more of the programs, the electronic device may implement any function possessed by the electronic device in the first aspect and / or the second aspect, which will not be elaborated here.

[0022] In a fourth aspect, the present application provides a computer-readable medium, in which instructions may be stored. When the instructions run on an electronic device, the electronic device may be enabled to execute any function in the first aspect and / or the second aspect, which will not be elaborated here.

[0023] Implementing the technical solutions of the present application can avoid the problem of the cloud server repeatedly sending patches multiple times in the case where different electronic devices need to repair the same program vulnerability, reduce the consumption of network bandwidth, and can quickly synthesize patch machine codes adapted to different electronic devices on the terminal side, greatly improving the efficiency of patch repair and bringing a better user experience to users. Description of the Drawings

[0024] Figure 1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present application;

[0025] Figure 2 is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present application;

[0026] Figure 3 is a software framework diagram of an electronic device provided by an embodiment of the present application;

[0027] Figure 4 is a schematic diagram of patch machine code generation provided by an embodiment of the present application;

[0028] Figure 5 is a flowchart of a method for patching provided by an embodiment of the present application;

[0029] Figure 6 It is a schematic diagram of a scenario of a patching method provided by an embodiment of the present application;

[0030] Figure 7 It is a flowchart of another patching method provided by an embodiment of the present application;

[0031] Figure 8 It is a schematic diagram of a scenario of another patching method provided by an embodiment of the present application;

[0032] Figure 9A It is a schematic diagram of a user interface provided by an embodiment of the present application;

[0033] Figure 9B It is a schematic diagram of a user interface provided by an embodiment of the present application;

[0034] Figure 10A It is a schematic diagram of a user interface provided by an embodiment of the present application;

[0035] Figure 10B It is a schematic diagram of a user interface provided by an embodiment of the present application;

[0036] Figure 10C It is a schematic diagram of a user interface provided by an embodiment of the present application. Detailed implementation manners

[0037] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular forms "a", "an", "the", "above-mentioned", "this" and "such" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in the present application refers to and includes any or all possible combinations of one or more of the listed items. In the embodiments of the present application, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as implying or indicating relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality" is two or more.

[0038] Embodiments of the present application provide a communication system, which may include multiple electronic devices. The multiple electronic devices can establish a communication connection by accessing the same local area network and perform data interaction through this communication connection. Among them, the first electronic device can be a smart phone, a tablet computer, a laptop computer, a desktop computer, or other types of electronic devices, and the present application does not impose any restrictions on this. The first electronic device can have relatively strong computing and processing capabilities and relatively sufficient internal storage space. The first electronic device can be a device for mounting a patch pool, and the first electronic device can also be a device for compiling a patch into machine code. The first electronic device can provide the compiled patch machine code for the second electronic device in the local area network. The second electronic device can be a smart phone, a tablet computer, a laptop computer, etc., which have relatively strong computing and processing capabilities and relatively sufficient internal storage space, or the second electronic device can also be a smart watch, a smart bracelet, a smart speaker, a smart headset, etc., which have relatively weak computing and processing capabilities or relatively small internal storage space, and the present application does not impose special restrictions on this. The second electronic device can receive a patch from the first electronic device through a local area network connection, or receive an instruction from the first electronic device and execute the corresponding function to repair the vulnerability targeted by the patch. The first electronic device and the second electronic device can be equipped with or other types of operating systems, and the present application also does not impose any restrictions on this.

[0039] Embodiments of the present application also provide a method for patching, which solves the problem that the cloud server repeatedly distributes the same patch to different electronic devices multiple times. The method for patching can be applied to the communication system and electronic devices provided by the embodiments of the present application. In the method for patching provided by the present application, the first electronic device mounted with the patch pool can obtain the first patch sent by the cloud server. The first patch can be used to repair the first vulnerability of the first program. Among them, the first patch can be an interpreted patch code, which is a source program written in a high-level computer language (such as C language, Python, etc.). The interpreted patch code is independent of the electronic device and version information, so it can run across devices. The first electronic device can compile the interpreted patch code into the first machine code based on the first version information of the first program in this device. In the same local area network, the version information of the first program of other electronic devices may not be the same. Therefore, the patch machine codes will also be different. For example, for the same function interface, the offset addresses corresponding to different program versions are different. Therefore, for the same interpreted patch code, for different electronic devices, the patch machine codes may have certain differences, and this difference can be reflected in the different offset amounts of some absolute addresses. The first mapping table can be recorded in the patch pool, and the first mapping table can record the one-to-one correspondence between different versions of the first program and the offset amounts.

[0040] The first electronic device can obtain the ID of the second electronic device in the same local area network and the second version information of the first program in the second electronic device. The first electronic device can quickly synthesize the second machine code and generate the second patch file according to the second offset corresponding to the second version information queried from the first mapping table. The second patch file is a patch file that can be used to repair the first vulnerability in the first program of the second electronic device. The second electronic device can obtain the second patch file or the instructions corresponding to the second patch file and run them, and the patch takes effect, and the first vulnerability in the first program of the second electronic device is repaired.

[0041] Implementing the technical solutions of the embodiments of the present application, in the case where different electronic devices need to repair the same program vulnerability, the cloud server only needs to send the patch to the first electronic device in the local area network once, and then the patch can be quickly synchronized to other electronic devices in the same local area network. Therefore, implementing the technical solutions of the present application can avoid the cloud server from sending the patch repeatedly for many times, reduce the consumption of network bandwidth, and can quickly synthesize the patch machine code adapted to different electronic devices on the terminal side, greatly improving the efficiency of patch repair and bringing a better user experience to users.

[0042] Next, some terms and concepts related to the present application are introduced.

[0043] A patch is a small program for solving problems released for large software systems or applications exposed during use. Patches can be used to repair one or more software vulnerabilities. For example, patches can repair one or more vulnerabilities including but not limited to application programs, application frameworks, kernels, hardware drivers, etc. Patches can also be used to add new product features or functions.

[0044] A patch pool can be one or more directories storing one or more patch files. For example, the storage location of the patch pool in the terminal device can be the directory / data / hotpatch, etc., and the present application does not limit this. Usually, the patch pool can be mounted on a terminal device with relatively sufficient internal storage space. If the patch pool is set with network attributes, the patch pool is visible to other electronic devices in the same local area network, while the storage location of the patch pool is invisible to electronic devices outside the local area network. The directory where the patch pool is located can also be provided with corresponding security protection mechanisms. Except for certain specific applications with write permissions, modification permissions, and / or other relevant permissions, other electronic devices or other applications in the local area network only have read-only permissions for this directory and cannot perform operations such as writing and / or modifying on this directory.

[0045] Devices related to patch generation and effectiveness mainly involve servers and terminal devices. The server may include a patch packaging tool, patch package archiving, patch package distribution, etc. Among them, the patch packaging tool is a script running in the server background that packs patch files into a compressed file. The overall layout of each file inside this compressed file is unique to the patch package. Patch package archiving is used to place the patch package at a specified archiving address after the patch packaging tool generates the patch package, for subsequent server access to the patch package. Patch package distribution is used for the server to send the patch file to the terminal device. The terminal device may include patch package download, patch engine, patch package upgrade, and patch partition, etc. Among them, patch package download is used to receive the patch package sent by the server. Patch package upgrade means that after the user searches for the patch package on the mobile phone and confirms the unified download of the patch package, the patch engine performs operations such as downloading, verifying, and installing the patch package. The patch engine encapsulates various types of business logics, including verification of patch files, functions that can make the patch effective, and revoke abnormal patches. The patch partition is a space address on the terminal device hard disk, and the binary patch image in the patch package can be burned into this partition.

[0046] A computer language is a language used for communication between humans and computers. A computer language is a medium for transmitting information between humans and computers. The most significant feature of a computer system is that instructions are conveyed to the machine through a language. In order for an electronic computer to perform various tasks, a set of numbers, characters, and grammar rules for writing computer programs is required. These characters and grammar rules form various instructions for the computer, which is the computer language. Computer languages are divided into high-level languages and low-level languages. High-level languages are programming languages that are relatively close to natural languages and mathematical formulas. For example, C language, Python language, Java language, PHP language, etc. High-level languages are basically independent of the machine's hardware system and are used to write programs in a way that is easier for people to understand. The programs written are called source programs. Low-level languages are divided into machine language and assembly language. These two languages are both machine-oriented languages and are closely related to the instruction system of a specific machine. Machine language is a set of machine instructions directly recognizable and executable by a computer represented in binary code. That is, machine language is a system of instruction sets, and this instruction set is called machine code, which is data that the computer's CPU can directly interpret. The main body of assembly language is assembly instructions. The difference between assembly instructions and machine instructions lies in the way of representing instructions. Assembly instructions are a memory-friendly writing format of machine instructions.

[0047] Machine code conversion refers to the process of compiling a high-level language into machine language. Since a computer cannot directly recognize a high-level language and can only recognize machine language, a high-level language needs to go through a compiler to program an assembly program, and then through an assembler to become machine code before it can be executed by the computer.

[0048] Mounting refers to the process of attaching a file or an external device (usually a storage device) to an existing directory on a device. By accessing this directory, the external device or file can be accessed. At the same time, placing the external device or file under the directory on the device allows the system on the device to know how to manage the external device or file and understand its read / write characteristics and the like.

[0049] An image file refers to a single file created by formatting a specific series of files in a certain format to facilitate user download and use, such as an operating system, a game, etc. Its most important feature is that it can be recognized by specific software and directly burned onto a CD. Generally speaking, an image file can be further extended to contain more information, such as system files, boot files, partition table information, etc. In this way, an image file can contain all the information of a partition or even a hard disk. The patch file type described below can be an image file.

[0050] An absolute address means that in data transmission and storage, the storage units of the main memory are in bytes, and each storage unit has an address corresponding to it. Assuming the capacity of the main memory is n, then there are n storage units in this memory (taking n bytes of storage space), and their address numbers are: 0, 1, 2,..., n - 1. The address numbers of the main memory space are called the absolute addresses of the main memory.

[0051] A relative address refers to the address used when addressing relative to a certain reference quantity (usually 0 is used as the reference quantity). Relative addresses are often used in the process of program writing and compilation. Since a program needs to be placed in the main memory to be executed, instructions and data must be related to a certain absolute address in the main memory - placed in the main memory unit. However, in a multi-program system, the main memory will store multiple jobs, so programmers may not accurately know where their programs are running in the main memory, that is, programmers often do not use absolute addresses to write programs. Therefore, programmers usually use relative addresses, that is, relative to a certain reference address, to write programs and arrange the positions of instructions and data.

[0052] boot.art is a class object image file that can contain all the classes listed in the framework / base / preloaded-classes file. These classes will be loaded into the memory all at once and can be directly used.

[0053] First, a communication system 10 provided by an embodiment of the present application is introduced.

[0054] As Figure 1Exemplarily, the communication system 10 may include cloud-side devices such as cloud server 101, and terminal-side devices such as mobile phone 102, router 103, tablet computer 104, laptop 105, smart TV 106, smart speaker 107, smart earphone 108, smart watch 109, smart bracelet 110, etc. Among them, the router 103 can form a wireless network and transmit wireless network signals. The mobile phone 102, tablet computer 104, laptop 105, smart TV 106, smart speaker 107, smart earphone 108, smart watch 109, smart bracelet 110, etc. can be in the same local area network by accessing the wireless network of the router 103.

[0055] The cloud server 101 can generate one or more sets of patch packages required by the electronic device. The patch packages generated by the cloud server 101 can be original interpreted patch codes written in a high-level computer language and device-independent, or patch codes in the form of machine codes. The cloud server can send the generated patch packages to the mobile phone 102 through far-field communication. The generated patch packages can be used to repair one or more vulnerabilities of the program, or can be used to add one or more product features or functions, and the present application does not limit this. For example, the electronic device can install a certain patch package to add the "voice assistant" function. This function can help the user send information and make calls without touching the electronic device, and can also help the user translate the other party's language into the language that the user can understand in real time when having a conversation in different languages face to face with others. Before installing this patch package, the electronic device does not have a series of related functions of the above "voice assistant". In addition, there can be various types of patches. For example, taking the system as an example, there may be corresponding types of patches in the application (APP) layer, application framework layer, kernel layer, hardware driver layer, etc., and the present application does not limit this.

[0056] In some embodiments, the mobile phone 102 may have strong computing and processing capabilities and sufficient internal storage space. The mobile phone 102 can serve as a patch pool to receive one or more patch packages from the cloud server side. The patch pool may have network attributes, that is, the storage location / directory where the patch pool is located is visible to all devices in the local area network. The mobile phone 102 can synchronize the information of the patch pool to other devices in the local area network through patch package broadcasting. The mobile phone 102 may have a Bluetooth (BT) module and / or a wireless local area network (WLAN) module. Among them, the Bluetooth module can provide a solution for Bluetooth communication including one or more of classic Bluetooth (Bluetooth 2.1) or Bluetooth low energy (BLE), and the WLAN module can provide a solution for WLAN communication including one or more of wireless fidelity direct (Wi-Fi direct), wireless fidelity local area networks (Wi-Fi LAN), or wireless fidelity software access point (Wi-Fi softAP). The mobile phone 102 can use Bluetooth or WLAN or one or more other types of wireless communication technologies to establish a wireless communication connection with other electronic devices near the mobile phone 102, and then can share the patch to other electronic devices through the wireless communication connection.

[0057] In some embodiments, the mobile phone 102 can receive a patch package actively pushed by the cloud server 101 through the network. The patch package can be a patch in the form of interpretive code. After receiving the patch package sent by the cloud server, when installing the patch, the mobile phone 102 can machine-code the patch program code on the device side based on the version information of the application program that needs to be patched on the device. The mobile phone 102 can also report the version information of the application program that needs to be patched to the cloud server 101. Then, the cloud server 101 performs machine coding according to the version information and sends the patch in the form of machine code to the mobile phone 102. A mapping table can be stored in the mobile phone 102. The mapping table can record the correspondence between the version information and the machine code offset. The mobile phone 102 can generate different machine code patches according to different version information, and then other terminal devices in the local area network can obtain the corresponding patches and install them to take effect.

[0058] The tablet computer 104 and the laptop computer 105 can be terminal devices with relatively strong computing and processing capabilities and relatively sufficient internal storage space, and can be equipped with wireless communication modules such as a Bluetooth module and a WLAN module. Among them, for the descriptions of the Bluetooth module and the WLAN module, reference can be made to the Bluetooth module and the WLAN module in the above-mentioned mobile phone 102, which will not be elaborated here. Terminal devices such as the tablet computer 104 and the laptop computer 105 with relatively strong computing and processing capabilities and relatively sufficient internal storage space can also serve as a patch pool and can also be terminal devices for compiling patch programs into machine code. The terminal device where the patch pool is located and the terminal device for compiling the patch program into machine code can be the same terminal device or not the same terminal device. For example, the mobile phone 102 serves as the terminal device to which the patch pool is mounted, and the laptop computer 105 serves as the terminal device for compiling the patch machine code. After the mobile phone 102 obtains the patch program sent by the cloud server 101, the laptop computer 105 obtains the patch in the patch pool, and then the laptop computer 105 executes the machine code conversion of the patch program.

[0059] The smart TV 106, the smart speaker 107, the smart earphone 108, the smart watch 109, and the smart bracelet 110 can be terminal devices with relatively weak computing and processing capabilities or relatively small internal storage space, and can be equipped with wireless communication modules such as a Bluetooth module and a WLAN module. Among them, for the descriptions of the Bluetooth module and the WLAN module, reference can be made to the Bluetooth module and the WLAN module in the above-mentioned mobile phone 102, which will not be elaborated here. In some embodiments, the patch files run by these terminal devices with relatively weak computing and processing capabilities or relatively small internal storage space can be mounted on a terminal device with relatively strong computing and processing capabilities or relatively large internal storage space in the same local area network. In this case, when these terminal devices with relatively weak computing and processing capabilities or relatively small internal storage space disconnect from the local area network connection, the patch will become invalid accordingly. When reconnecting to the local area network connection, the patch will become effective again.

[0060] As Figure 1 shown, the cloud server 101 can generate patch packages required by electronic devices within the local area network where the mobile phone 102 is located and send the patch packages to the mobile phone 102. In some embodiments, the patch packages generated by the cloud server can be sent in groups. The grouping method can be grouped by function, such as vulnerability repair, new product feature addition, etc., or can be grouped by patch type, such as application (APP) layer type patches, hardware driver layer type patches, etc. This application does not limit this.

[0061] In some embodiments, each of the terminal devices sharing patches, such as mobile phone 102, tablet computer 104, laptop 105, smart TV 106, smart speaker 107, smart earphone 108, smart watch 109, smart bracelet 110, etc., may be equipped with the same operating system, such as system. Under the connection of router 103, a system ecosystem is formed. Under the same operating system, the machine codes of patch programs corresponding to different version information have relatively small differences. The terminal device that compiles the machine code can quickly synthesize the corresponding patch machine code according to the different version information.

[0062] It can be understood that the communication system 10 shown in this embodiment does not constitute a specific limitation on the embodiments of the present application. In some other embodiments of the present application, the communication system 10 may further include more or fewer devices than those shown in the figure. For example, the communication system 10 may further include other electronic devices such as desktop computers, smart table lamps, smart refrigerators, etc., and the present application does not impose any restrictions on this.

[0063] Next, an exemplary electronic device 100 provided in the embodiments of the present application will be introduced.

[0064] Figure 2 A schematic structural diagram of the electronic device 100 is shown.

[0065] Among them, the electronic device 100 may be the mobile phone 102, tablet computer 104, laptop 105, smart TV 106, smart speaker 107, smart earphone 108, smart watch 109, smart bracelet 110, etc. shown in the communication system 10, or may be other electronic devices, such as desktop computers, laptop computers, handheld computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices. The embodiments of the present application do not impose special restrictions on the specific type of this electronic device. It can be understood that the structure schematically shown in the embodiments of the present invention does not constitute a specific limitation on the electronic device 100. In some other embodiments of the present application, the electronic device 100 may include more or fewer components than those shown in the figure, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0066] The electronic device 100 may include a processor 111, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0067] The processor 111 may include one or more processing units. For example, the processor 111 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors.

[0068] The controller may generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching and executing instructions.

[0069] A memory may also be provided in the processor 111 for storing instructions and data. In some embodiments, the memory in the processor 111 is a cache memory. This memory may save the instructions or data that the processor 111 has just used or recycled. If the processor 111 needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 111, and thus improves the efficiency of the system.

[0070] In some embodiments, the processor 111 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0071] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 111 may include multiple groups of I2C buses. The processor 111 may be respectively coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example, the processor 111 may be coupled to the touch sensor 180K through the I2C interface, enabling the processor 111 and the touch sensor 180K to communicate through the I2C bus interface to implement the touch function of the electronic device 100.

[0072] The I2S interface can be used for audio communication. In some embodiments, the processor 111 may include multiple groups of I2S buses. The processor 111 may be coupled to the audio module 170 through the I2S bus to implement communication between the processor 111 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface to implement the function of answering a call through a Bluetooth headset.

[0073] The PCM interface can also be used for audio communication to sample, quantize, and encode analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled through the PCM bus interface. In some embodiments, the audio module 170 may also transmit an audio signal to the wireless communication module 160 through the PCM interface to implement the function of answering a call through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0074] The UART interface is a general - purpose serial data bus for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 111 and the wireless communication module 160. For example, the processor 111 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to implement the Bluetooth function. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 through the UART interface to implement the function of playing music through Bluetooth headsets.

[0075] The MIPI interface can be used to connect the processor 111 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 111 and the camera 193 communicate through the CSI interface to implement the shooting function of the electronic device 100. The processor 111 and the display screen 194 communicate through the DSI interface to implement the display function of the electronic device 100.

[0076] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 111 with the camera 193, the display screen 194, the wireless communication module 160, the audio module 170, the sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0077] The USB interface 130 is an interface that conforms to the USB standard specification. Specifically, it can be a Mini USB interface, a Micro USB interface, a USB Type - C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used for data transmission between the electronic device 100 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect other electronic devices, such as AR devices, etc.

[0078] It can be understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are only illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 can also adopt different interface connection methods in the above - mentioned embodiments, or a combination of multiple interface connection methods.

[0079] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some embodiments of wired charging, the charging management module 140 can receive the charging input of the wired charger through the USB interface 130. In some embodiments of wireless charging, the charging management module 140 can receive the wireless charging input through the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device through the power management module 141.

[0080] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 111. The power management module 141 receives the inputs from the battery 142 and / or the charging management module 140 and supplies power to the processor 111, the internal memory 121, the display screen 194, the camera 193, the wireless communication module 160, etc. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 141 can also be disposed in the processor 111. In some other embodiments, the power management module 141 and the charging management module 140 can also be disposed in the same device.

[0081] The wireless communication function of the electronic device 100 can be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modulation and demodulation processor, and the baseband processor, etc.

[0082] The antenna 1 and the antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example, the antenna 1 can be multiplexed as the diversity antenna of the wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0083] The mobile communication module 150 may provide solutions for wireless communications such as 2G / 3G / 4G / 5G applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 may receive electromagnetic waves through the antenna 1, filter, amplify, and perform other processes on the received electromagnetic waves, and then transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modulation and demodulation processor and convert it into electromagnetic waves through the antenna 1 for radiation. In some embodiments, at least some functional modules of the mobile communication module 150 may be provided in the processor 111. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 111 may be provided in the same device.

[0084] The modulation and demodulation processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. Subsequently, the demodulator transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 170A, receiver 170B, etc.), or displays an image or video through the display screen 194. In some embodiments, the modulation and demodulation processor may be an independent device. In other embodiments, the modulation and demodulation processor may be independent of the processor 111 and be provided in the same device as the mobile communication module 150 or other functional modules.

[0085] The wireless communication module 160 may provide solutions for wireless communications applied to the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite systems (GNSSs), frequency modulation (FM), near field communication (NFC), infrared (IR), etc. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and sends the processed signals to the processor 111. The wireless communication module 160 may also receive signals to be sent from the processor 111, perform frequency modulation and amplification on them, and convert them into electromagnetic waves through the antenna 2 for radiation.

[0086] In some embodiments, the electronic device 100 may discover devices in the same local area network through wireless communication technologies such as WLAN and establish a wireless communication connection with the device. The electronic device 100 may also discover devices in a certain nearby area through Bluetooth and establish a communication connection. Among them, the Bluetooth (BT) module may provide solutions for one or more Bluetooth communications including classic Bluetooth (Bluetooth 2.1) or Bluetooth low energy (BLE). The WLAN module may provide solutions for one or more WLAN communications including Wi-Fi direct, Wi-Fi LAN, or Wi-Fi softAP.

[0087] In some embodiments, the electronic device 100 may access the Internet through a mobile network (such as 2G / 3G / 4G / 5G networks), a wireless network (such as Wi-Fi), or a wired network (such as broadband) and communicate with other devices through the network. The WLAN wireless communication solution provided by the wireless communication module 160 may also enable the electronic device to communicate with devices in the network (such as a server) and communicate with a cloud device through the device (such as a server) in the network. In this way, the electronic device can discover and transmit data to devices and cloud devices in the network.

[0088] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, such that electronic device 100 can communicate with a network and other devices through wireless communication technologies. The wireless communication technologies may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include global positioning system (GPS), global navigation satellite system (GLONASS), beidou navigation satellite system (BDS), quasi-zenith satellite system (QZSS), and / or satellite based augmentation systems (SBAS).

[0089] Electronic device 100 implements a display function through a GPU, display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, and is connected to display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 111 may include one or more GPUs, which execute program instructions to generate or change display information.

[0090] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can adopt a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled, a MicroLed, a Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0091] The electronic device 100 can implement the shooting function through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, etc.

[0092] The ISP is used to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, and light passes through the lens and is transmitted to the camera photosensitive element. The optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. The ISP can also optimize the noise, brightness, and skin color of the image through algorithms. The ISP can also optimize parameters such as the exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0093] The camera 193 is used to capture static images or videos. An object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, etc. format. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0094] The digital signal processor is used to process digital signals. In addition to being able to process digital image signals, it can also process other digital signals. For example, when the electronic device 100 selects a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy, etc.

[0095] The video codec is used to compress or decompress digital videos. The electronic device 100 can support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0096] The NPU is a neural-network (NN) computing processor. By learning from the structure of biological neural networks, such as learning from the transmission pattern between human brain neurons, it can quickly process input information and can also continuously self-learn. Through the NPU, applications such as intelligent cognition of the electronic device 100 can be realized, such as: image recognition, face recognition, voice recognition, text understanding, etc.

[0097] The internal memory 121 may include one or more random access memories (RAM) and one or more non-volatile memories (NVM).

[0098] The random access memory may include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, for example, the fifth-generation DDR SDRAM is generally called DDR5 SDRAM), etc.;

[0099] The non-volatile memory may include disk storage devices, flash memory.

[0100] Flash memory can be classified into NOR Flash, NAND Flash, 3D NAND Flash, etc. according to the operating principle, and can be classified into single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc. according to the number of potential levels of storage cells. According to the storage specification, it can be classified into universal flash storage (UFS), embedded multi media Card (eMMC), etc.

[0101] The random access memory can be directly read and written by the processor 111, and can be used to store the operating system or executable programs (such as machine instructions) of other running programs, and can also be used to store data of users and application programs, etc.

[0102] The non-volatile memory can also store executable programs and data of users and application programs, etc., and can be pre-loaded into the random access memory for the processor 111 to directly read and write.

[0103] The external memory interface 120 can be used to connect to an external non-volatile memory to expand the storage capacity of the electronic device 100. The external non-volatile memory communicates with the processor 111 through the external memory interface 120 to implement the data storage function. For example, files such as music and videos are saved in the external non-volatile memory.

[0104] The electronic device 100 can implement audio functions through the audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor, etc. For example, music playback, recording, etc.

[0105] The audio module 170 is used to convert digital audio information into an analog audio signal for output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 can be disposed in the processor 111, or some functional modules of the audio module 170 can be disposed in the processor 111.

[0106] The speaker 170A, also known as the "loudspeaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or hands-free calls through the speaker 170A.

[0107] The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a call or a voice message, the voice can be received by placing the receiver 170B close to the human ear.

[0108] The microphone 170C, also known as the "microphone" or "transmitter", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak into the microphone 170C by bringing the mouth close to it, thereby inputting the sound signal into the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In some other embodiments, the electronic device 100 may be provided with two microphones 170C, which can not only collect sound signals but also implement a noise reduction function. In some other embodiments, the electronic device 100 may also be provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify the sound source, and implement functions such as directional recording.

[0109] The headphone jack 170D is used to connect a wired headphone. The headphone jack 170D can be a USB interface 130, or a 3.5 mm open mobile terminal platform (OMTP) standard interface, or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0110] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. The gyroscope sensor 180B can be used to determine the motion posture of the electronic device 100. The barometric pressure sensor 180C is used to measure barometric pressure. The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can use the magnetic sensor 180D to detect the opening and closing of the flip leather case. The acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in each direction (generally three axes). When the electronic device 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of the electronic device and is applied to applications such as horizontal and vertical screen switching and pedometers. The distance sensor 180F is used to measure distance. The electronic device 100 can measure distance through infrared or laser. In some embodiments, in the shooting scene, the electronic device 100 can use the distance sensor 180F to measure distance to achieve rapid focusing. The proximity light sensor 180G can include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The ambient light sensor 180L is used to sense the ambient light brightness. The fingerprint sensor 180H is used to collect fingerprints. The temperature sensor 180J is used to detect temperature. The touch sensor 180K, also called a "touch control device". The touch sensor 180K can be disposed on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting thereon or nearby. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In some other embodiments, the touch sensor 180K can also be disposed on the surface of the electronic device 100, at a different position from that of the display screen 194. The bone conduction sensor 180M can obtain vibration signals.

[0111] The keys 190 include a power-on key, volume keys, etc. The keys 190 can be mechanical keys. They can also be touch keys. The electronic device 100 can receive key inputs and generate key signal inputs related to the user settings and function controls of the electronic device 100.

[0112] The motor 191 can generate vibration prompts. The motor 191 can be used for incoming call vibration prompts and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playing, etc.) can correspond to different vibration feedback effects. For touch operations acting on different regions of the display screen 194, the motor 191 can also correspond to different vibration feedback effects. Different application scenarios (such as: time reminder, receiving information, alarm clock, game, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0113] The indicator 192 can be an indicator light, which can be used to indicate the charging status, power change, or can also be used to indicate messages, missed calls, notifications, etc.

[0114] The SIM card interface 195 is used to connect the SIM card. The SIM card can be inserted into or pulled out from the SIM card interface 195 to achieve contact and separation from the electronic device 100. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, that is, an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0115] The software system of the electronic device 100 can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture. In the embodiments of the present invention, taking the system as an example, the software architecture of the electronic device 100 is exemplarily described.

[0116] Figure 3 is the software structure block diagram of the electronic device 100 in the embodiments of the present invention.

[0117] As Figure 3 shown, the software structure of the electronic device 100 can include: an application layer (applications, APP), an application framework layer (application framework, FWK), an Android runtime ( runtime), and a system library (libraries), and a kernel layer (kernel).

[0118] The application layer can include a series of application packages.

[0119] As Figure 3 shown, the application packages can include applications such as a camera, a gallery, a calendar, a call, a map, a navigation, a WLAN, a Bluetooth, music, a video, and a short message.

[0120] The application framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions.

[0121] As Figure 3 shown, the application framework layer may include a window manager, a content provider, a view system, a telephone manager, a resource manager, a notification manager, etc.

[0122] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0123] The content provider is used to store and obtain data, and make this data accessible to applications. The data may include videos, images, audio, dialed and answered calls, browsing history and bookmarks, phone books, etc.

[0124] The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build applications. The display interface can be composed of one or more views. For example, a display interface including a short message notification icon may include a view for displaying text and a view for displaying pictures.

[0125] The telephone manager is used to provide the communication function of the electronic device 100. For example, the management of call states (including connection, disconnection, etc.).

[0126] The resource manager provides various resources for applications, such as localized strings, icons, pictures, layout files, video files, etc.

[0127] The notification manager enables applications to display notification information in the status bar, can be used to convey notification-type messages, can automatically disappear after a short stay without user interaction. For example, the notification manager is used to inform that the download is completed, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or a scroll bar text, such as the notification of a background running application, and can also be a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, emitting a prompt sound, vibrating the head-mounted display device, flashing the indicator light, etc.

[0128] Runtime includes core libraries and a virtual machine. Runtime is responsible for the scheduling and management of the Android system.

[0129] The core libraries contain two parts: one part is the functional functions that need to be called by the Java language, and the other part is the core libraries of Android.

[0130] The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files in the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0131] The system library can include multiple functional modules. For example: surface manager, Media Libraries, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0132] The surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.

[0133] The media library supports the playback and recording of multiple common audio and video formats, as well as static image files, etc. The media library can support multiple audio and video coding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0134] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc.

[0135] The 2D graphics engine is a drawing engine for 2D drawing.

[0136] The kernel layer is the layer between the hardware and the software. The kernel layer at least includes a display driver, a camera driver, an audio driver, a sensor driver, as well as WLAN Bluetooth capabilities and basic communication protocols.

[0137] It can be understood that patches can be used to fix one or more software program vulnerabilities, or can be used to add one or more new product features or functions. For example, in the operating system, the patches of the electronic device 100 can fix one or more program vulnerabilities in the above application layer, application framework layer, system library, and kernel layer, etc. The patches can also be used to add one or more product features or functions in the above application layer, application framework layer, system library, and kernel layer, etc. This application does not make any restrictions on this.

[0138] In some implementations, a patch file may include fragments such as version information, verification information, location information, and new code to be written. The new code to be written can be differential code or replacement code. Differential code represents the differential part of the patch code between the old program code with unfixed vulnerabilities and the new program code with fixed vulnerabilities. Differential code can effectively compress the volume of the patch file, reduce code duplication, and save storage space. Replacement code means that the patch code can directly replace the code at the bug location. For example, when reading the function where the bug is located, it can jump to the patch code to read the patch code and replace the code at the bug location. After the patch code is read, it jumps back to the original program code to continue reading other code.

[0139] Version information may refer to the program version applicable to the current patch file, including version number, version name, generation time, etc. Verification information can be a cyclic redundancy check (CRC) code, which is generally used to distinguish the identity of the patch file and verify the correctness of the data in the patch file. The system can determine whether the patch file matches the system through the version information and verification information. The location information may record the bug, that is, the address of the code to be modified, and the jump address to the corresponding newly written code. Therefore, the location information of the bug code in the original program can be found through the data in the location information fragment, and then the new patch code can be written. In the fragment of the new code to be written, new function codes are included. These new function codes can be generated by the compiler after programming. When fixing program vulnerabilities, the data in this fragment is written into the original program, and the patch takes effect, achieving the repair of the vulnerability.

[0140] In some embodiments, when repairing a vulnerability in an original program, the terminal device will detect the running state of the original program in the system. When it detects that the original program is running, the terminal device will further detect the patch files in the system. If a patch file is detected in the system, it will authenticate the patch file to determine whether the patch file matches the original program. Specifically, when verifying the patch file, the version information and verification information in the patch file can be read, and the patch file can be verified through the version information and verification information, that is, comparing the verification data in the patch file, such as version number, generation time, CRC verification code, with the verification data in the original program to ensure that the patch file matches the original program in the system and avoid using the wrong patch file. If the verification is successful, it means that the patch file matches the original program on the terminal device; if the verification fails, it means that the patch file does not match the original program on the terminal device. In the case of successful verification, the terminal device will obtain the location information of the code to be modified and the new code to be written in the patch file, so as to write the new patch code at the bug location and achieve functions such as vulnerability repair.

[0141] Figure 4 Schematic diagram of the machine code conversion of the patch code provided by the embodiment of the present application.

[0142] After receiving the original interpretive patch code sent by the cloud server, the electronic device 100 can compile the original interpretive code into machine code that can be directly executed by the computer processor based on the version information of the device.

[0143] Combined Figure 4 , the patch can be composed of public code 401 and private code 402. Both the public code 401 and the private code 402 are non-machine codes, that is, interpretive codes. Among them, the public code 401 will be compiled into the machine code of the public module during the machine code conversion process. The interfaces or functions used by the private code 402 are codes of a more underlying development kit. The machine code after compilation of the private code 402 is composed of a combination of absolute addresses and relative addresses. The above-mentioned public code 401 and private code 402 are both original interpretive codes. That is to say, the above-mentioned public code 401 and private code 402 are non-machine codes and can rely on certain specific containers to shield differences, so they can run across devices.

[0144] When the electronic device 100 compiles the patch non-machine code into machine code, it compiles the private code 402 into the machine code 403 of the private code and compiles the public code 401 into the machine code 404 of the public code. The machine code 403 of the private code is the machine code generated after the private code is compiled during the machine code conversion process. Usually, this part of the code can be common on different electronic devices, and the private resources in each platform referred to in this part of the code are shareable. The machine code 404 of the public code is the machine code generated after the public code is compiled during the machine code conversion process. This part of the code can be generated based on the code of the intermediate layer public interface of the electronic device. Since the resources, configurations, etc. of different electronic devices are not the same, the public addresses of the public interfaces of different devices are also not the same. The public code 401 can generate machine code strongly related to the electronic device according to the public addresses of the public interfaces of different devices, etc. For example, taking the electronic device as the mobile phone 400, the public code 401 combines the obtained offset address related to the mobile phone 400 to generate the machine code 404 of the public code strongly related to the mobile phone 400 and stores it in the boot.art file.

[0145] The machine code 403 of the private code and the machine code 404 of the public code are combined to form the patch machine code 405. The patch machine code 405 can be stored in the buffer pool of the electronic device.

[0146] The patch code in the patch pool can be machine-coded based on the device where the patch pool is mounted. However, on different devices, although the main code of the same patch code is the same, the offset address of the same function may be different. Therefore, the corresponding machine codes are different when the patch code is machine-coded on different devices. A mapping table can be stored in the patch pool to record these differences and mark the relevant devices corresponding to the differences. In this way, when the machine-coded patch code in the patch pool is migrated to the second device, the new patch machine code can be quickly synthesized in combination with the differences corresponding to the second device. The synthesis methods include but are not limited to binary synthesis method, disk block synthesis method, code relocation method, etc.

[0147] For example, the patch pool stores the relevant information of patch offset A 406 corresponding to mobile phone 400 and patch offset B 407 corresponding to watch 408. Patch offset A 406 may include: patch machine code offset, the identifier of mobile phone 400 corresponding to this offset in the local area network, and the matching information of patch-related content. Patch offset B 408 may include: patch machine code offset, the identifier of watch 408 corresponding to this offset in the local area network, and the matching information of patch-related content. If the version information of the programs to be patched on mobile phone 400 and watch 408 is different, then the offset addresses of the public interfaces may also be different, and thus patch offset A 406 and patch offset B 407 are also different. However, when the patch machine code of mobile phone 400 is migrated to watch 408, the patch machine code of mobile phone 400 can be quickly synthesized into a new patch machine code in combination with patch offset B of watch 408, and the new patch machine code can take effect on watch 408.

[0148] Exemplarily, the patch pool can store a mapping table, which can record information such as version number, unique identification number of the electronic device, offset, etc. Among them, exemplarily, the mapping table can be as shown in Table 1 below:

[0149] Table 1

[0150]

[0151] As shown in Table 1, the unique identification number of the electronic device recorded in this exemplary mapping table takes the product serial number (SN) of the electronic device as an example. The version number of the electronic device 869672321140250 is 10.0.1, and the offset corresponding to this electronic device is 1F69H. The version number of the electronic device 869672321150369 is 10.0.2, and the offset corresponding to this electronic device is 0F60H. The version number of the electronic device 869672321120568 is 10.0.3, and the offset corresponding to this electronic device is 0060H. Among them, the H at the end of the offset can represent that the offset is a hexadecimal number.

[0152] In some other embodiments, the unique identification number of the electronic device recorded in the mapping table may be the fixed physical address (media access control, MAC) of the electronic device, or the unique number that distinguishes this electronic device from other electronic devices. This application does not limit this.

[0153] It can be understood that the above example table is only used to explain this application and should not constitute a limitation to this application.

[0154] It can be understood that Figure 4 it is only an exemplary illustration of the implementation method of the machine-coded original interpretive patch code and should not constitute a specific limitation to this application.

[0155] Next, based on the foregoing communication system 10 and electronic device 100, the patching method provided by this application will be described in detail.

[0156] Embodiment 1

[0157] In this embodiment, the interaction between a mobile phone and a tablet computer is used as an example for illustration. The mobile phone can be used as the device for mounting the patch pool and the device for machine-coding the patch, and the tablet computer can be used as the device that needs to obtain the patch to repair program vulnerabilities or upgrade product features. Both the mobile phone and the tablet computer are terminal devices with relatively strong computing processing capabilities and relatively sufficient internal storage spaces. The mobile phone and the tablet computer are in the same local area network. The mobile phone can machine-code the patch on the mobile phone side according to the version information of the tablet computer, generate a patch file in the form of machine code, and then send it to the tablet computer. The tablet computer reads the patch file and the patch takes effect.

[0158] In some embodiments, the device for mounting the patch pool and the device for machine - coding the patch may not be the same device. For example, a laptop computer is the device for mounting the patch pool. The laptop computer can obtain various patches from a cloud server and store them in the patch pool, and the patch pool is visible to devices connected to the same local area network. A mobile phone, a tablet computer, and the laptop computer are in the same local area network. The mobile phone can obtain a certain patch from the patch pool and perform machine - coding of the patch on the mobile phone side according to the version information of the tablet computer to generate a patch file in machine - code form, and then send it to the tablet computer. The tablet computer reads the patch file and the patch takes effect.

[0159] It can be understood that the interaction between the mobile phone and the tablet computer is only for an exemplary illustration and does not impose any limitation on the embodiments of the present application.

[0160] Figure 5 The following shows a method flow for patching provided by the embodiments of the present application. Specifically, it may include the following steps:

[0161] S101. The mobile phone and the tablet computer are connected to the same local area network.

[0162] Specifically, the mobile phone and the tablet computer can be in the same local area network by connecting to the same Wi - Fi access point provided by the same router. The mobile phone and the tablet computer can establish a wireless communication connection (which can also be called the first connection) through this Wi - Fi access point. In this local area network, information such as the patch pool mounted on the mobile phone and the location of the patch pool is visible to the tablet computer.

[0163] S102. As the device for mounting the patch pool, the mobile phone can obtain the first patch (which can also be called the first patch file) sent by the cloud server. The first patch can be used to repair the first vulnerability of the first program.

[0164] Specifically, the patch pool can refer to one or more directories storing one or more patches. This directory can be set to be visible to other devices in the local area network, and invisible to other devices not in the same local area network. Specifically, the patch pool can be a certain directory on the mobile phone device where it is mounted, such as / data / hotpatch / . Set the attribute of this directory to be visible to other devices in the local area network. In this way, the storage location of the patch pool will be exposed in the entire local area network.

[0165] The first patch may include one or more patch files. The code form of the first patch may be interpreted code or machine code, and this application does not make any restrictions. If it is a patch file in the form of machine code, the cloud server needs to obtain the version information of the program in the device to be patched before sending the patch, then perform machine code conversion in the cloud according to the version information, and then send it to the device side. The device side does not need to compile and can directly run the machine code. The first patch may be actively pushed to the mobile phone after being generated by the cloud server, or may be sent according to the request of the mobile phone, and this application does not make any restrictions on this.

[0166] S103. According to the version number A of the first program in the mobile phone, the mobile phone compiles the code of the first patch into machine code A (which can also be called the first machine code).

[0167] Specifically, in the same local area network, the version information of the first program on different electronic devices may not be the same. The version information may include information such as version name and version number. In this embodiment, the version information of the first program in the mobile phone may be called the first version information. The version number of the first program in the mobile phone is version number A. The mobile phone also stores a first mapping table, which may record the one-to-one correspondence between different version numbers of the first program and the offsets relative to the machine code A. Since the offset addresses of the same function interface may not be the same for different version information of the first program, different versions of the program will correspond to different offsets.

[0168] Of course, the first mapping table may also record other corresponding information. For example, if the mobile phone can obtain a certain version of the first program currently used by other electronic devices in the local area network, then the first mapping table may also record the correspondence between the unique identity document (ID) of the electronic device and the version number. The ID of the electronic device may be its fixed physical address (media access control, MAC), or the product serial number (serial number, SN) of the electronic device, or other unique identification numbers that distinguish the electronic device from other electronic devices, and this application does not make any restrictions on this.

[0169] S104. The mobile phone obtains information such as the ID of the tablet computer and the version number B of the first program in the tablet computer.

[0170] The ID of the tablet computer is the unique identification number of the tablet computer. The ID of the tablet computer may be the MAC number, the SN number, or other unique identification numbers that distinguish the tablet computer from other electronic devices, and this application does not make any restrictions on this.

[0171] In this embodiment, the version information of the first program in the tablet computer can be referred to as the second version information. The version number of the first program in the tablet computer is version number B, which is different from the version number A of the first program in the mobile phone.

[0172] S105. The mobile phone queries the first mapping table, and the version number B corresponds to the offset B (which can also be referred to as the first offset). The mobile phone synthesizes the offset B corresponding to the version number B and the machine code A into the machine code B (which can also be referred to as the second machine code), and generates the patch file B (which can also be referred to as the second patch file). The patch file B is a patch file that can be used to repair the first vulnerability of the first program with the version number B.

[0173] Specifically, the method of synthesizing the offset B and the machine code A into the machine code B may include, but is not limited to, binary synthesis method, disk block synthesis method, and code relocation method. Among them, the binary synthesis method refers to synthesizing multiple binary files into one, and specifying the data segment address offset, and filling the default value at the address between the data segments. The disk block synthesis method refers to synthesizing multiple physical hard disks into one logical hard disk for use. The code relocation method refers to the process of transforming the logical address space of the program into the actual physical address space in the memory. There are two methods of relocation, namely dynamic relocation and static relocation. Static relocation is completed during the process of loading the program into the memory, which means that before the program starts running, all items related to the addresses in the program have been relocated, and the address transformation is usually completed once during loading and will not change later. Dynamic relocation is not completed when the program is loaded into the memory, but every time the central processing unit (CPU) accesses the memory, the dynamic address transformation mechanism (hardware) automatically transforms the relative address into the absolute address. Dynamic relocation requires the mutual cooperation of software and hardware.

[0174] It can be understood that the patch file B may include one or more files.

[0175] S106. The mobile phone sends a broadcast in the local area network. The message of this broadcast may include the device ID of the mounted patch pool (such as the mobile phone ID), the device ID supported by the patch file B (such as the tablet computer ID), the version number of the first program supported by the patch file B (such as version number B), and so on.

[0176] S107. The tablet computer responds to the broadcast of the mobile phone. The response message may include the mobile phone ID, the tablet computer ID, the version number B, and so on.

[0177] S108. The tablet computer obtains the patch file B generated on the mobile phone side.

[0178] After the tablet computer responds to the broadcast of the mobile phone and the mobile phone verifies the identity of the tablet computer, the mobile phone can send the patch file B to the tablet computer side.

[0179] S109. When the first program is running, the tablet computer loads the patch file B, the first patch takes effect, and the first vulnerability in the first program is repaired.

[0180] In some embodiments, the code in the patch file may be differential code. Then, when loading the patch file B, the patch file B will be synthesized with the original first program code to generate new first program code, and the problem where the first vulnerability is located is repaired in the new first program code.

[0181] In other embodiments, the code in the patch file may be replacement code. Then, when the tablet computer runs the machine code corresponding to the first vulnerability of the first program, it can jump to load the patch file B, the patch takes effect, and the first vulnerability in the first program is repaired. After the patch file B is read completely, it jumps back to the original program. Specifically, the tablet computer can make the patch file B into a format of a loadable dynamic link library. The patch file B contains the code information of the first vulnerability in the first program and the code information for repairing the first vulnerability. Then, during the process of loading the patch file into the address space of the first program process through the loader, the address of the first vulnerability is found, and the entry instruction of the first vulnerability is changed to be writable. At the same time, the entry instruction of the first vulnerability is changed to jump to the code for repairing the first vulnerability in the patch file B. When the tablet computer runs the first program and runs to the machine code corresponding to the first vulnerability in the first program, it can be redirected to the position of the new code for repairing the first vulnerability in the patch file B. After the patch code for repairing the first vulnerability is executed, it returns to the original first program and continues to run.

[0182] Figure 6 It is a schematic diagram of the scenario of the patching method described in the first method embodiment.

[0183] As Figure 6 Exemplarily shown, this implementation scenario may include: a mobile phone 102, a router 103, and a tablet computer 104. The mobile phone 102 and the tablet computer 104 can be in the same local area network by accessing the same Wi-Fi access point provided by the router 103. Among them, the first program in the mobile phone 102 is version number A, and the first program of the tablet computer 104 is version number B.

[0184] In Figure 6 the shown implementation scenario, the mobile phone 102 is the mounting device of the patch pool. For the description of the patch pool, reference can be made to the description of the patch pool in the foregoing, which will not be elaborated here.

[0185] Referring to the patching method described in Steps 101 to 109, the mobile phone 102 can receive, from the cloud server side, the first patch code for fixing the first vulnerability in the first program. Based on the version information of the mobile phone 102 itself, such as device-related information like version number A, the mobile phone 102 machine-codes the interpretive patch code of the first patch and compiles it into patch machine code A for storage. The mobile phone 102 can also store a first mapping table. The first mapping table may record the one-to-one correspondence between different version numbers of the first program and the offsets relative to the machine code A. Since the offset addresses of the same function interface may be different for different version information of the first program, different versions of the program will correspond to different offsets.

[0186] The mobile phone can obtain information such as the ID of the tablet computer in the same local area network and the version number B of the first program in the tablet computer. The mobile phone queries the first mapping table, and the version number B corresponds to the offset B. The mobile phone combines the offset B corresponding to the version number B with the patch machine code A to form patch machine code B and generates a patch file B, which is a patch file that can be used to fix the first vulnerability of the first program with version number B.

[0187] Then the mobile phone can send a broadcast in the local area network. The message of the broadcast may include information such as the mobile phone ID for mounting the patch pool, the tablet computer ID supported by the patch file B, and the version number B of the first program supported by the patch file B, etc. After the tablet computer responds to the mobile phone's broadcast and the mobile phone verifies the identity of the tablet computer, the mobile phone can send the patch file B to the tablet computer side. When the first program is running, the tablet computer loads the patch file B, the patch takes effect, and the first vulnerability in the first program is fixed.

[0188] For more details, reference can be made to the description in Steps 101 to 109 and will not be elaborated here. It can be understood that Figure 6 the implementation scenarios in

[0189] Embodiment 2

[0190] In this embodiment, the interaction between a mobile phone and a smart speaker is taken as an example for illustration. The mobile phone can be a device for mounting a patch pool and a device for machine-coding patches, and the smart speaker can be a device that needs to obtain a patch to repair a program vulnerability or upgrade product features. The mobile phone is a terminal device with relatively strong computing and processing capabilities and relatively sufficient internal storage space, etc. The smart speaker is a terminal device with relatively weak computing and processing capabilities and relatively small internal storage space, etc. The mobile phone and the smart speaker are in the same local area network. The mobile phone can perform machine-coding of patches on the mobile phone side according to the version information of the smart speaker, generate a patch file in the form of machine code, and store it on the mobile phone side. When the smart speaker receives an interaction request related to the file that needs to be repaired by the patch, it can forward it to the mobile phone side. The mobile phone reads the file that has been repaired by the patch, and the mobile phone sends the interaction result or execution instruction to the smart speaker, and the patch takes effect.

[0191] In some embodiments, the device for mounting the patch pool and the device for machine-coding patches may not be the same device. For example, a laptop computer is a device for mounting the patch pool. The laptop computer can obtain various patches from a cloud server and store them in the patch pool. The patch pool is visible to devices connected to the same local area network. The mobile phone, the smart speaker, and the laptop computer are in the same local area network. The mobile phone can obtain a certain patch from the patch pool and perform machine-coding of the patch on the mobile phone side according to the version information of the smart speaker, generating a patch file in the form of machine code.

[0192] It can be understood that the interaction between the mobile phone and the smart speaker is only for an exemplary illustration and does not impose any limitation on the embodiments of the present application. In addition to the smart speaker, the device for receiving patches can also be an electronic device of types such as a smart watch, a smart bracelet, a smart table lamp, a smart earphone, etc., which have relatively weak computing and processing capabilities or relatively small internal storage space, etc.

[0193] Figure 7 Another method flow for patching provided by the embodiments of the present application is shown. Specifically, it may include the following steps:

[0194] S201. The mobile phone and the smart speaker are connected to the same local area network.

[0195] Specifically, the mobile phone and the smart speaker can be in the same local area network by connecting to the same Wi-Fi access point provided by the same router. The mobile phone and the smart speaker can establish a wireless communication connection (which can also be called a first connection) between the two through the Wi-Fi access point. In this local area network, information such as the patch pool mounted in the mobile phone and the location where the patch pool is located is visible to the smart speaker.

[0196] S202. As a device for mounting the patch pool, the mobile phone can obtain the first patch (which can also be referred to as the first patch file) sent by the cloud server. The first patch can be used to repair the first vulnerability of the first program.

[0197] Specifically, the patch pool can refer to one or more directories storing one or more patches. This directory can be set to be visible to other devices in the local area network, while it is invisible to other devices not in the same local area network. Specifically, the patch pool can be a certain directory on the mounted mobile phone device, such as / data / hotpatch / , and the attribute of this directory is set to be visible to other devices in the local area network. In this way, the storage location of the patch pool will be exposed in the entire local area network.

[0198] The code form of the first patch can be interpretive code or machine code, which is not limited in this application. If it is a patch file in machine code form, the cloud server needs to obtain the version information of the program in the device to be patched before sending the patch, and then perform machine code conversion in the cloud according to the version information, and then send it to the device side. The device side does not need to compile and can directly run the machine code. The first patch can be actively pushed to the mobile phone after being generated by the cloud server, or can be sent according to the request of the mobile phone, which is not limited in this application.

[0199] S203. According to the version number A of the first program in the mobile phone, the mobile phone compiles the code of the first patch into machine code A (which can also be referred to as the first machine code).

[0200] Specifically, in the same local area network, the version information of the first program on different electronic devices may not be the same. The version information can include information such as version name and version number. In this embodiment, the version information of the first program in the mobile phone can be referred to as the first version information. The version number of the first program in the mobile phone is version number A. The mobile phone also stores a first mapping table, which can record the one-to-one correspondence between different version numbers of the first program and the offsets relative to the machine code A. Since the version information of the first program is different, the offset addresses of the same function interface may not be the same, so different versions of the program will correspond to different offsets.

[0201] Of course, other corresponding information can also be recorded in the first mapping table. For example, the mobile phone can obtain a certain version of the first program currently used by other electronic devices in the local area network, then the first mapping table can also record the correspondence between the ID of the electronic device and the version number. The ID of the electronic device can be the MAC number, the SN number of the electronic device, or other unique identification numbers that distinguish the electronic device from other electronic devices, which is not limited in this application.

[0202] S204. The mobile phone obtains information such as the ID of the smart speaker and the version number C of the first program in the smart speaker.

[0203] The ID of the smart speaker is the unique identification number of the smart speaker. The ID of the smart speaker can be the MAC number, the SN number, or other unique identification numbers that distinguish the smart speaker from other electronic devices. This application does not limit this.

[0204] In this embodiment, the version information of the first program in the smart speaker can be referred to as the second version information. The version number of the first program in the smart speaker is version number C, which is different from the version number A of the first program in the mobile phone.

[0205] S205. The mobile phone queries the first mapping table, and version number C corresponds to offset C (which can also be referred to as the first offset). The mobile phone combines the offset C corresponding to version number C with machine code A to form machine code C (which can also be referred to as the second machine code), and generates patch file C (which can also be referred to as the second patch file). Patch file C is a patch file that can be used to repair the first vulnerability of the first program with version number C.

[0206] Specifically, the method of combining offset C and machine code A to form machine code C can include but is not limited to binary synthesis method, disk block synthesis method, and code relocation method. For the description of the three relocation methods, reference can be made to the description in step S105 above, and details will not be elaborated here.

[0207] S206. The mobile phone sends a broadcast in the local area network. The message of this broadcast can include the device ID for mounting the patch pool (such as the mobile phone ID), the device ID supported by patch file C (such as the smart speaker ID), the version number of the first program supported by patch file C (such as version number C), etc.

[0208] S207. The smart speaker responds to the broadcast of the mobile phone. The response message can include the mobile phone ID, the smart speaker ID, version number C, etc.

[0209] S208. The mobile phone obtains file L in the smart speaker. File L is the file corresponding to the first program.

[0210] Due to the poor computing and processing ability or small internal storage space of the smart speaker, in this embodiment, patch file C is stored or read on the mobile phone side, and patch file C does not need to be stored on the smart speaker side. File L can include one or more files, and the content of the first program is stored in file L.

[0211] S209. The mobile phone generates file M. File M can be the file synthesized by file L and patch file C. File M in this mobile phone is associated with file L in the smart speaker.

[0212] The mobile phone can obtain the file L corresponding to the first program in the smart speaker, and synthesize the patch file C and the file L into the file M on the mobile phone side. The file M is one or more first program files that have repaired the first vulnerability. The file M can be stored on the mobile phone side. The file M can also include one or more files.

[0213] On the smart speaker side, it can be set to associate the path of the file L in the smart speaker with the file M in the local area network. When the file L receives an interaction request, the interaction request will be forwarded to the file M.

[0214] S210. The file L in the smart speaker receives an interaction request.

[0215] S211. The smart speaker forwards the interaction request for the file L to the file M in the mobile phone.

[0216] S212. The mobile phone reads the file M, generates an interaction result or instruction, and sends the interaction result or instruction to the smart speaker.

[0217] S213. The smart speaker executes the interaction result or instruction, the first patch takes effect, and the first vulnerability of the first program in the smart speaker is repaired.

[0218] Specifically, the mobile phone can send relevant instructions or interaction results to the smart speaker through a communication connection. After receiving the instruction or interaction result, the smart speaker executes the relevant function to repair the first vulnerability in the first program.

[0219] S214. The smart speaker disconnects from the local area network.

[0220] When the smart speaker disconnects from the communication connection with the mobile phone, the file M cached in the mobile phone for solving the first vulnerability can continue to be saved in the mobile phone and take effect again when the smart speaker accesses the local area network next time; the file M can also be deleted along with the disconnection from the network, and the mobile phone regenerates the file M when the smart speaker accesses the local area network next time.

[0221] S215. The file L in the smart speaker receives an interaction request.

[0222] S216. Since the connection to the local area network has been disconnected, the smart speaker cannot read the file M in the local area network that repairs the first vulnerability. Therefore, the file L is read, and the first vulnerability in the first program in the smart speaker is not repaired.

[0223] In this embodiment, the vulnerability repair on the smart speaker side depends on the patch file provided by the mobile phone in the local area network. Therefore, the smart speaker can repair the vulnerability only when it is connected to the network. If the smart speaker disconnects from the local area network, it cannot obtain the patch file for repairing the vulnerability, and the corresponding vulnerability problem cannot be repaired.

[0224] Figure 8 Schematic diagram of the scenario of the patching method described in Method Embodiment 2.

[0225] As Figure 8 Exemplarily shown, the implementation scenario may include: a mobile phone 102, a router 103, and a smart speaker 107. The mobile phone 102 and the smart speaker 107 may be in the same local area network by accessing the same Wi-Fi access point provided by the router 103. Among them, the first program in the mobile phone 102 is version number A, and the first program of the smart speaker 107 is version number C.

[0226] In Figure 8 In the shown implementation scenario, the mobile phone 102 is the device for mounting the patch pool. For the description of the patch pool, reference can be made to the description of the patch pool in the foregoing, which will not be elaborated here.

[0227] Referring to the patching method described in Steps 201 to 216, the mobile phone 102 can receive the first patch code for fixing the first vulnerability in the first program from the cloud server side. Based on the version information of the mobile phone 102 itself, such as device-related information such as version number A, the mobile phone 102 machine-codeifies the interpretive patch code of the first patch and compiles it into patch machine code A and stores it. The mobile phone 102 can also store a first mapping table. The first mapping table may record the one-to-one correspondence between different version numbers of the first program and the offsets relative to the machine code A. Since the offset addresses of the same function interface may be different for different version information of the first program, different versions of the program will correspond to different offsets.

[0228] The mobile phone can obtain information such as the ID of the smart speaker in the same local area network and the version number C of the first program in the smart speaker. The mobile phone queries the first mapping table, and the version number C corresponds to the offset C. The mobile phone synthesizes the offset C corresponding to the version number C with the patch machine code A to generate a patch machine code C, and generates a patch file C. The patch file C is a patch file that can be used to fix the first vulnerability of the first program with version number C.

[0229] Then the mobile phone can send a broadcast in the local area network. The message of the broadcast may include information such as the mobile phone ID for mounting the patch pool, the smart speaker ID supported by the patch file C, and the first program version number C supported by the patch file C, etc. After the smart speaker responds to the mobile phone's broadcast and the mobile phone verifies the identity of the smart speaker, the mobile phone can obtain the file L corresponding to the first program in the smart speaker, and synthesize the file L and the patch file C into a file M on the mobile phone side. The file M is the file that has fixed the first vulnerability and is stored on the mobile phone side. On the smart speaker side, it can be set to associate the path of the file L in the smart speaker with the file M in the local area network. When the file L receives an interaction request, the interaction request will be forwarded to the file M.

[0230] When the file L in the smart speaker receives an interaction request, the smart speaker forwards the interaction request for the file L to the file M in the mobile phone. The mobile phone reads the file M, generates an interaction result or instruction, and sends the interaction result or instruction to the smart speaker. The smart speaker executes the interaction result or instruction, the first patch takes effect, and the first vulnerability of the first program of the smart speaker is repaired. When the smart speaker disconnects from the local area network, the first patch becomes invalid, and the first vulnerability cannot be repaired.

[0231] For more details, reference can be made to the descriptions in steps 101 to 109, which will not be elaborated here. It can be understood that Figure 8 the implementation scenarios herein are only for exemplarily illustrating the embodiments of the present application and do not constitute any limitation to the present application.

[0232] The following introduces an exemplary user interface for the application menu on the electronic device 100.

[0233] Figure 9A An exemplary user interface 901 is shown.

[0234] The user interface 901 may include: a status bar 902, a calendar indicator 903, other application icons 904, a page indicator 905, and a tray 906 with common application icons.

[0235] The status bar 902 may include: one or more signal strength indicators for mobile communication signals (also known as cellular signals), one or more signal strength indicators for wireless fidelity (Wi-Fi) signals, a battery status indicator, etc.

[0236] The calendar indicator 903 may be used to indicate the current time, such as date, day of the week, hour and minute information, etc.

[0237] The other application icons 904 may be, for example: a music icon, a calculator icon, a browser icon, a settings icon, etc.

[0238] The page indicator 905 may be used to indicate which page of applications the user is currently browsing. The user can slide the area of the other application icons left and right to browse the application icons on other pages.

[0239] The tray 906 with common application icons may display: a camera icon, a contacts icon, a phone icon, a messages icon, etc.

[0240] In some embodiments, Figure 9A the exemplary user interface 901 shown may be the home screen.

[0241] In some other embodiments, the electronic device may further include a home screen key. The home screen key may be a physical button or a virtual button. The home screen key can be used to receive a user's instruction to return the currently displayed UI to the home screen, which facilitates the user to view the home screen at any time. The above instruction may specifically be an operation instruction for the user to press the home screen key once, an operation instruction for the user to press the home screen key twice continuously within a short period of time, or an operation instruction for the user to long-press the home screen key within a predetermined time. In some other embodiments of the present application, the home screen key may also integrate a fingerprint recognizer so that when the user presses the home screen key, fingerprint collection and recognition are performed accordingly.

[0242] It can be understood that Figure 9A only the user interface on the electronic device 100 is exemplarily shown and should not constitute a limitation to the embodiments of the present application.

[0243] Next, some embodiments of the application scenarios involved in the present application and the user interfaces implemented on the electronic device 100 will be described separately.

[0244] Figure 9A , Figure 9B shows the user interface exemplarily shown on the electronic device 100 when the mobile phone 102 obtains the relevant permissions of the electronic device 100 within the local area network.

[0245] As Figure 9A shown, when the mobile phone 102 within the same local area network needs to obtain relevant information of the electronic device 100 (such as the version number of the first program, the ID of the electronic device 100, etc.), the electronic device 100 may display a prompt box 907 in the user interface 901. The prompt box 907 can be used to prompt the user whether to grant the corresponding permissions to the mobile phone 102. For example, the prompt information displayed in the prompt box 907 may be the text "Do you allow the mobile phone 102 in the network to obtain your device information?". Without being limited to text information, the prompt information may also be voice or other types of prompt information output by the electronic device 100, and the present application does not limit this. The prompt box 907 may also display corresponding controls so that the user can select whether to grant the corresponding permissions to the mobile phone 102. In response to the user's touch operation (such as clicking) on the control, the electronic device 100 may execute the option of only allowing the mobile phone 102 to obtain relevant information of the electronic device 100 this time, the option of always allowing the mobile phone 102 to obtain relevant information of the electronic device 100, or the option of rejecting the mobile phone 102 from obtaining relevant information of the electronic device 100. For example, the prompt box 907 may display an "Allow" control, an "Always Allow" control, and a "Reject" control. Detecting the user's touch operation (such as clicking) on the "Always Allow" control, the electronic device 100 may execute the instruction of always allowing the mobile phone 102 to obtain relevant information of the electronic device 100 in the network-connected state.

[0246] As Figure 9B shown, when the mobile phone 102 in the same local area network sends a patch file for repairing the first vulnerability on the electronic device 100 to the electronic device 100, the electronic device 100 can display a prompt box 908 on the user interface 901. The prompt box 908 can be used to prompt the user whether to allow the mobile phone 102 to update the patch for the electronic device 100. For example, the information displayed in the prompt box can be the text "Do you allow the mobile phone 102 in the network to update the patch for you?". Not limited to text information, the prompt information can also be voice or other types of prompt information output by the electronic device 100, and the present application does not limit this. The prompt box 908 can also display corresponding controls so that the user can select whether to allow the mobile phone 102 to update the patch for the electronic device 100. In response to the user's touch operation (such as clicking) on the control, the electronic device 100 can execute the option corresponding to the control to allow the mobile phone 102 to send the patch to the electronic device 100 only this time, the option to always allow the mobile phone 102 to send the patch to the electronic device 100 this time, or the option to reject the mobile phone 102 from sending the patch to the electronic device 100. For example, the prompt box 908 can display an "Allow" control, an "Always Allow" control, and a "Reject" control. Detecting the user's touch operation (such as clicking) on the "Always Allow" control, the electronic device 100 can execute the instruction to always allow the mobile phone 102 to update the patch for the electronic device 100 in the networked state.

[0247] Figure 10A 、 Figure 10B 、 Figure 10C shows a user interface related to the technical effects demonstrated after implementing the technical solution of the present application.

[0248] Figure 10A An exemplary implementation scenario is shown. The implementation scenario can include: a mobile phone 102, a smart watch 109, and a tablet computer 104. The mobile phone 102 can be in the same local area network with the smart watch 109 and the tablet computer 104 by accessing the same wireless access point and establish communication connections with each other.

[0249] The user interface 1001 of the mobile phone 102 can be displayed when the mobile phone 102 discovers that the cloud-side server generates a required patch. The user interface 1001 can include a title bar 1004, a main interface 1005 for program version update, etc.

[0250] The title bar 1004 may include a current page indicator and a back navigation control. The current page indicator can be used to indicate the current page. For example, the text information "System Update" can be used to indicate that the current page is for displaying system update-related information. The current page indicator is not limited to text information and can also be an icon. The back navigation control can be used to monitor operations (such as touch operations) through this control. In response to this operation, the electronic device can return from the current interface to the previous level interface.

[0251] The main interface 1005 for program version update can display one or more version update-related information entries, and the one or more version update-related information entries can include: a new patch discovery prompt entry for the electronic device, a patch package size information entry, an update time information entry, an update log information entry, etc.

[0252] For each version update-related information entry on the main interface 1005 for program version update, there is a corresponding title and text description. For example, the title corresponding to the new patch discovery prompt entry for the electronic device is "New Patch Discovered", the title corresponding to the patch package size information entry is "Patch Package", and the text description is the discovered new version number "Size: 2.32MB". The title corresponding to the update time information entry is "Update Time", and the text description is "Date: September 20, 2020". The title corresponding to the update log information entry is "Update Log", and the text description is "This update adds system security repair patches and fixes system vulnerabilities", etc.

[0253] The main interface 1005 for program version update may also include an "Update" operation control 1006 and a "Cancel" operation control 1007, which can be used to monitor operations (such as touch operations) through these controls. In response to an operation on "Update" or "Cancel", the electronic device will update the patch or cancel the patch update.

[0254] In some other embodiments, the program version update page can display other program version update-related information, including but not limited to, for example, third-party application programs. The version update page can add version update-related information entries or reduce version update-related information entries, and this application does not limit this.

[0255] The user interface 1002 of the smartwatch 109 and the user interface 1003 of the tablet 104 may include interface elements that are partially or fully the same as those in the Figure 9A user interface 901 mentioned above (such as a status bar, a calendar indicator, application icons, a page indicator, and a tray of common application icons, etc.), which will not be elaborated here.

[0256] Figure 10BThe user interface 1008 of the mobile phone 102 exemplarily shown can be the user interface displayed on the mobile phone 102 when receiving a patch downloaded from the cloud server. This user interface 1008 can be used to prompt the user about the progress of downloading the patch from the cloud server. For example, an icon 1009 can be displayed, which prompts the user that the patch is being downloaded and the download progress is 25%. The user interface 1008 can also display a text message "Downloading patch" to prompt the user that the patch is being downloaded. Not limited to text messages, the prompt message can also be voice or other types of prompt messages output by the mobile phone 102, and this application does not limit this. The user interface 1008 can also display a cancel control 1010 for listening to touch operations (such as clicks) on this control. In response to this "cancel" operation, the mobile phone 102 can cancel downloading the patch from the cloud server.

[0257] Figure 10C Exemplarily shown are the user interface 1011 of the mobile phone 102, the user interface 1012 of the smartwatch 109, and the user interface 1013 of the tablet computer 104. The above user interfaces can prompt the user that in this implementation scenario, the first vulnerabilities of different versions of the first program in the mobile phone 102, the smartwatch 109, and the tablet computer 104 have all been repaired. For example, the user interface 1011 can display a text prompt message "The first vulnerability has been repaired" and display the version number information "Version 10.0" of the first program owned by the mobile phone 102. The user interface 1012 can display a text prompt message "The first vulnerability has been repaired" and display the version number information "Version 8.0" of the first program owned by the smartwatch 109. The user interface 1013 can display a text prompt message "The first vulnerability has been repaired" and display the version number information "Version 9.0" of the first program owned by the tablet computer 104. Not limited to text messages, the prompt message can also be voice or other types of prompt messages output by the electronic device, and this application does not limit this.

[0258] In Figure 10A 、 Figure 10B 、 Figure 10CIn the illustrated embodiment, only the mobile phone 102 downloads the first patch for fixing the first vulnerability from the cloud server. The mobile phone 102 can machine-code the first patch on the mobile phone side according to the version 10.0 of the mobile phone 102. Then, the mobile phone can generate new patch machine code according to the machine code offsets corresponding to the versions 8.0 of the smart watch 109 and 9.0 of the tablet computer 104 obtained. For the specific method of the tablet computer 104 to obtain the patch in the mobile phone 102, reference can be made to Method Embodiment 1. For the specific method of the smart watch 109 to obtain the patch in the mobile phone 102, reference can be made to Method Embodiment 2, which will not be elaborated here. The tablet computer 104 and the smart watch 109 in the same local area network as the mobile phone 102 do not need to repeatedly download the same patch from the cloud server. Therefore, in Figure 10B the mobile phone 102 is downloading the patch, while the smart watch 109 and the tablet computer 104 are not downloading the patch. However, when the mobile phone 102 finishes downloading the patch, the smart watch 109 and the tablet computer 104 with different program versions in the same local area network will automatically fix the same vulnerability targeted by the patch. Implementing this embodiment can avoid repeatedly downloading the same patch, save bandwidth, and improve the patching efficiency.

[0259] It can be understood that Figure 9A 、 Figure 9B 、 Figure 10A 、 Figure 10B 、 Figure 10C are only examples of some user interfaces and do not impose any restrictions on other embodiments of the present application.

[0260] In the above embodiments, depending on the context, the term "when..." can be interpreted to mean "if...", or "after...", or "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if detecting (the stated condition or event)" can be interpreted to mean "if determining...", or "in response to determining...", or "when detecting (the stated condition or event)", or "in response to detecting (the stated condition or event)".

[0261] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

[0262] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware with a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. The foregoing storage medium includes: various media that can store program codes such as ROM or random access memory RAM, magnetic disks, or optical discs.

Claims

1. A patching method, characterized in that, The method includes: The first electronic device establishes a first connection with the second electronic device; The first electronic device obtains a first patch file for fixing a first vulnerability of a first program, where the first vulnerability exists in the first program of the second electronic device; The first electronic device compiles the first patch file into first machine code according to the first version information of the first program; The first electronic device synthesizes the first machine code and a first offset into second machine code, and burns the second machine code to generate a second patch file, where the first offset is determined according to second version information, and the second version information is obtained by the first electronic device from the second electronic device through the first connection, and the second patch file is used to fix the first vulnerability of the first program with the second version information; The first version information is the version information of the first program in the first electronic device, and the second version information is the version information of the first program in the second electronic device.

2. The method according to claim 1, wherein The first offset is determined according to the second version information, specifically including: The first offset is determined according to the corresponding relationship between the second version information and the first offset recorded in the first mapping table.

3. The method according to claim 1 or 2, characterized in that, It further includes: The first electronic device sends the second patch file to the second electronic device, and the second patch file is used to synthesize with the first program file in the second electronic device to form a second program file, where the first program file is the executable file of the first program in the second electronic device that has not fixed the first vulnerability, and the second program file is the executable file of the first program in the second electronic device that has fixed the first vulnerability.

4. The method according to claim 1 or 2, wherein It further includes: When the second electronic device receives an interaction request for the first program file, the first electronic device receives the interaction request for the second program file through the first connection, where the first program file is the executable file of the first program in the second electronic device that has not fixed the first vulnerability, the second program file is obtained by the first electronic device synthesizing the first program file and the second patch file, the second program file is the executable file of the first program that has fixed the first vulnerability, and the first program file on the second electronic device is associated with the second program file on the first electronic device; The first electronic device reads the second program file, generates an interaction result or executable instructions, and sends the interaction result or executable instructions to the second electronic device through the first connection.

5. The method according to claim 1 or 2, characterized in that, After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, and the broadcast information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; After receiving the response information of the second electronic device in response to the broadcast information, the first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program, and the response information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device.

6. The method according to claim 3, characterized in that, After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, and the broadcast information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; After receiving the response information of the second electronic device in response to the broadcast information, the first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program, and the response information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device.

7. The method according to claim 4, characterized in that, After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, and the broadcast information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; After receiving the response information of the second electronic device in response to the broadcast information, the first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program, and the response information includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device.

8. A patching method, characterized in that, The method includes: The first electronic device establishes a first connection with the second electronic device; The second electronic device sends the second version information of the first program to the first electronic device through the first connection; The first electronic device obtains a first patch file, and the first patch file is used to repair the first vulnerability of the first program, and the first vulnerability exists in the first program of the second electronic device; The first electronic device compiles the first patch file into first machine code according to the first version information of the first program; The first electronic device synthesizes the first machine code and a first offset into second machine code, and burns the second machine code to generate a second patch file, where the first offset is determined according to the second version information, and the second patch file is used to repair the first vulnerability of the first program with the version information being the second version information; The first version information is the version information of the first program in the first electronic device, and the second version information is the version information of the first program in the second electronic device.

9. The method according to claim 8, wherein The first offset is determined according to the second version information, specifically including: The first offset is determined according to the corresponding relationship between the second version information and the first offset recorded in the first mapping table.

10. The method according to claim 8 or 9, characterized in that It further includes: The second electronic device receives the second patch file generated by the first electronic device; The second electronic device combines the first program file and the second patch file into a second program file, where the first program file is the executable file of the first program in the second electronic device that has not repaired the first vulnerability, and the second program file is the executable file of the first program in the second electronic device that has repaired the first vulnerability.

11. The method according to claim 8 or 9, characterized in that, It further includes: The second electronic device receives an interaction request for the first program file; The second electronic device forwards the interaction request to the second program file of the first electronic device through the first connection, where the first program file is the executable file of the first program in the second electronic device that has not repaired the first vulnerability, the second program file is obtained by the first electronic device combining the first program file and the second patch file, the second program file is the executable file of the first program that has repaired the first vulnerability, and the first program file on the second electronic device is associated with the second program file on the first electronic device; The first electronic device reads the second program file, generates an interaction result or an executable instruction, and sends the interaction result or the executable instruction to the second electronic device through the first connection; In response to the interaction result or the executable instruction, the second electronic device runs the first program in which the first vulnerability has been repaired.

12. The method according to claim 8 or 9, characterized in that, After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, which includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; In response to the broadcast information, the second electronic device sends a response message to the first electronic device, and the response message includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device; The first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program.

13. The method according to claim 10, wherein After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, which includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; In response to the broadcast information, the second electronic device sends a response message to the first electronic device, and the response message includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device; The first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program.

14. The method according to claim 11, wherein After the first electronic device generates the second patch file, it further includes: The first electronic device sends broadcast information, which includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information applicable to the second patch file; In response to the broadcast information, the second electronic device sends a response message to the first electronic device, and the response message includes: the identity identification number of the first electronic device, the identity identification number of the second electronic device, and the second version information of the first program in the second electronic device; The first electronic device determines that the second patch file is a patch file for the second electronic device to repair the first vulnerability of the first program.

15. An electronic device, characterized in that, It includes a communication device, a memory, and a processor coupled to the memory, multiple application programs, and one or more programs; when the processor executes the one or more programs, the electronic device implements the method described in any one of claims 1 to 7 and claims 8 to 14.

16. A computer-readable storage medium, comprising instructions, characterized in that, When the instruction runs on the electronic device, the electronic device is caused to execute the method described in any one of claims 1 to 7 and claims 8 to 14.

Images